AI Agent Architectures: From Instruction Execution to Autonomous Growth

The agent field has seen a notable shift recently. Several new open-source agents have attracted significant attention in a short period, and developer discussion has moved from “Can it call tools?” to “Can it become a genuine long-term collaboration partner?”

This is not merely a surge of interest in individual projects. It reflects a growing divergence in agent product strategies.

One type of agent is closer to a highly open automation framework. Users can freely connect tools, models, messaging channels, and external services; design their own workflows; and maintain their own runtime environment. Its strengths are controllability, extensibility, and suitability for deep customization, but its barrier to use is relatively high.

Another type emphasizes the long-term user experience. It aims to let users describe a goal while the system plans steps, selects tools, records experience, and reuses proven methods in later tasks. It is no longer just an executor waiting for instructions; it tries to become a digital assistant that accumulates capability.

Neither path is inherently superior. The real difference is where each places complexity.

1. From Tool Calling to Capability Growth

The basic working pattern of early agents was not complicated:

1. Receive a user instruction.
2. Call a large language model for analysis.
3. Select a tool.
4. Retrieve the tool’s result.
5. Continue reasoning or return an answer to the user.

This pattern can already handle web operations, file processing, information retrieval, scheduled tasks, and message notifications. But it has an obvious limitation: each task is often a one-off.

If a user teaches the system how to generate a report today, they may still need to explain it again tomorrow. If the system failed last time because of a permission issue, it may repeat the same mistake next time. If a complex task has already been broken down into an effective process, that process is difficult to naturally consolidate into a reusable capability.

As a result, competition among agents is shifting from “how many tools are available” to “whether experience can be converted into capability.”

An agent capable of growth must handle at least three kinds of information:

• Factual memory: user preferences, working habits, commonly used directories, permission boundaries, and similar information.
• Procedural memory: how a task was completed and what steps were involved.
• Strategic memory: which approach should be used under which conditions, and which solutions are prone to failure.

Only when this information is stored in a structured way and accurately retrieved in later tasks can an agent show continuity.

2. Open Agents: Value and Cost

Open agents usually provide rich extension interfaces. Developers can connect custom tools, external protocols, internal enterprise systems, and different types of models. They can also adjust prompts, permission policies, and task orchestration logic according to business needs.

This type of system is well suited to scenarios such as:

• Enterprise applications that need to connect to many internal systems.
• Production environments with strict requirements for data flow and permission control.
• Engineering teams that need to design complex workflows themselves.
• Technical teams that want to use an agent as a foundation for secondary development.

But a high degree of openness also means higher maintenance costs.

When a task fails, the cause may come from multiple layers: model misunderstanding, inaccurate tool descriptions, incorrect parameter formats, missing dependencies in the runtime environment, expired authorization, excessive context length, or version incompatibility between components. Users need to know not only how to use the agent, but also how to troubleshoot the entire chain.

It is similar to driving a customizable engineering vehicle: it has strong adaptability, but the operator also needs to understand the power system, sensors, control logic, and maintenance process.

Openness is therefore not a free capability. It usually translates into configuration cost, learning cost, and operational cost.

3. Growth-Oriented Agents: Making Experience Reusable

The design focus of a growth-oriented agent is not simply adding more tools. It is organized around the question: “What remains after a task is completed?”

A relatively complete growth loop can be represented as:

User goal
  ↓
Task understanding and decomposition
  ↓
Tool selection and execution
  ↓
Result verification
  ↓
Failure analysis and experience extraction
  ↓
Memory, skill, or strategy update
  ↓
Reuse in the next task

The most important parts are the final three steps.

If a system only returns a result after completing a task and does not save the process, it is still just a one-off executor. Only when the system can identify which practices worked and which did not, and convert those conclusions into retrievable knowledge, does it have a real foundation for growth.

For example, suppose a user asks an agent to regularly organize a batch of documents. During the first execution, the agent may discover that:

• Certain file types need format conversion first.
• A particular directory does not have write permission.
• Date formats in file names are inconsistent.
• Generated results must be reviewed by a human.
• The task should be scheduled during off-peak hours.

This information should not remain only in the chat history. It should be extracted into structured rules or skill descriptions. The next time the same task appears, the agent can directly use the proven process instead of starting trial and error from scratch.

4. Memory Systems Cannot Be Just Chat Logs

Many systems treat conversation history directly as memory. This approach is simple, but its effectiveness is limited.

Long conversations often contain temporary information, outdated information, incorrect judgments, and contextual noise. If all content is injected into later tasks without distinction, it not only increases inference cost but may also cause the agent to use incorrect information.

A more reasonable memory system usually needs the following capabilities.

4.1 Memory Extraction

Identify content worth saving from the task process, such as stable preferences, fixed procedures, key constraints, and failure causes.

4.2 Memory Classification

Separate information into user profiles, project knowledge, operational experience, environment state, and security rules, preventing different types of information from contaminating one another.

4.3 Memory Retrieval

Select relevant content based on the current task rather than providing the entire history to the model at once.

4.4 Memory Update

When new information conflicts with old information, determine which is more credible and retain the update time, source, and scope of applicability.

4.5 Memory Eviction

Clean up information that is invalid, duplicated, or of low value, preventing the system from becoming more disordered over time.

From an engineering perspective, memory is not a simple text file. It is closer to a knowledge system with source, time, confidence, and permission attributes.

5. Skill Systems Determine Whether an Agent Improves with Use

Memory addresses “what to remember,” while skills address “how to do it.”

A skill should not be just a few prompt sentences. It should contain complete execution guidance, such as:

• Task types the skill applies to.
• Required input information.
• Tools that can be called.
• Recommended execution order.
• Common failure cases.
• Result verification methods.
• Steps that require user confirmation.
• High-risk operations that should not be executed.

Such a skill can be viewed as an operating manual for the agent.

After a task has been executed repeatedly, the system can distill a stable process into a skill. Once the skill is formed, the agent does not need to replan every time, which reduces inference overhead and improves execution stability.

However, automatic skill generation cannot be left completely unchecked. The system should confirm whether a skill is reliable through test tasks, result validation, and permission review. This is especially important when deleting files, sending messages, modifying business data, or calling high-privilege APIs. Human confirmation and rollback mechanisms must be in place.

6. The Real Differentiator Is Autonomous Error Correction

Ordinary automation workflows usually follow a fixed path. Once a node fails, the workflow stops. The advantage of an agent is that it can adjust strategy based on feedback, but this does not mean it should try indefinitely on its own.

Reliable autonomous error correction should include at least four stages:

1. Identify the failure type: distinguish between parameter errors, permission errors, network issues, business rule conflicts, and model judgment errors.
2. Choose a repair action: for example, retry, modify parameters, switch tools, or ask the user for more information.
3. Verify the repair result: “the tool returned success” cannot be equated directly with “the task is complete.”
4. Record the failure experience: avoid repeating the same incorrect path next time.

For example, when the system receives an “operation successful” response, it does not necessarily mean that the file was actually generated, the data was actually written, or the message was actually delivered. An agent needs result verification mechanisms, including status queries, content checks, format validation, and necessary human confirmation.

Autonomy without verification often only produces errors faster.

7. Model-Agnostic Design Is a Foundation for Long-Term Sustainability

An agent should not be overly tied to a single model. Different models differ in cost, speed, context length, tool-calling capability, and complex reasoning.

A more reasonable architecture decouples the model layer from the agent layer:

Task management layer
  ↓
Strategy and memory layer
  ↓
Model adaptation layer
  ↓
Tool and execution layer

This allows different models to be selected according to task type:

• Use lightweight models for simple classification and format conversion.
• Use models with stronger reasoning capability for multi-step planning.
• Use models in local or private environments for sensitive data processing.
• Prioritize faster-response models for tasks with high real-time requirements.

Switching models should not cause memory loss, invalidate skills, or require tool interfaces to be reconfigured. Only when this is achieved can an agent maintain continuity despite changes in the underlying model.

8. Security Boundaries Determine Whether an Agent Can Enter Real Production Environments

The stronger an agent becomes, the less security can be treated as an accessory feature.

At minimum, the following boundaries should be established:

• Apply the principle of least privilege to tools.
• Require confirmation for high-risk operations by default.
• Isolate context between different users and different tasks.
• Desensitize sensitive information before it enters the model.
• Keep audit logs for all tool calls.
• Review automatically generated skills.
• Provide rollback or compensation mechanisms for critical tasks.
• Limit consecutive retries to prevent abnormal loops.

Particular attention should be paid to “memory poisoning.” If an agent writes unverified external content into long-term memory, later tasks may continue to be affected by incorrect information. Memory writes should therefore distinguish trusted sources and support manual deletion and traceability.

9. The Two Paths Are Not Mutually Exclusive

Open agents and growth-oriented agents are not an either-or choice.

An ideal technical solution can have both:

• A sufficiently open foundation that supports extension of tools, models, and channels.
• A sufficiently simple upper layer that reduces the configuration burden for ordinary users.
• Observable task processes that make problems easier to locate.
• Experience that can be accumulated to create long-term benefits.
• Controllable permissions and risks that meet enterprise governance requirements.

In other words, a good agent should leave complexity to the system and certainty to the user.

Developers can retain full debugging, extension, and orchestration capabilities. Ordinary users only need to describe the goal without understanding all underlying details. The system completes planning, execution, verification, and review in the background, and clearly explains the reasons to the user when necessary.

Conclusion: The Goal Is Better Collaboration, Not Just Execution

In the past, an agent was often evaluated by how many tools it connected to, how many channels it supported, and how many demo tasks it could complete. In the future, more important metrics may include:

• Does it remember what the user truly cares about?
• Can it improve from failures?
• Can it consolidate repetitive work into stable skills?
• Can it proactively clarify when uncertain?
• Can it remain restrained before high-risk operations?
• Can it become more reliable, rather than more chaotic, through long-term use?

The difference between “commanding an executor” and “cultivating an assistant” is not in the interface or the number of tools. It lies in whether the system has established a complete loop of continuous learning, experience reuse, and security governance.

This is the core of the current agent route competition: one path pursues greater freedom, while the other pursues a lower barrier to use and stronger long-term adaptability. A truly mature technical solution will ultimately need to combine both, letting openness serve growth and building growth on controllability.