The State, Implementation Principles, and Trends of AI Agents in 2026¶

Research date: 2026-08-10 Note: "Popular" in this article weighs product influence, developer adoption, ecosystem activity, and open-source community attention together; it does not represent a strict market share ranking. Commercial products generally do not disclose full technical details, so their implementation principles are based on official public materials and observable behavior.

One-Page Summary¶

1. An agent is not a model that is better at chatting, but a system that can continuously act toward a goal. A practical agent typically consists of a model, instructions, tools, state/memory, execution environment, permissions, and evaluation.
2. Coding agents are currently the most mature and most competitive direction. Codex, Claude Code, Cursor, Gemini CLI, Devin, and OpenHands have moved from "code completion" into a complete closed loop of "understand the repository—modify files—run commands—test—commit/deliver."
3. The key to general-purpose agents is not just model intelligence, but whether there is a controllable "computer." Manus, Comet, Browser Use, and others rely on browsers or cloud sandboxes to complete web operations, data processing, document generation, and application building.
4. Enterprise agents are shifting from chatbots to a governed business execution layer. The competitive focus of Copilot Studio, Agentforce, and Gemini Enterprise Agent Platform is connectors, enterprise data, identity permissions, auditing, process orchestration, and industry templates.
5. Production systems are returning to "deterministic workflows + local autonomous decision-making." Fully open-ended agents are costly, high-latency, and hard to reproduce; reliable solutions typically let the model handle understanding, routing, and exception handling, while letting code handle transactions, approvals, and irreversible actions.
6. Multi-agent systems will grow, but will not become the default answer to every problem. Only when a task can be clearly decomposed into independent roles, verified in parallel, or requires isolated context does multi-agent generally outperform a single strong model with good tools.
7. MCP and A2A are forming a two-layer interoperability standard. MCP connects agents to tools/data, and A2A connects agents to agents; the real moat will gradually shift toward data, permissions, skills, evaluation sets, and business closed loops.
8. Security and evaluation are the main bottlenecks for agent deployment. Prompt injection, unauthorized calls, sensitive information leakage, memory pollution, and error accumulation across long chains determine that sandboxes, least privilege, human confirmation, trace tracking, and regression evaluation must become infrastructure.

1. What Counts as an Agent¶

Traditional chat models typically perform a single "input → output" pass; an agent, by contrast, repeatedly observes the environment, selects tools, executes actions, reads results, and revises its plan based on the goal, until a completion condition is met or a stop rule is triggered.

flowchart LR
    U[Goal and constraints] --> M[Model: understanding, planning, decision-making]
    M --> T[Select tool/delegate task]
    T --> E[Sandbox, browser, codebase, or business system]
    E --> O[Observe execution results]
    O --> S[Update state, memory, and plan]
    S --> M
    S --> G{Complete, failed, or needs approval?}
    G -->|Continue| M
    G -->|End| R[Results, artifacts, and execution trace]
    P[Permissions, guardrails, budget, evaluation] -.Constraints.-> M
    P -.Constraints.-> T
    P -.Constraints.-> E

Current mainstream implementations can be summarized into seven layers:

Anthropic makes a very practical distinction between "workflows" and "agents": the former has paths predefined by code, while the latter has the model dynamically determine the process and tool usage; it also recommends starting with the simplest, composable options, because agents typically trade higher latency and cost for flexibility. Source

2. Notable Popular Agents Today¶

2.1 Coding Agents: The Most Mature Track¶

Official materials: Codex · Claude Code · Cursor Agent · Gemini CLI · Devin / Architecture · OpenHands / Sandbox

The reason this track leads is straightforward: software engineering naturally provides machine-readable context, executable tools, and automatic acceptance signals. Code can compile, tests can pass, diffs can be reviewed, and Git can roll back, making it easier for agents to form a closed loop than in the open world.

2.2 General-Purpose Execution and Browser Agents¶

Materials: Manus introduction / Cloud Computer · Comet · Browser Use · Gemini Computer Use

2.3 Enterprise Workflow Agent Platforms¶

Materials: Copilot Studio / Integration strategy · Agentforce Atlas · Gemini Enterprise Agent Platform · ServiceNow AI Agent Orchestrator

The moat of enterprise platforms is usually not "smarter models," but that they already know who employees are, what data they can see, what actions they can invoke, how approval works, and how operations are audited and rolled back afterward.

3. Popular Agent Development Frameworks¶

Products are the end-user experience; frameworks are the foundation for building your own agents. The two should not be placed in the same ranking.

Materials: LangGraph · CrewAI · OpenAI Agents SDK · Google ADK · Microsoft Agent Framework · Browser Use

Open-Source Attention Snapshot¶

GitHub stars can only indicate developer attention; they cannot be equated with active users, enterprise adoption, or product quality, but they help observe ecosystem momentum. As of this research, representative projects are roughly:

Star data comes from the corresponding GitHub repository pages; the values change continuously and should not be used for precise ranking.

Wrapping an Internal Agent Platform with OpenClaw: Pros and Cons¶

OpenClaw's official positioning is a self-hosted personal AI assistant. It uses a long-running Gateway to uniformly carry message channels, sessions, Hooks, nodes, and the Agent Runtime, then extends capabilities through tools, Skills, Plugins, MCP, browser, and multi-Agent routing. The Gateway architecture shows that a single Gateway can connect to channels such as Slack, Teams, Telegram, WhatsApp, and WebChat, with control-plane clients and device nodes connecting via WebSocket.

This happens to cover the most time-consuming set of common capabilities in the early stages of an enterprise internal Agent platform, so some companies choose to add portals, SSO, knowledge bases, and business tools around OpenClaw to quickly form an internal platform. This approach has practical value, but the premise is to treat OpenClaw as an Agent Harness, channel adapter, and execution unit, rather than directly as an enterprise-grade identity, permission, and multi-tenant security kernel.

Key Advantages¶

The OpenClaw Tools documentation clearly distinguishes the extension surface into Tools, Skills, and Plugins; tools can also be filtered through multiple layers of allow/deny policies at the global, Agent, channel, Provider, and Sandbox levels. This makes it more attractive as an internal Agent prototyping foundation than building from scratch.

Key Disadvantages and Risks¶

The most critical limitation comes from OpenClaw's own security documentation: Multi-tenant hosting requires separate complete instances for different trust boundaries; Security also explicitly states that a shared Gateway is not a hostile multi-tenant security boundary. In other words, "multi-Agent routing" solves message distribution and workspace isolation, but does not equal true multi-tenant authorization.

Furthermore, OpenClaw's Policy plugin is mainly used to check configuration compliance and drift; the official documentation explicitly states that it does not enforce tool calls on every request, nor does it rewrite runtime behavior. Therefore, enterprises cannot treat a single policy.jsonc as a complete real-time authorization layer.

Recommended Enterprise Wrapping Approach¶

Employees / Slack / Teams / Internal portal
              │
        SSO + API Gateway
              │
    Internal Agent Control Plane
   ├── Agent catalog, tenants, and quotas
   ├── Model routing, task status, and Evals
   ├── Approvals, audit, and cost attribution
   └── Gateway/Cell lifecycle management
              │
    Independent OpenClaw Cell per trust domain
   ├── Fixed-version Gateway
   ├── Approved Skills/Plugins
   └── Independent workspaces and short-lived session state
              │
     Container / gVisor / Kata / VM
              │
       Policy + Tool Gateway
   ├── User identity and short-lived credential exchange
   ├── Parameter validation, rate limiting, and human confirmation
   ├── Network egress, data masking, and audit
   └── Enterprise APIs, Git, browser, database

员工 / Slack / Teams / 内部门户
              │
        SSO + API Gateway
              │
   内部 Agent Control Plane
   ├── Agent 目录、租户与配额
   ├── 模型路由、任务状态与 Evals
   ├── 审批、审计与成本归属
   └── Gateway/Cell 生命周期管理
              │
   每个信任域独立 OpenClaw Cell
   ├── 固定版本的 Gateway
   ├── 审批后的 Skills/Plugins
   └── 独立工作区与短期会话状态
              │
     Container / gVisor / Kata / VM
              │
       Policy + Tool Gateway
   ├── 用户身份与短期凭据交换
   ├── 参数校验、限速和人工确认
   ├── 网络出口、数据脱敏和审计
   └── 企业 API、Git、浏览器、数据库

The following principles are recommended when implementing:

1. One instance per trust domain: Split Gateways at least by team or security domain; mutually untrusted tenants use separate containers, OS users, or VMs; do not mistake Agent routing for tenant isolation.
2. OpenClaw serves only as the Harness: Identity, permissions, secrets, approvals, billing, and auditing go into a separate control plane and Tool Gateway; the Agent can only propose actions, and the external policy layer decides whether to execute them.
3. Read-only by default and minimal tool set: First open up search, knowledge bases, and read-only APIs, then open write operations item by item; do not give a general-purpose Agent an unrestricted exec and shared production credentials.
4. Explicitly enable strong isolation: Choose containers, gVisor, Kata, or VMs based on risk; separate the Gateway from the execution Sandbox, and deny outbound network and host directory mounts by default. See Sandbox and the differences between Sandbox, Tool Policy, and Elevated.
5. Extensions first, fork last: Prefer extending with Skills, Tool Plugins, MCP, and external services; only maintain a small Patch when upstream extension points genuinely cannot meet the need, and pin versions and maintain an upgrade test matrix.
6. Establish an internal artifact supply chain: Disable employees from arbitrarily installing community Skills/Plugins; use internal allowlists, pinned versions, code review, dependency scanning, signing, and canary releases. The Skills documentation also requires treating third-party Skills as untrusted code.
7. Evaluate with real tasks: Every time OpenClaw, a model, a Skill, or a tool is upgraded, run the same set of golden tasks and compare completion rate, unauthorized-access rate, tokens, latency, cost, and human takeover rate.
8. High-risk actions do not go through an open-ended Shell: Encapsulate capabilities such as production releases, refunds, deletions, and payments as narrow interfaces, with server-side Schema, permission, idempotency, transaction, and approval validation.

When It Is Worth Choosing¶

Singapore's IMDA OpenClaw responsible deployment case study likewise recommends adopting Zero Trust, not using the open-source original directly for mission-critical tasks, and not creating an "omnipotent Agent" with unlimited permissions.

Overall assessment: OpenClaw is a good accelerator for an internal Agent platform, but it is not a ready-made enterprise security kernel. The most reasonable approach is to reuse its channels, sessions, tool ecosystem, and Agent runtime capabilities, while keeping multi-tenancy, identity, authorization, secrets, policies, auditing, evaluation, and high availability in the enterprise's own control plane. For trusted teams and low-risk scenarios, this can significantly shorten time-to-launch; for company-wide, highly regulated, and high-risk action scenarios, the cost of filling in peripheral capabilities may gradually approach rebuilding a controlled Agent Runtime.

4. Mainstream Implementation Patterns¶

4.1 Tool-Calling Loop: The Minimal Core of an Agent¶

The most common core is not complex:

state = initialize(goals, constraints, context, budget)
while not complete and budget not exceeded:
    observation = get current environment and previous step result
    decision = model selection: answer / call tool / modify plan / request approval / delegate
    result = execute decision within permission boundaries
    state = record results, errors, artifacts, and remaining tasks
return final result + verifiable artifacts + execution trace

state = 初始化(目标、约束、上下文、预算)
while 未完成 and 未超出预算:
    observation = 获取当前环境与上一步结果
    decision = 模型选择：回答 / 调工具 / 修改计划 / 请求审批 / 委派
    result = 在权限边界内执行 decision
    state = 记录结果、错误、制品与剩余任务
return 最终结果 + 可验证制品 + 执行轨迹

The truly difficult part is not the loop itself, but how context is selected, whether tool descriptions are accurate, how errors are recovered, whether completion conditions are verifiable, how permissions are restricted, and whether failures are traceable.

4.2 ReAct and Plan-and-Execute¶

• ReAct: performs one reasoning step and one action per round based on the latest observations; flexible and easy to recover, suitable for tasks where the environment changes quickly; the downside is a high number of calls and possible detours.
• Plan-and-Execute: first decomposes the task, then executes step by step with periodic re-planning; suitable for long tasks; the downside is that the initial plan may be built on incorrect assumptions.
• Real products usually mix the two: first generate a coarse-grained plan, then use ReAct within each step, with local re-planning after failures.

4.3 State Graphs and Deterministic Workflows¶

Decomposing tasks into nodes and writing branches, retries, approvals, and exception paths as explicit graphs yields recoverability, testability, and auditability. LangGraph, CrewAI Flows, Microsoft Agent Framework, and enterprise low-code platforms are all moving toward this pattern.

4.4 Manager–Worker Multi-Agent¶

A Manager is responsible for decomposition, dispatch, and aggregation, while multiple Workers execute in parallel using different tools or contexts. It is suitable for:

• Multiple subtasks are independent of each other, and parallelism can reduce wall-clock time;
• Specialized roles need different tools, permissions, or contexts;
• Independent generation and cross-review are needed;
• A single context is too large and information needs to be isolated.

It is not suitable when: tasks are strongly serial, shared state changes frequently, subtasks cannot be independently accepted, or a single strong model call is already sufficient. In such cases, multi-Agent often only adds coordination cost.

4.5 Context Engineering, RAG, Memory, and Skills¶

An Agent's capabilities increasingly depend on "what context it gets at each step," not just the System Prompt:

• RAG provides the external facts needed for the current task;
• Short-term state stores plans, tool results, and unfinished items;
• Long-term memory stores stable preferences and cross-session knowledge, but must prevent contamination and staleness;
• Skills encapsulate domain knowledge, steps, scripts, and resources into on-demand capabilities;
• Context compression summarizes long trajectories into executable task state, reducing cost and attention dilution.

4.6 Sandboxes, Permissions, and Human Approval¶

The risk of an executing Agent comes from its ability to change external state. Mature Harnesses typically adopt:

• A separate container/VM per task, restricting files, network, and system calls;
• Tool allowlists, domain allowlists, and least-privilege credentials;
• Separation of read and write privileges, with mandatory confirmation for actions such as sending, purchasing, deleting, and publishing;
• Limits on rounds, tokens, time, concurrency, and cost;
• Saving commands, tool parameters, page observations, Diffs, and approval traces;
• Isolation and detection of indirect Prompt Injection in web pages, emails, documents, and tool return values.

5. Major Trends After 2026¶

Trend 1: From "Model Products" to "Agent Harness and Runtime"¶

Model capabilities still matter, but product differentiation increasingly comes from code search, browser, sandbox, Checkpoint, Skills, permissions, evaluation, human takeover, and delivery interfaces. The same model placed in different Harnesses can produce very different actual task completion rates.

Trend 2: Programming Agents Move from Copilot to "Delegable Engineering Queues"¶

Interactive IDE Agents will continue to exist, but the faster-growing forms are background tasks, GitHub/CI triggers, batch migrations, automated fixes, and parallel Workers. Engineers' focus will shift from line-by-line code generation to defining tasks, preparing environments, writing acceptance criteria, and reviewing results.

Trend 3: Protocol-Layer Standardization¶

MCP adopts a Host–Client–Server architecture, allowing servers to expose capabilities as Tools, Resources, and Prompts; A2A handles Agent discovery, task delegation, status updates, and Artifact exchange. In the short term, a large number of adapters will appear; in the long term, this will drive standardization of tool, identity, authorization, and audit interfaces.

Trend 4: Long Tasks, Persistent Execution, and Asynchronous Delivery¶

Agents are evolving from a single session into task entities that can be paused, resumed, scheduled, and run in the background. Cloud VMs, persistent file systems, Checkpoints, task Inboxes, and mobile takeover will become standard. But the longer the task, the more severe error accumulation becomes, so intermediate acceptance, budget control, and automatic rollback must be developed in parallel.

Trend 5: Multi-Agent Moves from Demos to "Bounded, Verifiable Parallelization"¶

The value of multi-Agent is mainly parallelism, context isolation, permission isolation, and independent review, not simulating a group of characters in a meeting. OpenAI's model guidance also positions multi-Agent as suitable for complex tasks that can be clearly decomposed, and emphasizes concurrency, stopping conditions, and output evidence. Source

Trend 6: Agentic and Deterministic Convergence¶

Production systems will place LLMs where fuzzy judgment is most valuable: understanding intent, classification, extraction, planning, tool selection, and handling exceptions; while leaving amount calculation, permission decisions, approvals, database transactions, and irreversible operations to deterministic code. In the future, "whether a workflow is an Agent" will no longer matter; what matters is the boundary within which autonomy is placed.

Trend 7: Evaluation Expands from Final Answers to the Entire Trajectory¶

Judging only whether the final statement is correct is not enough; you also need to evaluate wrong tool selection, repeated calls, privilege escalation attempts, ineffective detours, cost, latency, and recovery capability. Tracing, real task sets, reproducible sandboxes, LLM-as-Judge combined with deterministic assertions, and converting failure trajectories into regression test cases will become the standard closed loop for Agent engineering. The OpenAI Agents SDK already incorporates model calls, tools, Handoff, and Guardrail into Trace; Anthropic also emphasizes that modern Agent Evals require clear tasks, stable environments, and complete testing. OpenAI · Anthropic

Trend 8: Security Focus Shifts to Zero Trust Agent¶

Agents read untrusted web pages, emails, code, and documents, while holding real tool permissions, making indirect Prompt Injection a structural risk. The trend is to move the security boundary out of the Prompt: adopting independent policy engines, capability tokens, per-action authorization, data provenance labeling, input/output isolation, confirmation for sensitive actions, network egress control, and continuous red team testing. Anthropic's protection guidance also clearly distinguishes indirect Prompt Injection originating from third-party content.

Trend 9: Cost Optimization Upgrades from "Using Fewer Tokens" to Model and Tool Routing¶

Future Agents will select different models based on the step: strong models handle planning and difficult judgment, small models handle classification and formatting, and code runtimes handle filtering, aggregation, and validation; caching, parallel tool calls, context compression, and staged summarization are also used. Given the same result quality, reducing the number of model turns will be more critical than simply compressing the Prompt.

Trend 10: Vertical Agents and Enterprise Data Closed Loops Outperform General Demos¶

Vertical scenarios such as customer service, sales, R&D, IT operations, financial reconciliation, and legal review have stable data sources, fixed tools, and clear KPIs, making it easier to establish evaluation and ROI. General-purpose Agents will exist as entry points, but the truly scalable value will most likely come from constrained industry Agents and internal organizational Skills.

6. Core Problems Still Unsolved¶

1. Reliability declines with chain length: With 98% correctness per step, the theoretical probability of 30 consecutive steps all being correct is only about 55%. Agents need checkpoints, local validation, and recovery, rather than blindly adding steps.
2. "Completion" is difficult to define: Code has tests, but research, design, and business communication often lack automated criteria, so Agents tend to produce results that look complete but are unusable.
3. Open environments are uncontrollable: Web page changes, expired logins, CAPTCHAs, network fluctuations, and changes in tool return formats can all interrupt long tasks.
4. Permission and identity chains are complex: When a user delegates to an Agent, and the Agent further delegates to sub-Agents, who can do what, on whose behalf, and who bears responsibility still requires unified governance.
5. Prompt Injection has no silver bullet: Relying solely on system prompts cannot serve as a security boundary; browser and email Agents especially need least privilege and human confirmation.
6. Evaluation easily becomes disconnected from real business: General benchmarks can compare models, but enterprises ultimately need their own golden tasks, real environments, and failure cost weights.
7. Cost and latency cannot be ignored: Open-ended planning, multi-Agent discussion, and long contexts rapidly amplify inference costs and response times.

METR's task-completion time horizon study shows that the task length frontier Agents can handle continues to grow, but its page also notes that measurements beyond 16 hours are currently not reliable enough. This indicates the capability curve is rising, but "stably taking over long-term work" still cannot be directly extrapolated from short benchmarks.

7. Selection Recommendations¶

Individual Developers or Small Teams¶

• For daily coding, first compare Codex, Claude Code, Cursor, Gemini CLI, evaluating with your own real repository tasks rather than relying only on public leaderboards.
• If you need a free/open-source entry point and a modifiable CLI, start with Gemini CLI, OpenHands; if you need deep self-hosting and research Harness, focus on OpenHands.
• For browser automation, look for an API first; only if no API exists, use Browser Use/Computer Use, and restrict domains and write operations.

Building Your Own Agent Product¶

• For strong process constraints, pause/resume, and auditability: prioritize LangGraph or Microsoft Agent Framework.
• For rapid role-based multi-Agent prototyping: consider CrewAI, but first verify whether a single Agent is sufficient.
• For lightweight tool calling, Handoff, Guardrail, Tracing, or real-time voice: consider OpenAI Agents SDK.
• If primarily running in the Google Cloud/Gemini ecosystem: consider Google ADK.
• Regardless of which framework you choose, keep domain tools, state models, permission policies, and evaluation sets as portable assets.

Enterprise Deployment¶

It is recommended to proceed in the following order:

1. Select high-frequency processes with clear inputs, outputs, and success criteria;
2. Start with read-only Agents, then open up low-risk write operations;
3. Prioritize API/connectors, with GUI Computer Use as a supplement;
4. Run with least-privilege identities, authorizing each high-risk action individually;
5. Establish real-task evaluation sets, end-to-end Trace, and cost and failure alerts;
6. Only after reaching a stable threshold, add persistent memory, background running, and multi-Agent;
7. Retain human approval for deletion, payments, publishing, outbound messages, and production changes.

8. Final Judgment¶

The development direction of Agents is already fairly clear: models handle understanding and decision-making, tools handle action, sandboxes host execution, state maintains continuity, protocols connect the ecosystem, and evaluation and permissions ensure usability.

Over the next 12–24 months, what deserves the most attention is not how many more "all-purpose Agents" appear, but the following three things:

• Whether coding Agents can stably scale from single tasks to long-cycle engineering collaboration;
• Whether MCP/A2A, identity, and permissions can form truly interoperable Agent infrastructure;
• Whether enterprises can turn Agent success rates, risks, and costs into observable, regression-testable, auditable engineering metrics.

In the short term, the most realistic product form will still be "humans set goals and boundaries, Agents execute most of the process, and humans accept at key checkpoints." Full autonomy will first land in verifiable, rollback-capable closed scenarios, rather than replacing all knowledge work in open environments in one step.

References¶

• OpenAI Developers: Codex and Agent Capabilities
• OpenAI Agents SDK
• OpenAI Model Guidance: Tool Calling and Multi-agent
• Anthropic: Building Effective Agents
• Anthropic: Claude Code
• Cursor Agent Documentation
• Google Gemini CLI
• Cognition Devin Documentation
• OpenHands
• Manus Documentation
• Perplexity Comet
• LangGraph Documentation
• CrewAI Documentation
• Google ADK
• Microsoft Agent Framework
• Model Context Protocol Architecture
• Agent2Agent Protocol
• METR: Task-Completion Time Horizons