From Agent Cognitive Architecture to Agent Frameworks

Introduction: Building an LLM Argentina

The questions in this article can also be addressedFor LLM, the outer project with the certainty chain: from Claude Code, Agent HarnessHow the concept of a relatively close read together is developed in different contexts.

From 2025 onwards, language model smarts entered more engineering scenes from the thesis and Demo. The academic community is discussing cognitive structures, memory and multi-intellectual collaboration, while industry is more concerned with the use of tools, competencies, state recovery and observationability. Agent is no longer just a “model multi-wheel dialogue”, but has started to undertake some of the open tasks that would otherwise have been difficult to deliver in a stable manner.

This article does not specifically argue “why Agent is needed”. I just put one premise on the table: LLM brought Agent a lot of world a priori, so that it didn't have to go from zero to zero in a very restricted environment, as it was in the traditional RL Agent.

LLM Agen is not a mystery per se. Its basic logic is to project the model from a simple dialogue into a cycle that allows for observation of the environment, calls for tools, receives feedback and continues to act. The development of LLM Agent has already started in a sense, as long as the language model SDK is called, the model is sent out to solve the structure, and the structure is mapped to the tool.

Harder than the cycle. A deliverable Agent needs to answer many specific questions: how memory is organized, how action is taking place, how feedback is going to move into the next round of decision-making, where authority is limited, and how to restore when failure is over. It's only business instincts that make Agent easily stop at the toy stage.

This article looks at Agent Framework as a layer of engineering translation: it puts memories, actions, feedback, status and privileges in CoALA into a visible, debugging structure. The role of the framework is to reduce the costs of build-up and maintenance, not to define Agent for the developers.

I would prefer to discuss these issues in a practical relationship of dependency. CoALA first gives coordinates of memory, planning, action and environment; WorldFlow, Supervisor and Agent Team then puts control in different positions; then discusses the border between Single Agent and MAS; the framework ends with a freeze on these options into states, nodes, information and recovery mechanisms, and how they become technical debts and what the Agent Framework should look like in my mind. In turn, it is easy to learn the words of a framework before mistakenly thinking that it is Agent itself.

CoALA: The cognitive structure of the intelligent

CoALA（Cognitive Architectures for Language Agents） Language models are seen as a core component of the cognitive architecture and additional modules are used to compensate for the memorylessness of language models and the difficulty of exchanging information with external sources. CoALA is not a specific engineering framework, but a cognitive framework for understanding language intelligence. Understanding the core structure of Single Agen is the only way to further discuss the difference between WorkFlow, Supervisor, Age Team and MAS, and to choose technologies that fit your needs to construct Agent.

Source:Cognitive Architectures for Language Agents Figure 4。

And in combination with this, CoALa can be broken into two layers. Left A is the long-term structure of the intelligent: program memory, semantic memory, scenario memory, work memory, how to read and write between decision-making processes and the external environment. Right B is a partial cycle of action selection: observing the system, following the planning, proposal, evaluation, action, and then returning the results.

Thus, CoALA considers that a language intelligence contains at least three core components:

LLM Interactive: Includes tips, output resolution, structured calls, model selection, etc. LLM is the main source of intelligence, and this layer is the bridge between intelligence and external engineering systems.
Internal memoryThis includes Retrieva from long-term memory, Reasoning to update information in work memory, and Learning to write back experience and knowledge into long-term memory.
External environmentIncludes the digital environment, the physical environment, human users, other intelligence bodies, and various tools-enabled API, file systems, terminals, browsers, databases.

In chronological order, an intelligent body can first obtain context from internal memory and environment, then use LLM for reasoning and decision-making, then implement actions, observe feedback, update work memory and, if necessary, write important lessons into long-term memory. This cycle makes LLM from a one-time generator to a system that can sustain movement in the environment.

The core implementation module of CoALA can be understood as rect Loop. Although various ways of solving the problem have been proposed for Agent, such as Plan-and-Execute, Trey of Thoughts, React Loop is still the most basic structure. Plans and reasoning can be seen as actions in language space and feedback in language space can be generated when plans are validated or modified. In other words, the essence of Agent is not “how many tools have been deployed”, but whether it has a closed loop around objectives, actions, observations and state updates.

Working Memoory: Work in the current decision-making cycle Station

Working Memory keeps active information in the current decision-making cycle, including user input, current targets, tool returns, reasoning intermediate findings, knowledge retrieved from long-term memory, and critical state left over from the previous decision-making cycle.

Engineering can interpret Working Memoory as the core context window for Agent. It is not a pile of all history, but a platform on which the current mission cuts. Access to this desk will directly influence how the model is then understood, tools selected and actions generated. Therefore, the management of Work Memoory is at the heart of the Agent project, and most of the additional components are essentially managed around Work Memoory.

The limited context window raises two problems. First, the message cannot be put aside. Secondly, even if it can, the model may not be able to use it steadily. The long context is not a natural equivalent of effective work memory.Lost in the Middle Such studies have shown that the model does not use information in an evenly balanced manner in different positions in the long context. So Working Memory decides what to enter, what to leave, what to be compressed, what to return to long-term memory.

Episodic Memoory: Experience and trajectory

Episode Memoory stores decision-making experience and mission trajectories. It's concerned with what happened in the past: how a mission is broken down, which tools have failed to call, which prompt works in a certain kind of scene, and how a user's preference is expressed.

When scenario memory is retrieved into Work Memoory, it becomes in-content learning. Agent does not necessarily need to fine-tune parameters, but can also re-use historical experience through external memory. Many of the long-range continuous learnings of Agent are not about updating model weights, but rather about reusable experiences as searchable, auditable, compressible external memories.

Semantic Memoory: Knowledge and facts

Semantic Memoory stores more stable knowledge, facts, rules and field materials. Scenario memory emphasizes experience, and semantic memory emphasizes the knowledge base itself. Documentation in RAG, the Enterprise Knowledge Bank, API documents, product rules, and a glossary of terms are closer to semantic memory.

Semantic and scenarioal memories can all go through Retrieva into Working Memoory, but they have different risks. Scenario memory may not be suitable for migration, semantic memory may be searchable wrongly, context incompletely or knowledge obsolete (if a time-related task). An available Agent Memoory system must address both recall, sorting, compression, source tracking, conflict and obsolescence. These details of realization will be developed separately in subsequent articles on Context Engineering and Agent Memoory.

Procedural Memoory: Processes, Tools and Rules of Action

Program Memory (Procedural Memory) includes the built-in knowledge of the process in the language model, as well as processes, tool definitions, privileges rules, status conversions and hint templates directly encoded in smart code.

The drawing structure, the edge of the project framework, the tools, the scheme program, the skills, the MCP Server, and the approval rules are all considered part of the program memory. Program memory is necessary to activate the intelligence body, but it is also the most vulnerable to misuse. Automatically generate Workflow, essentially to modify program memory: Without expert knowledge to intervene and validate, the processes that are generated may appear reasonable but cannot be corrected under border conditions.

Thus, procedural memory is both a source of stability and a source of rigidity and technical debt. Workflows of WorldFlow, StateGraph in LangGraph, Dify, and automated processes of n8n are essentially part of the decision logic that is written into the program memory. The closer-to-MAS system returns program memory from hard-bound to soft-bound.

Retriev, Reassoning, Learning and Action

The reading and writing of three types of memory constitutes internal motion space, with corresponding external interaction constituting external action space.

Retrieval From long-term memory to work memory. The understanding of retrieval and memory, and how it can be achieved in engineering, are all worthy of separate discussion. In memory enhancement intelligence, long-term memory and retrieval are two sides of the coin and are at the core of continuous learning.

Reasoning Read and update the work memory. It is not just thinking, but building the basis for the next step between the current goals, constraints, feedback and memory.

Learning Update experience to scenario memory, update knowledge to semantic memory, and also influence program memory through fine-tuning, rule updating or work stream modification. There is no special emphasis on forgetting in CoALA, but in the real Age Memoory system, forgetting, conflict management and version governance are issues that must be taken seriously.

Action The blog also shows how the government is doing a lot of work to help people to get out of the country. The external environment can be either a physical world, or a digital system, a file system, a terminal, a browser, a human user, or another Agent.

Context is likely to be the core of the Agent project. The bottom constraints posed by online attention or stronger memory mechanisms remain insufficient attention and limited context until they are truly mature. The history of the Agent project is largely a constant use of external system designs to compensate for the current LLM's short-sets of memory, reasoning and action. When these panels are absorbed by the underlying model, a part of the shell of the Agent project will disappear naturally; but in the present time, CoALA remains an important starting point for understanding Agent Framework.

The essence of intelligent engineering.

The smart engineering program addresses a contradiction:The emergence of intelligence and business.。

A purely Prompt-driven, fully autonomous LLM Agent is imaginative, but it is also highly susceptible to hallucinations, cycles or process collapses in complex production environments. On the contrary, purely rule-based codes, while stable, are unable to address the vague needs of an open world. The goal of intelligent engineering is to strike a balance between performance, generalization and controlability.

This chart of control flows and architecture provides a good overview of the core tools of industry to build Agent. It covers the following modes: WorkFlow, Map-Reduce, RAG, Age Loop, Supervisor, Multi-Agent. From the perspective of CoALA, these models are not unrelated engineering techniques, but are compensating for the short panel of different cognitive modules. The original CoALA also provides a comprehensive summary of existing research (before 2024); if you want to get to the issue first from the researcher's perspective, it is worth reading it first, and the following reading is more engineering-oriented.

Workflow: external program memory

It's pure workwork, like... Summarize Email -> Draft Replyis a one-way or small-scale branch process.

It's cognitive map is Procedural Memoory external hard code. Humans write SOP, rules of operation, anomalies and state flow into the program, and LLM makes only partial judgements or text generation in certain nodes.

And so is it. Anthropic article on effictive agents . The core of the distinction between workflow and anent: Workflow is a predefined code path-routing model and tool; Agent allows the model to dynamically determine its own processes and tools. The production system is usually more biased towards the WorkFlow because it is stable, testable and approved. The price is lower freedom and is prone to rigidity when faced with undefined anomalies.

Map-Reduce: circumventing Work Memoory Limit

Map-Reduce's partitioning skills for Working Memoory. A context window cannot carry all the details at the same time when faced with a large document, long log, multiple file code library or mass input. Map-Reduce breaks the material into separate batches, allowing work memory processing over a short life cycle, and then aggregates the results back into the main work memory.

It addresses not long-term memory issues, but the working memory capacity of current missions. It is valuable in isolation and compression: each Mapworker sees only local context and reduce receives only structured summaries, evidence and necessary references. This reduces both the situation of contact problem and the decision-making of the polluter Agent without any detail.

Many Harnesss of subagent can also be understood from this angle. The sub-age does not necessarily mean MAS, it may also be just a work memory separator: the main, Agent gives local tasks to the sub-prefect, and the sub-preparation only returns to conclusions, evidence and state of necessity after the discovery.

RAG: Long-term memory into working memory

RAG is a common path for long-term memory into Working Memoory. Vector databases, keyword indexes, document libraries, code indexes, graphic databases are essentially different carriers of long-term memory. The retrieval process is responsible for the retrieval of information required for the current mission and for its sorting, compression and formatting into the work memory.Here's the RAG not specifically pointed to the vector search for enhanced generation.

RAG's cognitive map is Retriev: Retrieving material needed for the current mission from Semantic Memoory or Episodic Memoory. For RAG, the real difficulty is not just whether it is possible to find out, but whether the information that is found should be at the current desk, whether it is sourced, whether it is outdated, or not it conflicts with existing memory.

RAG is a engineering path to the current decision-making cycle for long-term memory. More complete memory reading, writing, compressing, updating and forgetting should be discussed in dedicated Agent Memoory and Context Engineering.

Agent / Supervisor: closering control for processing feedback

The Agent mode in the figure usually contains a cycle and a condition branch, e.g. Draft -> Review -> Revise -> ApproveI'm sorry. The Supervisor model introduces a dispatcher to the outer layer to determine which tasker will be next, whether to continue or not.

These two can be understood in the same model:They are closed-ring control structures that handle external and self-revenue feedback, although the concentration of control varies.

The key to Agent Loop is to observe after the action, which will update the state and then decide on the next step based on objectives and feedback. Supervisor simply centralizes this feedback processing: a top controller reads the global state and decides which role, tool or sub-process to call.

This type of structure is really closer to intelligence than a one-way workflow, but it does not automatically equal MAS. If all of you share the same global state and are decided by the same centralized set of conditions, it is more like a single-acting Agent rather than a number of independent Agent societies.

Agent Team: Dynamic cognitive route

The current industry is popular: several highly specialized Agents work together and communicate with each other.

This is different from static workflow. Workflow is the human path that is prescribed in advance; Agent Team wants Agent to make a dynamic route according to the mission status. It is closer to the professional division of labour in human organizations: Planner, Researcher, Coder, Reviewer, Opraator, each with its own borders, and also with information.

But it's easier to spread. The more free the multiple Agent conversations, the more difficult it is to judge who has the final state, who is responsible for termination, who can cover whose judgement, where the error goes into the system. This pattern is...The emergence of intelligence itself and the game of business is a little more than the game of intelligence.

Agent Team is the entrance to the MAS, but it's not magic. It requires clear communication protocols, status boundaries, a model of authority and conditions for termination. We're probably a long way from a real multi-smart system, or tomorrow.

Three early cases: browsers, software teams and analog towns

WebGPT, MetaGPT and General Agents are often present in the Agent primer, but they do not solve the same problem. It's a lot clearer to look at in the cognitive structure ahead.

WebGPT: Let the model find evidence in the browser environment

WebGPT Puts the language model in a text browser, which searchs, opens the web page, quotes the source and answers the questions on the basis of the material collected. It is closer to monomer Agent: a model maintains the current task, browsers provide external action space, and search results return as observation. The generation of answers and the collection of evidence thus entered a training and evaluable trajectory.

MetaGPT: Organize software tasks with role and SOP

MetaGPT Roles such as product managers, architects, engineers are put into software development processes and collaboration is constrained by structured products and standard operating processes. It is often classified into multi-smart systems, but in this paper it is more like a highly structured Agent Team, or even near-suppressed MAS: there are many roles, communications exist and systems rely mainly on pre-designed processes, document interfaces and stage sequences.

General Acts: Memory, Reflection and Plan-driven Social Simulation

Some Chinese material is put Generative Agents The project is being conducted in the Western World. The paper actually built a small town environment inspired by Model Life, 25 generating intelligent bodies that document experiences, form high-level reflections, generate agendas and interact with each other. Simulations can be sustained, relying on the respective memory streams and plans of each actor; other players form part of the environment.

These three cases are quite different. WebGPT shows how the monomer Agent collects evidence by using tool loops; MetaGPT shows how workflow and role division can hold down collaborative spreads; and Generative Ages places independent memories, plans and messages in the same simulation environment. They are all called Agent, but control, memory attribution and communication boundaries are completely different.

Single Agent or MAS

When the project maps extend to Multi-Agent, Supervisor, Age Team, a controversial question arises: What is a single intelligence and what is a multi-intellectual system?

The number of roles, the number of prompts, the number of nodes do not define boundaries. The real boundary lies in the right to work memory, control flow autonomy and the environmentalization of communications.

Workflow: LLM node process system

The first is Workflow. It can be traditional workworkwork, or AI-driving workworkwork. The core feature is that processes are defined by humans or code, and LLM is only a local capacity node in the process.

In such systems, LLM can make abstractes, classifications, extracts, judgments, rewrites or call tools, but it does not have overall control flow. It does not have the autonomy to decide what it “is going to do next”, nor does it have the sovereign right to work independently. It's more like an automated smart component.

Such systems are not inferior. Instead, it is often the most productive of the agglomerations. Most enterprise tasks do not require a fully autonomous Agent, but only a few semantic judgements are embedded in a reliable process. For real production environments, the pursuit of technological novelties is sometimes biased; it is more important to understand business first and automate the stable parts of it.

MAS: Multiple prompt, multi-role, multi-node

The second category is pseudo-MAS. Many of the multiple role systems led by LangGraph fall into this category: The system has multiple prompts, multiple nodes, multiple role names; there are subvisor, searchcher, coder, reviewer, but they share global state, which controls the flow by centralized map structures and conditions.

It's not derogatory. It is of clear value: role division makes the hint clearer, the chart structure makes the state flow manageable, checkpoint allows the long mission to recover, and the break-up mechanism significantly reduces the work memory burden of individual intelligence. But in cognitive terms, it's still closer to a single Single Agent: a brain that wears different masks at different stages, switching work patterns through a central state machine.

Typical features include:

Whether or not the node is called is decided by graph/router, not by Agent to decide whether or not to respond.
Communications are not messages in the environment, but function calls and status updates.

So the LangGraph model subvisor is the multi-player Agent on the edge of the condition, not the strictly MAS. It is suitable for engineering control, but it should not be mistaken for a society of self-governing intelligence.

MAS: Information-based and border-based Agent Team

The third category is the real MAS or the Agent Team closer to the MAS. It's not about having a lot of Agent, it's about having at least a relatively independent working memory, tool boundaries, target interpretation rights and an interface.

In this structure, other Agents are external to one Agent. Agent A does not see the full internal state of Agent B unless B voluntarily shares the information. A. Requests sent do not necessarily impose enforcement, B can respond, refuse, forward, request more information or call tools according to its own strategy.

Communications themselves will also be part of the design of the system. The agreement provides for information formats and actionable actions, broadening the decision point-to-point, broadcast or central movement, and content boundaries to determine whether conclusions, evidence or full trajectory are shared. Collaboration, consultation and competition are no longer mere role lines in the prompt, but change the mandate, status and follow-up.

This is closer to the Actor Model or the news community in computer science. Its advantages are autonomy and complication, and its weaknesses are the cost of containment, observation and governance. Full and open MAS is easily dispersed, so real production systems often have another layer of workflow on the MAS outer layer. This would form a hybrid structure: there would be an independent Agent internally, working by means of information, and the external boundaries would remain bound by a definitive process.

Why is this distinction important?

The former separates the WorkFlow, the pseudo-MAS and the Agent Team, which is closer to real collaboration, not for terminological purposes, but because once the classification is confused, the project judgement is distorted.

If all multiprompt, multi-role, multi-node systems are collectively called MAS, developers can easily misjudge the problems they face. You think you're designing multi-intelligence collaboration, and you think that you're actually just trying to maintain a centralization machine; you think that the system failed because of multiple Agents, and that what really went out of control was just sharing the state that was expanding, the route was becoming more and more fragile, and the context was contaminated by the middle noise.

More importantly, the capacities that are really needed by different structures are also quite different. The core issue of WorkFlow is reliability of organization: whether sequence is controlled, node replayable, failure is restored, approval and log is complete. The central issue of the pseudo-MAS is governance: how to tailor the context of sharing, how to recover the checkpoint, how to keep the conditions transparent, and how to explore the whole picture in part. The closer to true collaboration, Agent Team, is the way to move the problem to the message agreement, the handoff syntax, the boundaries of authority, conflict resolution and termination strategies.

So, the difference is not really about naming, but about where you should spend your engineering energy.

MAS or Single Agent and Dynamic Workflow

When the boundaries are clear, new elements are seen, which are all circled around the same question: where should the system put uncertainty? Put it in a continuous monomer, put it in multiple separate Agents, or put it in dynamically rewritten Workflow.

June 2026: Claude Code Dynamic Workflows, essentially dynamically adjust the program memory to allow Agent to generate, modify and execute processes in its operation. I was talking about something very close with tears in January: writing a DG Yaml file, and running it with a set of Runtme. The problem is that the YAML is not very expressive, it's written in terms of DSL; people are in prison, AI writing fees are available.intentlang Closer to the direction I can accept: to write the expert's experience into hard-line constraints, but not to let the expert be kidnapped by the Agent concept. Claude Code is just replacing the carrier with a self-generated JS Reconciliation Runtme, the route is not mysterious.

The danger is here: Dynamic Workflow is the same as making Agent rewritten the program memory. The model is strong, but not to the extent of default decentralization. It must be accompanied by subagent privileges, tool boundaries and validation points; otherwise it will bring not only dynamic processes but also dynamic accident entry points.

Anthropic and Cognition can also be compared here with the differences between a multi-smart system and a single one. Anthropic. multi-agent research system Suitable for research tasks: lead anent schedule multiple subagents in parallel, internal rating sheets add Claude Opus 4 90.2% higher, and complex queries reduced by up to 90%. The price is token, normal anent has burned about 4x, multi-smart system about 15x, token usage itself explains 80% performance differentials.

Cognition Don't Build Multi-Agents . The coded task is not defaulted on multiple intelligences. Coding anent often requires complete track and actions imply design decisions; one subagent paints background and conduit, and the other draws birds, and it is easy to spell the same visual style. Once the sub-missions are highly integrated, local autonomy becomes a conflict of the whole.

So this is not a contradictory blog, and they actually support the other side in a certain degree of detail, but do not appear in the title. Research missions can naturally be parallel and evidence can be aggregated; coding missions are high and continuous track is more valuable. My judgment is simple: wide information, looseness, budget, mas; continuity of decision-making, consistency of style, many implied constraints, using Single Agent; clear processes and steps to deflate and long exaggerate, using Dynamic Workflow. It is not the number of players that should be seen, but the parallelity, the state coupling, whether or not the race must be shared, whether the powers can be isolated, and what the failure radius is.

Workflow or Age: Why production systems end up moving towards hybrid structures

But once the boundary is understood, another reality becomes clear: a real production system, often not stopped in a pure form.

The advantages of pure Workflow are stable, auditable and manageable, but it has limited capacity to handle open assignments, long chain exploration and undefined anomalies. Pure Agent has the advantage of being flexible, autonomous, capable of trying to advance in vague issues, but at the cost of a context that is more perturbed, of reasoning that is more drifting, and of system behaviour that is more unpredictable. The extremes of each of these two groups make it difficult to support complex production tasks alone.

So, the common sense method in reality is not to choose between Agent and Workflow, but to make them into a mixed layer of composite architecture: The taskline, budget, approval and termination conditions are locked in the perimeter with the WorkFlow; the local high uncertainty chain is inserted into Agent with the capacity to plan autonomously; and the independent sub-mission is delegated to Subagent when the individual Agent's context continues to expand, only to recover the conclusions of the compression, rather than to pour the whole exploration back into the main context.

So, the workflow is a outer order, the Agent is a local intelligence, and the Subagent is responsible for cutting the context. What we really designed is not whether or not we want Agent, but what level must be rigid, which level can unleash autonomy, which level must isolate memory and reasoning.

But whether it is a choice of the outer layer, or whether it is a partial placement into the autonomous Agent, the real premise is not a framework, but an understanding of the business by the developers. Workflow is a reliable area, essentially to include in the system the understanding of experts in the field of problem definition, state flow, abnormal branch and acceptance criteria; a credible autonomous Agent also requires first clarification of the target boundary, feedback signals, authority and failure restoration. AI is hard to solve for you a problem you don't even know. In many cases, the most modest way to develop such systems is not to find another framework, but to have coffee every day and for business parties to ask a little bit about those judgements that exist only in experience.

And that's one of the reasons why the Agent framework is so confusing today. Users are disturbed by abstract ways of different frameworks without building an understanding of the Agent itself, and it is difficult to create a stable understanding of the Agent design.

But the meaning of the framework is here: it should not blur those borders for us, but should help us to make them visible.

Smart framework: from cognitive scaffolding to engineering infrastructure

If one sentence is used to set the tone:The framework is not providing intelligence, but is freezing the contract on how to manage LLM uncertainty. The real difference between frameworks is not a name or interface, but rather what they choose to treat as a core abstraction, what they leave to models to play freely and what they see as a fixed stream of work.

LangChain / LangGraph: from Chain to StateGraph

LangChain represents the first wave of the Agent project, which is very typical: first, the Prompt call, the tool call, the RAG, the memory, these common actions are sealed into a condensable assembly, then they are tied together through Chain. It provides not a fixed intelligence, but an interface that combines LLM as an application component. It's the first time that it's put LLM in an application.

But when Agent went from a one-time call to a long mission, Loop and a halfway back, the simple Chain was not enough. LangGraph, he then upgraded the core abstraction to a visible one. StateGraph: shared status, nodes, sides, route of conditions, cycle, checkpoint recovery. Its strengths are clear: state-of-the-art thinking, chart-flow structures, human approval, long-term mission recovery, failure retrace and replayability.

And because it's strong, LangGraph can easily shape the thinking of developers, let people learn framework syntax, and understand the mission itself. It's not about the frame being inadequate, it's about the frame.Not fit as default Agent mind modelI'm sorry. Moreover, the integrator of smart technology itself has developed rapidly, and premature high-level sealing has quickly become a technical debt.

This debt will affect first. Human developers can read documents on a temporary basis and remember that interface migrations; models are more easily disturbed by old versions of documents, training materials and project local codes. It changes a LangGraph project not just by changing business logic, but by modifying a fast-evolving control language:StateGraph、state schema、conditional edge、message reducer、checkpoint、node side effect。

The problem is not that these concepts are per se complex, but that they expand the wrong space. The working ant must also determine whether the bug comes from the business code, node side effects, status consolidation, route conditions, or framework version. Once the upper-level envelope becomes an additional level of interpretation, the maintenance cost moves from understanding the task to understanding how the framework is named.

Such liabilities also affect the development process itself.AnalysisPosts The first stage of the project is the simultaneous cleaning. It cannot simply use OpenAI-compatible request mode because the project requires a more finer primary SDK control:ZaiClient Re-use, Request Level timeout, visual input,thinking Parameters, and BatchaPI and KV-Cache.

The LangGraph/ LangChain model interface does not directly support this SDK, and can only be called by hand from the original Python in the node. The problem is not just that the code is written in more than a few lines, but that the centre of abstraction is shifting: the model requests, retests, and co-opts and parameter controls that really determine the system ' s reliability and capability boundaries are not in the frame, but are in the original code in the code in the node. When this key link is returned to its original Python, LangGraph will be able to provide only a layer of process organization and no longer assume the role of the core runtime.

The second specific scene is Staage2's DataAgent and SeachAgent. They are not a branch of normal functions, but two small React Loop: each produces tools for call, tool return, failed attempts, intermediate observations and local judgment. These should be part of their own private work memory, not be written by default. messagesI'm sorry. If the collaboration is understood as a flow of nodes on shared state following the LangGraph default mental model, then both branches will be updated to the same MessagesStateWell, then... add_messages Or reducer will accumulate both tracks into the same stream. Subsequent subvisor or other nodes read not only the end product, but also the internal noise of another Agent.

And this and... AnalysisPosts The demand is the opposite. What it needs is...Limited information exchangeDataAgent and SeachAgent can each keep a partial working memory, but the main process only receives questions, tables, insight provenance, a small track or compressed summary. LangGraph is not completely incapable of this isolation; it can be used to map the parent state manually to subgraph input, subgraph output to parent state. But then the real hard part goes back to the original code: Which messages allow to leave the sub-unit Agent, which fields should be filtered, which results can be merge and which intermediate tracks must be discarded. The framework provides shared status maps, and this demand requires private work memory and visible communication protocols. The default abstraction of LangGraph is not an advantage in this scenario, but a simple incentive for developers to put the context that they should not share into the global state. This is a common demand of Agent Dev, but Langraph was not taken into account in the original design and was forced to add a patch that was not light and was not easy to use.

So my judgment on LangGraph is balanced. It is suited to complex situations, long-term recovery, multi-step audits and processes that require visible and sustained continuity. But if your core issues are the design of the Agent body, control of context pollution, definition of environmental feedback, and management of the boundaries of authority, starting directly with LangGraph, it might make you premature to translate the problem into a picture, rather than think clearly about the task itself.

Diffy / Coze / n8n: Platform, Product and Automated Framework

Diffy, Coze, n8n could be discussed together, as they are not the first objective of “writing an Agent runtime”, but rather package the Agent capabilities into applications or processes that are more readily available for delivery. But the three are not the same.

Diffy is more like the Agent platform for application delivery. It places the knowledge base, tools, workflows, observation, deployment and operation backstages into a single product. For business such as question and answer, assistant, retrieval enhancement, form processing, content production, Agent, development teams often do not want to build memory layers, log panels, distribution links and backstage configuration systems from a patch. Diffy is worth letting apps run first.

It also comes at the cost of plaque-encapsulation. The more complex the control stream, the more the state design of the fine particle scale and the more the scenes need to be debugged in a transparent manner at the bottom. When the task requires a self-defined restoration logic, fine-tuning context tailoring or non-standard tool route, the platform ' s convenience becomes the upper limit of the scope of the project.

Coze is more like the Agent factory, which is oriented towards the product entrance. It is not just a back-end arrangement, but rather how the Persona, knowledge, tools, plugins, workflows, chat interfaces and distribution channels are combined into a product that can be directly accessed by users. For many teams, what they really want to do is not a back-end framework, but an Agent product that is online, operational and distributed.

Coze has the advantage of productization of access and capability consolidation at the cost of the platform choosing the bottom details for you. This is good for fast-track end-products; it also means more discipline for teams that want to take deep control of state structures, protocol layers, log systems or cross-system runtime.

n8n is not based on Agent, but on automation. It would have addressed how to reliably link different systems and SaaS services, so the real strengths are connector ecology, trigger mechanisms and visualization processes. When the AI node is accessed, n8n forms the paradigm of "Structivity flow plus local intelligence node".

Such models are particularly appropriate for the task of “process automation + a little intelligence”: form collection, message routing, summary generation, retrieving after the rules are triggered, semantic classification when across-system synchronization. It is very valuable, but it is not natural for complex memory management, long-term state recovery and multiAgent consultations. n8n is good at embedding AI processes, not at transforming processes into complete processes.

N8n-like connector ecology will continue to be an important infrastructure, but MCP, Agent Skills and coding anent matures to change the boundaries of the no-code platform. Once we made a choice between no-code and code, it's now becoming more like a choice between no-code and vibe coding.

AutoGen: Attraction and Risk

AutoGen It represents another route: to break the world apart from the world, and then to engage those actors through the message and dialogue. Different Agent has different duties, tips and tools to accomplish the goal by session, handoff and task break-down.

This paradigm is naturally close to human instincts for teamwork. You can quickly get a planner, coder, reviewer, tool anent, and get them to exchange information like meetings. This is valuable for demonstrating the multi-Agent organizational shape, exploring open division of tasks, and researching the upper limit of autonomous collaboration.

The risks of such frameworks are also very direct. The more free the Agent dialogue, the more easily it will be exposed to problems of condensity, observableness and production stability. Why did the mission break out? Which Agent really has state sovereignty? Who's in charge of stopping? How do you track the chain of responsibility when one misjudged accepted by another? Once these problems are brought into real business, the costs of debugging will rise rapidly.

So AutoGen is very well suited to help us understand the potential of multiple Agents and explore the true MAS collaborative boundaries. But they are not natural equivalent to the most easily landed production programmes. The closer it gets to the real MAS, the more it takes to get information protocols, private memory, auditing, authority and termination conditions. And there's no conclusion as to how these harnesses are designed.

OpenAI Agents SDK: Light contrast to runtime

OpenAI Agents SDK The government has also been able to provide an alternative direction that deserves to be contrasted: Agens, Handoffs, Guardrails, Tracing. It does not put the core abstract on the map and the status machine, as LangGraph did, but it is closer to a light runtime: providing basic structures for models, tools, interfaces, safe boundaries and trajectory observations.

The point of this light runtime is that it does not rush to draw a complete state map for the developers, but to make the infrastructure of the most easily repeated parts of the Agent system. Handoff handles control transfer, guardrails handles input-output boundaries, tracing handles detectability. These abilities do not define the Agent body, but make it easier for developers to build their own runtime.

This does not mean that light frameworks are necessarily better. It also leaves more design responsibilities to developers. But when the Agent norm is not stable, the advantage of light frames is to make less decisions for you and less of a DSL that cannot be made.

Summary: What are the agreements frozen in these frameworks?

Frame	Abstract Unit	Control flow	Status Model	Autonomy	Apply scene	Main costs
LangChain / LangGraph	Chain / Node / StateGraph	Visible routing and circulation	Share State + checkpoint	Medium, can be precisely bound by the map	Multistep closed loops, long missions, clearance, recovery	It's abstract, it's easy to learn the frame before understanding the mission.
Dify	Applications, knowledge base, tools, work streams	Platform presentation	Platform hosting status	Medium and Low	Questions and answers, business assistants, rapid delivery	Limited flexibility, low-level detail difficult to reach
Coze	Persona, Plugins, Workstreams, Product Entry	Product dialogue portal	Platform 's Inner Cluster State	Medium	Agent product for terminal	The platform is strong and the scope is limited
n8n	Automation Nodes	Specific Process + AI Node	Process Context	Low to Medium	System integration, automation of processes	Not original
AutoGen / CrewAI	Agent / Message / Crew	Dialogue Collaboration or Flow Control	Dispersion or session status	High to Medium	Agent Team, Multi Agent Experiment	Fragmentable, sovereign state and ending difficult governance
OpenAI Agents SDK	Agent / Handoff / Guardrail / Trace	Light runtime	Developer custom	Medium High	Self-study Agent runtime, light frame integration	Don't make decisions about infrastructure.

These frameworks, taken as a matter of fact, are not answering “who is more advanced”, but are answering three questions: How to regulate models, how to organize themselves, and how to deal with uncertainties. The so-called framework difference is ultimately a different solution to these three issues.

When the framework precedes regulation: why the smart framework quickly becomes a technical debt

The problem was never that a framework existed, but rather that it had prematurely entrenched a temporary set of practices into high abstraction when the design norms of the intelligent were not stable. So many frameworks are not settling proven engineering patterns, but propagating experience that at some stage seems good enough.

In other words, once the framework has evolved from a tool to a pre-dense model, it will disguise the unstable engineering options of Prompt, tool, memory, retrieval, recovery and so forth as a set of stability norms. It is most dangerous not to have multiple layers of code, but to have a layer of failure: developers must first judge whether the problem comes from models, operations, environments, or the abstraction of the framework itself.

No norm. Abstract first.

Today we still have no real stable Agent design code. How should Context be graded? Amory should be exposed to database, cache or graphic writing back? How does the Tool Use's permission boundary be defined? Are failure restored by nodes, steps or tasks? To evaluate the final evaluation process, the results or the trajectory? These core languages are still changing rapidly.

The framework is sealed at a high level at such a time that the periodic answers are packaged into universal truths. For example, translate Agent into a diagram, translate the role into nodes, translate the interactive into a global state, translate the memory into some sort of store. They may be useful, but none of them should be mistaken for the Agent's essence and the only way to solve the problem.

Early abstraction increases the burden of mind.

Early abstraction changes the order of learning. Many developers are forced to learn before they understand the Agent body. StateGraph、Router、Node、Agent Team、Memory Store、Reducer、Checkpoint These are the framework words. The result is not to understand Context, tools and state, but to choose the right abstract; it is to learn how the framework is named and then to push Agent back.

This problem is going to be even worse for the coding anent. At a minimum, humans can read documents, remember differences in versions, understand implied agreements; models tend to be more easily miswritten when confronted with high-level DSL and frequently changed frame interfaces. The more high-level and rapidly changing seals, the harder it is to be preserved by future angtic coding stability.

Black box seals are weakening the visibility.

Another cost of the framework is to hide the key engineering details. Prompt how it is written, when it is, when it is written or when it is read or written, who decides to try again after failure, which checkpoint it is read one time, and often it is sealed in the frame default logic.

When systems are smooth, these seals are very low; when systems are out of control, they become the most difficult black boxes to open. For Agent, a system that is already full of uncertainty, observable is not a pre-condition for adding flowers, but for producing them.

Models advance, the seals are fast out.

The evolution of modelling capabilities further exacerbates the problem. Original calling, longer context, parallel tool call, stuctured output, supplier SDK bringing, modeling built-in web search and code execution will change what abstraction is necessary.

Many once intelligent seals could become a patch of excess in a few months. Developers began to spend a great deal of time on how to circumvent the framework limits rather than on mission modelling and business logic. In particular, when the core issues are environment, competence, feedback, and governance, self-study runtime tends to be more direct than a generic framework.

The framework, for example, remains useful, but it should help us to expose problems, not hide them for us; it should reduce the cognitive burden, not create new cognitive debt.

Claude Code and OpenClaw: Why the front system goes back to the original development

If the previous types of frameworks are seen together, a more interesting contrast emerges: many of the truly effective front-line systems do not choose a common framework before they plug in; rather, they often create original runtimes around specific environments before deciding which parts are worth abstraction.

In other words, LangGraph, AutoGen, OpenAI Agents SDK, these frameworks discuss "How to abstract Argentina," while Claude Code and OpenClaw are more like answering another question: When the mission environment itself is sufficiently rich, whether the system should grow in the environment before deciding which capacities are worthy of being framed.

Claude Code: original closure around the coded workflow Ring

Claude Code is not about proving that a generic Agent Framework is strong enough, but rather about making the encoded mission space organization a primary closed loop with high feedback density. The code library is readable, terminal is operational, testing and construction provides quick feedback, and Git diff and code review forms a natural human review point.

This environment is itself well suited to Agent: the file system provides external memory, the terminal provides operational space, the test provides feedback, Git diff provides state boundaries, review provides human-in-the-loop. It does not require translation into a generic mapping framework to allow the model to work.

So Claude Code's success is more like a mission structure running through, than a framework that is abstract and unified. It allows the model to work directly in the real development environment: reading codes, changing codes, running commands, observing results, and continuing iteratively. It's a primitive runtime idea, and the framework here is just a support tool, not a center.

OpenClaw: Combination of primary systems around personal environments

OpenClaw exposes another kind of problem. It is not about highly standardized development processes, but rather about chatting, voice, equipment, automation, personal knowledge, long-term memory, authority control over these isomeric and sensitive physical surfaces.

In this mission space, the difficult part is not to state a few Agent roles first, but to organize the debrisification environment into a system that is detectable, operational and not out of control. How equipment access is handled, how privileges are isolated, how automation is triggered, how long-term memory is managed, how skill systems are gradually exposed, and how users take over at any time are all problems of runningtime and system engineering.

If you're too early to fit into a generic Agent abstraction, you might cover up the real problem. A more logical sequence would be to define the environment, feedback, competencies, recovery and mandate structure before deciding which elements are worthy of frame.

Light-encapable unit: Skills position

The light-loading of Skills, which is attractive at this stage, is also an important component of both products, precisely because it does not rush into a heavy-power framework. It sets instructions, scripts, templates and reference materials into a catalogue of capabilities for progressive disclosure, suitable for carrying rules, processes and organizational experience without forcing itself to pretend that it is complete. For a more detailed discussion of Skills, please refer to another blog of mine. From MCP to Agent Skills。

But Skills also reminds us that light seals are not no cost. The model is faced with semi-structured documents and scripts, and it still needs to determine when, what to read and whether to execute. The question here is not just whether there is a framework, but whether the system has put uncertainty in the right place: The parts of the model that should be handed over to the model and which are locked to death by the project constraints must be clearly locked to death.

I understand the smart framework: what it really provides.

If it is recognized that a heavy framework can easily create a mental burden, the next step is not to reject it, but to narrow its functional boundaries. A good framework should only provide the capacity that is repeatedly needed and that is not worth rewriting by each team.

The first is transparent state management. What is in the context, how the status is updated, where the check points are and how the tasks are restored should be visible, auditable and understandable. The state is not transparent, and Agent can only stay in the phase that looks like it's moving.

The second is access to primary tools and protocols. The light-capable units such as MCP, function call, external API, file system, message system, and even Skills should be directly accessible, rather than forced to reset their own framework-specific protocols. A good framework should reduce the cost of adaptation rather than create new compatibility layers.

The third is observable. Prompt, how it was assembled, when the tools were called, what happened to its state, which nodes triggered a re-test, whether the entire track could be replayed, should not rely on frame black boxes UI to guess. Agent is not a traditional back-end service, and the weaker the observation capacity, the higher the costs of debugging.

The fourth is memory interface. Whether it's epsodic memoory, semantic memoory or procedural memoory, the frame should not pretend to be self-regulating. It should expose the readings, search strategies, compression, phase-out, conflict and policy to make it clear to developers how much of the memory affects current decision-making.

The fifth is the human-in-the-loop border with the permission. Approval points, manual takeovers, rollback points, hazard confirmation should not be based on ex post facto filling. Once a smart body enters a real work stream, human beings are not just a bottom-up, but part of the system. To replace a person completely, it is usually possible to pre-encapsulate human experience as Workflow; for autonomous decision-making, human-in-the-load remains a key component of reliability.

Finally, it should be friendly to anatomy coding. As model coding continues to increase, more and more systems will allow Agent to read, modify and even expand its own operating logic. The closer the framework is to the native language, the original engineering object and the primary tool chain, the easier it is to be understood with Agent; the more the upper-level magic seal, the easier it is to be a drag on subsequent automated maintenance.

Ultimately, a good framework should reduce cognitive debt while retaining control over the works. It does not think about what Agent should be, but rather provides basic capabilities that are worth replicating once the developer has understood the structure of the mission.

I look forward to a more thin, transparent and closer framework to the mission environment. It should make the memory, actions, feedback, status and privileges in CoALA visible, manageable, and interchangeable, rather than wrapping them into a black box that seems to be advanced and must be, finally, bypassed.