AGENT LANDSCAPE

Mapping the Emerging Agent Stack

Track the agents, runtimes, frameworks, and infrastructure shaping AI-native organizations — and understand where each fits through the Agentic Swarm lens.

Where does each type of agent fit inside an intelligent organization?

Landscape updated: October 2026

The Agent Stack

Not every agent product occupies the same layer. Some are end-user agents. Others provide memory, routing, tools, orchestration, execution environments, or infrastructure underneath them.

  1. Models
  2. Agents
  3. Runtimes & Gateways
  4. Orchestration
  5. Tools & Context
  6. Governance & Observation
  7. Organizational Intelligence

An illustrative view, not the only valid architecture. These layers are distinct from the Swarm Loop's organizational capabilities.

Six categories of the agent stack

Categories describe the ecosystem. They are separate from the Swarm Loop capabilities.

Personal & Persistent Agents

Agents designed to work continuously or repeatedly on behalf of an individual across tasks, applications, or connected services.

3 reviewed agents

  • Personal & Persistent Agents

    Muse

    Meta's personal agent helps with everyday tasks and longer-term goals across connected apps.

    Developed by Meta

    • Personal assistant
    • Background work
    • App-connected
    • Multi-agent

    Reviewed · Last reviewed

    View Agent Profile for Muse

    Source-backed facts

    What it does
    Meta's personal agent helps with everyday tasks and longer-term goals across connected apps.
    Architectural role
    Hosted personal agent running in Meta's dedicated Muse Secure VM; it uses Muse Spark and is not a developer framework.
    Primary user
    Individuals delegating personal tasks and goals to an app-connected assistant.
    Interaction model
    Conversational messaging through the Muse app or WhatsApp; Meta's announcement also describes mobile and Mac access.
    Deployment model
    Cloud

    Provenance

    Reviewed

    Agentic Swarm editorial interpretation

    Through the Agentic Swarm Lens
    Context — What information and systems can it access?
    Meta describes connected apps and user data in a dedicated VM. Exact connector availability and access vary by user permissions.
    Memory — What state or memory persists?
    Meta's design account says memory persists across conversations; the launch announcement says Muse remembers details that matter to the user.
    Tools — What tools and external systems can it use?
    Browser, connected services, and a dedicated cloud computer with filesystem and terminal, Meta says Muse can build tools for tasks and launch subagents
    Execution — Where does work actually happen?
    A dedicated cloud VM houses the agent and the user's connected-service data; work can continue after the app closes.
    Autonomy — How independently and for how long can it operate?
    Can advance goals and continue work in the background, including in response to relevant events; Meta says it returns when it needs user input or approval.
    Governance — Where are permissions, approvals, or human decisions required?
    Meta documents permissions and approval before sensitive actions such as sending email or purchases. A universal approval rule for every action is not claimed.
    Observation — How can humans inspect or monitor its work?
    Meta's design account documents an activity log, approved permissions, editable memory files, and a Goals tab showing tracked work and plans.
    Coordination — Can it delegate or participate in multi-agent workflows?
    Meta's security account says Muse can launch concurrent subagents; a user-configurable roster is not documented.
    Control Plane — What manages sessions, routing, tools, and agent state?
    User permissions, a dedicated VM, and Meta's Sentinel-mediated external interactions are documented; an organization-wide administration plane is not.

    Organizational Intelligence Implication

    Muse documents persistent personal context, delegated execution, and user-centered action controls. These can inform an individual's work, but do not establish organizational memory or governance across a team.

    Qualitative architectural relevance, not a score or ranking. Product features contribute to organizational capabilities; they do not replace them.

    Where it fits in the Swarm Loop

    Governance
    Relevant — User permissions and approvals bound sensitive agent actions, not organization-wide governance.
    Planning
    Strong relevance — Meta describes translating personal goals into plans and advancing them.
    Memory
    Strong relevance — Memory persists across conversations and supports personal context.
    Routing
    Not documented — The reviewed sources do not establish this organizational capability.
    Execution
    Strong relevance — Muse performs multi-step work in apps and on the web.
    Observation
    Relevant — The activity log and Goals tab support inspection of work, permissions, and plans.
    Learning
    Not documented — The reviewed sources do not establish this organizational capability.
    Simulation
    Not documented — The reviewed sources do not establish this organizational capability.

  • Personal & Persistent Agents

    Instinct

    Instinct's AI personal assistant plans and acts to help users complete everyday tasks.

    Developed by Spear Street Technology, Inc. (Instinct)

    • Personal assistant
    • Connected services
    • Task execution

    Reviewed · Last reviewed

    View Agent Profile for Instinct

    Source-backed facts

    What it does
    Instinct's AI personal assistant plans and acts to help users complete everyday tasks.
    Architectural role
    Personal assistant service operated by Spear Street Technology, Inc.; public sources describe a service and companion apps, not a framework.
    Primary user
    Adults (18+) seeking assistance with personal tasks through the Instinct service.
    Interaction model
    The service includes a website and related Mac and mobile applications; exact interaction surfaces were not fully verifiable during this review.

    Provenance

    Reviewed

    Agentic Swarm editorial interpretation

    Through the Agentic Swarm Lens
    Context — What information and systems can it access?
    The privacy policy says the assistant may use information the user shares or makes available through connected applications and accounts, depending on permissions.
    Memory — What state or memory persists?
    The privacy policy permits personalized suggestions based on interaction context and prior service experience; a persistent, inspectable memory feature is not documented.
    Tools — What tools and external systems can it use?
    Terms describe interactions with third-party services connected by the user, The privacy policy identifies connected applications, messages, documents, and other user-provided or integration data
    Execution — Where does work actually happen?
    Not documented
    Autonomy — How independently and for how long can it operate?
    The privacy policy says the assistant thinks, plans, and acts when engaged; precise autonomy settings and duration are not documented.
    Governance — Where are permissions, approvals, or human decisions required?
    Terms authorize actions on connected services, but do not document a guaranteed per-action approval workflow. Permission and confirmation controls are not described in sufficient detail to claim a universal human gate.
    Observation — How can humans inspect or monitor its work?
    The terms advise users to review and monitor actions; a product audit trail or reliable action-history interface is not documented.
    Coordination — Can it delegate or participate in multi-agent workflows?
    Multi-agent coordination is not documented in the reviewed legal sources.
    Control Plane — What manages sessions, routing, tools, and agent state?
    Access is conditioned on permissions users grant, but a user-facing policy, session, or organization management plane is not documented.

    Organizational Intelligence Implication

    Instinct's legal materials support personal task execution through connected services. They do not establish shared organizational memory, routing, auditability, or governance controls.

    Qualitative architectural relevance, not a score or ranking. Product features contribute to organizational capabilities; they do not replace them.

    Where it fits in the Swarm Loop

    Governance
    Not documented — The reviewed sources do not establish this organizational capability.
    Planning
    Not documented — The reviewed sources do not establish this organizational capability.
    Memory
    Not documented — The reviewed sources do not establish this organizational capability.
    Routing
    Not documented — The reviewed sources do not establish this organizational capability.
    Execution
    Relevant — The terms describe an AI assistant acting on connected services for users.
    Observation
    Not documented — The reviewed sources do not establish this organizational capability.
    Learning
    Not documented — The reviewed sources do not establish this organizational capability.
    Simulation
    Not documented — The reviewed sources do not establish this organizational capability.

  • Personal & Persistent Agents

    Dots

    OpenAI's Dots are persistent personal agents that work across connected apps and ongoing tasks, returning results and decisions for user review.

    Developed by OpenAI

    • Persistent personal agent
    • Background work
    • Connected apps
    • Action review

    Reviewed · Last reviewed

    View Agent Profile for Dots

    Source-backed facts

    What it does
    OpenAI's Dots are persistent personal agents that work across connected apps and ongoing tasks, returning results and decisions for user review.
    Architectural role
    Hosted, persistent personal agent in ChatGPT with its own cloud computer, connected apps, and background task execution.
    Primary user
    Eligible ChatGPT users delegating ongoing personal or work tasks to an always-on agent.
    Interaction model
    Create a dot in ChatGPT desktop or desktop web, then message or call it in ChatGPT and supported connected channels such as Slack or Teams.
    Release stage
    Rolling Out
    Source terms
    A managed ChatGPT product; a separate Dots product-source license is not documented in the reviewed sources.
    Deployment model
    Cloud

    Provenance

    Reviewed

    Agentic Swarm editorial interpretation

    Through the Agentic Swarm Lens
    Context — What information and systems can it access?
    Dots use task instructions, relevant prior conversation and preference context, and apps or computers the user explicitly connects. Access is rolling out to Pro users outside the EEA, Switzerland, and UK, and to Business Premium users in supported regions; Enterprise, Edu, and Healthcare workspaces can try the beta when an admin enables it. App access and connected-computer access are separate permissions.
    Memory — What state or memory persists?
    OpenAI documents use of relevant context from prior conversations and user preferences for ongoing work; a separate inspectable user-managed memory store is not documented.
    Tools — What tools and external systems can it use?
    Each dot has a cloud computer and browser; connected plugins provide selected app data and actions. A user may connect a computer for local work; coding tasks may use a configured Codex cloud environment. Dots can split work into parallel background agents and threads, then report progress and results.
    Execution — Where does work actually happen?
    Work runs in OpenAI's cloud computer and browser, which can retain state between uses; users may separately connect their own computer for local work.
    Autonomy — How independently and for how long can it operate?
    Dots can continue work between conversations, pursue multiple responsibilities, and work in the background; users can redirect tasks and respond to decisions or approval requests.
    Governance — Where are permissions, approvals, or human decisions required?
    Built-in action review checks instructions, connected-app permissions, custom rules, and safety requirements. An action can proceed, require approval, or be handed to the user; access is not granted by a custom rule alone.
    Observation — How can humans inspect or monitor its work?
    Activity view exposes background task progress, files, and results; users can inspect work, redirect tasks, and respond to requests for decisions, sign-in, or approval.
    Coordination — Can it delegate or participate in multi-agent workflows?
    Dots can assign work to parallel background agents and maintain separate visible threads; this is a Dots product feature, not the OpenAI Agents API.
    Control Plane — What manages sessions, routing, tools, and agent state?
    Users manage app connections through ChatGPT permissions, task instructions, optional custom rules, and Activity review. Availability and workspace controls depend on plan, market, and admin settings.

    Organizational Intelligence Implication

    Dots can carry personal responsibilities across apps and conversations while exposing ongoing work for user direction and review. Availability and governance are bounded by ChatGPT plan, region, workspace administration, app permissions, and action review; this is not evidence of an organization-wide control plane.

    Qualitative architectural relevance, not a score or ranking. Product features contribute to organizational capabilities; they do not replace them.

    Where it fits in the Swarm Loop

    Governance
    Relevant — App permissions, custom rules, built-in review, and required user decisions constrain actions.
    Planning
    Relevant — Dots can carry ongoing responsibilities forward, prioritize work, and seek input for decisions.
    Memory
    Relevant — Prior conversation and preference context can inform ongoing work; a separate organizational memory store is not documented.
    Routing
    Relevant — Dots can distribute work among background agents and threads, with the dot coordinating results.
    Execution
    Strong relevance — A persistent cloud computer and connected apps let Dots carry out multi-step tasks.
    Observation
    Relevant — Activity view provides progress and result inspection for ongoing work.
    Learning
    Not documented — The reviewed sources do not establish this organizational capability.
    Simulation
    Not documented — The reviewed sources do not establish this organizational capability.

Specialized & Team Agents

Agents designed around a specific role, function, team, or recurring organizational responsibility.

1 reviewed agent

  • Specialized & Team Agents

    Grok Bot

    Named AI teammates perform multi-step work across apps and websites using a persistent cloud computer.

    Developed by xAI

    • AI teammates
    • Persistent computer
    • Multi-agent
    • Workflow automation

    Reviewed · Last reviewed

    View Agent Profile for Grok Bot

    Source-backed facts

    What it does
    Named AI teammates perform multi-step work across apps and websites using a persistent cloud computer.
    Architectural role
    Hosted team-agent product: named Bots operate on a shared, persistent cloud computer rather than as isolated machines per Bot.
    Primary user
    Individuals and teams delegating specialist or recurring work to named Bots.
    Interaction model
    Users message Bots through desktop or mobile apps; docs also describe dictation, voice chat, and group conversations.
    Release stage
    Beta
    Deployment model
    Cloud

    Provenance

    Reviewed

    Agentic Swarm editorial interpretation

    Through the Agentic Swarm Lens
    Context — What information and systems can it access?
    Bots can use connected apps and computer interaction; Bots in one account share files, browser sessions, and app logins on the same computer.
    Memory — What state or memory persists?
    Named Bots retain their context and preferences across sessions; conversations are Bot-specific while files, browser sessions, and logins are shared among the account's Bots.
    Tools — What tools and external systems can it use?
    Persistent computer with browser, filesystem, and terminal, Connectors where available, and computer use for other apps and websites, Reusable skills and scheduled or supported event-triggered routines
    Execution — Where does work actually happen?
    Work runs on the account's persistent cloud computer and continues when the user's device is closed.
    Autonomy — How independently and for how long can it operate?
    Bots can continue background work and run saved routines; action permissions and Auto Review rules can be configured.
    Governance — Where are permissions, approvals, or human decisions required?
    Docs describe Allow once, Always allow, and Deny, plus configurable Auto Review rules. These controls are configurable, not a universal default block on consequential actions.
    Observation — How can humans inspect or monitor its work?
    Conversation transcripts show tool/computer activity, files, questions, and approval requests; routine details and recent run outcomes are viewable.
    Coordination — Can it delegate or participate in multi-agent workflows?
    Bots can work in parallel, message each other, share context, coordinate in group chats, and hand off task ownership.
    Control Plane — What manages sessions, routing, tools, and agent state?
    Users manage Bot profiles, access, routines, and Auto Review; team-admin enforced Auto Review rules are documented. Bots share one account computer.

    Organizational Intelligence Implication

    Grok Bot combines durable task context, parallel role-based work, configurable action review, and visible run activity. Shared computer state is an important boundary: Bots on one account are not isolated from one another.

    Qualitative architectural relevance, not a score or ranking. Product features contribute to organizational capabilities; they do not replace them.

    Where it fits in the Swarm Loop

    Governance
    Relevant — Action approvals and configurable Auto Review provide product-level controls.
    Planning
    Relevant — Named Bots can own recurring work through reusable skills and routines.
    Memory
    Relevant — Bot context and preferences persist, while the computer's files and sessions are shared.
    Routing
    Relevant — Bots can hand off work and coordinate without the user acting as the sole router.
    Execution
    Strong relevance — Bots act across apps and websites on a persistent computer.
    Observation
    Relevant — Conversation activity and routine outcomes can be inspected.
    Learning
    Not documented — The reviewed sources do not establish this organizational capability.
    Simulation
    Not documented — The reviewed sources do not establish this organizational capability.

Coding Agents

Agents specialized in software engineering, code modification, testing, debugging, refactoring, and development workflows.

2 reviewed agents

  • Coding Agents

    OpenAI Codex

    Codex inspects, edits, and runs repository code locally or in configured cloud workspaces.

    Developed by OpenAI

    • Cloud coding tasks
    • Local CLI
    • Parallel work
    • Developer review

    Reviewed · Last reviewed

    View Agent Profile for OpenAI Codex

    Source-backed facts

    What it does
    Codex inspects, edits, and runs repository code locally or in configured cloud workspaces.
    Architectural role
    Coding-agent product family spanning a local CLI, IDE/web surfaces, and cloud coding tasks.
    Primary user
    Developers working in a repository through Codex Cloud, the CLI, or an IDE integration.
    Interaction model
    Give Codex a task in ChatGPT or an IDE, or start it from a local terminal; cloud task results can be reviewed and continued from supported surfaces.
    Source terms
    Source terms vary by component: CLI is Apache-2.0; OpenAI says the IDE extension and Codex web are not open source. No single license is assigned to the entire cloud service.
    Deployment model
    Varies

    Provenance

    Reviewed

    Agentic Swarm editorial interpretation

    Through the Agentic Swarm Lens
    Context — What information and systems can it access?
    Cloud tasks use selected repositories and a published environment; CLI tasks work in the selected local project. Persistent learned context shared across separate tasks is not documented.
    Memory — What state or memory persists?
    Task context and saved CLI chats are documented; durable learned memory shared across distinct CLI or cloud tasks is not documented.
    Tools — What tools and external systems can it use?
    Cloud environments provide configured repositories, dependencies, tools, and service access, The CLI can inspect and edit files, run local commands, use MCP servers, and resume saved chats, Codex can use subagents for parallel work
    Execution — Where does work actually happen?
    Cloud tasks run in task-specific configured workspaces; CLI execution is local on the user's computer. Codex is not one deployment model.
    Autonomy — How independently and for how long can it operate?
    Cloud tasks can continue asynchronously while the user's computer sleeps and may run in parallel. CLI permissions are configurable.
    Governance — Where are permissions, approvals, or human decisions required?
    CLI users choose permissions. Cloud users inspect changed files and test results, request follow-up work, and decide whether to commit or open a pull request; automatic merging is not claimed.
    Observation — How can humans inspect or monitor its work?
    Cloud results include changed files and check results for review; CLI users can inspect repository changes and command output.
    Coordination — Can it delegate or participate in multi-agent workflows?
    Cloud tasks can run in parallel; the CLI documents subagents for parallelizing complex work.
    Control Plane — What manages sessions, routing, tools, and agent state?
    Cloud task environments are configured with repositories, tools, and access; CLI users configure local permissions. A single control plane across all Codex surfaces is not documented.

    Organizational Intelligence Implication

    Codex contributes repository execution and reviewable outputs, with configurable local permissions and parallel task options. These capabilities do not imply a unified policy or memory system across its distinct product surfaces.

    Qualitative architectural relevance, not a score or ranking. Product features contribute to organizational capabilities; they do not replace them.

    Where it fits in the Swarm Loop

    Governance
    Relevant — CLI permission settings and user review of cloud changes provide product-level controls.
    Planning
    Relevant — Parallel cloud tasks and CLI subagents support task decomposition, without establishing organization-wide planning.
    Memory
    Not documented — The reviewed sources do not establish this organizational capability.
    Routing
    Not documented — The reviewed sources do not establish this organizational capability.
    Execution
    Strong relevance — Codex reads, edits, and runs code in local or cloud environments.
    Observation
    Relevant — Changed files and test results let developers inspect task outcomes.
    Learning
    Not documented — The reviewed sources do not establish this organizational capability.
    Simulation
    Not documented — The reviewed sources do not establish this organizational capability.

  • Coding Agents

    Cursor Cloud Agents

    Cloud agents work in configured development environments to build, test, and return software changes.

    Developed by Cursor

    • Cloud coding agents
    • Isolated VMs
    • MCP tools
    • Parallel runs

    Reviewed · Last reviewed

    View Agent Profile for Cursor Cloud Agents

    Source-backed facts

    What it does
    Cloud agents work in configured development environments to build, test, and return software changes.
    Architectural role
    Managed remote coding agents that run in isolated cloud VMs; Cursor also documents self-hosted machines as a separate execution option.
    Primary user
    Developers and teams delegating repository work from Cursor or connected work tools.
    Interaction model
    Start agents from Cursor web, desktop, iOS, Slack, GitHub, Bitbucket, Linear, or the API; changes are pushed on a separate branch.
    Deployment model
    Varies

    Provenance

    Reviewed

    Agentic Swarm editorial interpretation

    Through the Agentic Swarm Lens
    Context — What information and systems can it access?
    Agents clone configured repositories and use installed dependencies, environment settings, secrets, and network access.
    Memory — What state or memory persists?
    Repository, environment, and current-run context are documented; persistent learned memory across runs is not documented.
    Tools — What tools and external systems can it use?
    Agents can build and test software, use a remote desktop/browser, and access configured MCP servers, Multi-repository environments let an agent work across related repositories
    Execution — Where does work actually happen?
    Cursor-managed isolated cloud VMs by default; Cursor documents self-hosted machines for execution on customer-managed hardware. Current docs say long-running is not available.
    Autonomy — How independently and for how long can it operate?
    Agents work remotely, can build/test/verify changes, and can run in parallel; the cloud-agent docs state long-running is not available.
    Governance — Where are permissions, approvals, or human decisions required?
    Changes are handed back on a separate branch for review. Separate PR Routing & Approval can approve low-risk pull requests under configured criteria; that is not a blanket policy for every agent action.
    Observation — How can humans inspect or monitor its work?
    The dashboard exposes run environment details; agents can use the remote desktop/browser to verify changes, and return changes on a branch.
    Coordination — Can it delegate or participate in multi-agent workflows?
    Multiple agents can run in parallel and a single agent can work across repositories; agent-to-agent handoffs are not documented.
    Control Plane — What manages sessions, routing, tools, and agent state?
    Cursor manages VM provisioning, isolation, snapshots, startup, artifacts, and capacity; admins configure source-control connections, environments, secrets, and network controls.

    Organizational Intelligence Implication

    Cursor Cloud Agents provide managed remote execution and a review handoff, while environment and network controls shape the agent's access. Parallel runs are documented; persistent cross-run memory and agent-to-agent coordination are not.

    Qualitative architectural relevance, not a score or ranking. Product features contribute to organizational capabilities; they do not replace them.

    Where it fits in the Swarm Loop

    Governance
    Relevant — Branch review and optional PR approval policies provide specific review controls.
    Planning
    Not documented — The reviewed sources do not establish this organizational capability.
    Memory
    Not documented — The reviewed sources do not establish this organizational capability.
    Routing
    Relevant — The separate PR Routing & Approval feature directs reviews to reviewers.
    Execution
    Strong relevance — Agents edit, build, test, and return repository changes.
    Observation
    Relevant — Run environment details, browser verification, and returned changes support inspection.
    Learning
    Not documented — The reviewed sources do not establish this organizational capability.
    Simulation
    Not documented — The reviewed sources do not establish this organizational capability.

Agent Runtimes & Gateways

Persistent environments that run, coordinate, route, and equip agents with context, tools, memory, sessions, and execution surfaces.

2 reviewed agents

  • Agent Runtimes & Gateways

    Hermes Agent

    Nous Research's tool-using agent runs through a configurable CLI or gateway, retaining curated memory and reusable skills across sessions.

    Developed by Nous Research

    • Persistent memory
    • Reusable skills
    • Scheduled automation
    • Messaging gateway

    Reviewed · Last reviewed

    View Agent Profile for Hermes Agent

    Source-backed facts

    What it does
    Nous Research's tool-using agent runs through a configurable CLI or gateway, retaining curated memory and reusable skills across sessions.
    Architectural role
    Configurable, self-hosted agent runtime with a messaging gateway, persistent memory, reusable skills, and scheduled work.
    Primary user
    People configuring an agent for local use, automation, or connected messaging platforms.
    Interaction model
    Use Hermes through its CLI or desktop app, or connect the background gateway to supported messaging platforms.
    Source model
    Open Source
    Source terms
    The official Hermes Agent repository uses the MIT license.
    Deployment model
    Self-hosted

    Provenance

    Reviewed

    Agentic Swarm editorial interpretation

    Through the Agentic Swarm Lens
    Context — What information and systems can it access?
    The agent uses its current conversation, configured workspace and tools, profile context, and bounded memory. MCP servers can expose additional configured context and capabilities.
    Memory — What state or memory persists?
    MEMORY.md and USER.md are bounded, curated files stored under the Hermes home and loaded into the prompt at session start; session search can retrieve prior-session context.
    Tools — What tools and external systems can it use?
    The official tool reference documents terminal, browser, web, memory, scheduling, and other tools; availability depends on configuration and environment. Configured local stdio or remote HTTP MCP servers can supply external tools; per-server filtering is supported. Reusable skills are on-demand instructions that Hermes can create or modify.
    Execution — Where does work actually happen?
    Runs in operator-managed CLI/desktop and gateway environments, which may be a local computer, VPS, or other configured host. Tools execute within the configured host or sandbox.
    Autonomy — How independently and for how long can it operate?
    Hermes can work through configured tools, create or improve skills, schedule unattended jobs, and use configured Bots or subagents; actual behavior depends on model, configuration, and permissions.
    Governance — Where are permissions, approvals, or human decisions required?
    Dangerous shell commands have configurable smart, manual, or off modes. The documented default is smart; unattended, cron, and one-shot modes default to deny when approval cannot be requested.
    Observation — How can humans inspect or monitor its work?
    Users can inspect sessions, tool activity, and job results through supported CLI, desktop, and gateway surfaces; the sources do not establish a single hosted observability service.
    Coordination — Can it delegate or participate in multi-agent workflows?
    Hermes supports configured subagents and named Bots; Bots can have separate profiles and coordinate through routines or messaging features.
    Control Plane — What manages sessions, routing, tools, and agent state?
    The operator configures the Hermes home/profile, models, tools, memory, approvals, jobs, and connected messaging gateway; Nous does not manage the deployed runtime.

    Organizational Intelligence Implication

    Hermes combines local or operator-hosted control with cross-session memory, reusable skills, and scheduled work. Those features can support repeated workflows, while permissions, approval policies, and separation between people or Bots depend on deployment and configuration.

    Qualitative architectural relevance, not a score or ranking. Product features contribute to organizational capabilities; they do not replace them.

    Where it fits in the Swarm Loop

    Governance
    Relevant — Configurable dangerous-command approvals and unattended defaults provide operator-level controls.
    Planning
    Relevant — Scheduled tasks and configured delegation can organize recurring work, with scope determined by the operator.
    Memory
    Strong relevance — Curated memory files persist across sessions and can be searched alongside session history.
    Routing
    Not documented — The reviewed sources do not establish this organizational capability.
    Execution
    Strong relevance — The runtime can invoke configured tools and scheduled tasks in its host environment.
    Observation
    Not documented — The reviewed sources do not establish this organizational capability.
    Learning
    Relevant — The agent can create and improve reusable skills; organizational review and adoption remain external.
    Simulation
    Not documented — The reviewed sources do not establish this organizational capability.

  • Agent Runtimes & Gateways

    OpenClaw

    OpenClaw runs a configurable personal AI agent through a persistent Gateway that connects messaging channels, clients, sessions, and tools.

    Stewarded by OpenClaw Foundation

    • Persistent gateway
    • Multi-channel routing
    • Workspace memory
    • Configurable tools

    Reviewed · Last reviewed

    View Agent Profile for OpenClaw

    Source-backed facts

    What it does
    OpenClaw runs a configurable personal AI agent through a persistent Gateway that connects messaging channels, clients, sessions, and tools.
    Architectural role
    Self-hosted personal agent runtime and long-lived Gateway for channel connections, routing, sessions, tools, and control.
    Primary user
    Individuals and trusted teams operating their own agent runtime and connected services.
    Interaction model
    Install and configure OpenClaw on a host, then interact through connected messaging channels, the CLI, or its web Control UI.
    Source model
    Open Source
    Source terms
    The official project repository is MIT-licensed; the license identifies the OpenClaw Foundation as copyright holder.
    Deployment model
    Self-hosted

    Provenance

    Reviewed

    Agentic Swarm editorial interpretation

    Through the Agentic Swarm Lens
    Context — What information and systems can it access?
    Agents use configured workspaces, sessions, channel conversations, and explicitly connected tools or services. Access depends on the selected agent, channel policy, plugins, and host configuration.
    Memory — What state or memory persists?
    Workspace files provide durable memory: USER.md and MEMORY.md load at session start, daily notes hold working context, and configured search can retrieve indexed notes. Session histories and memory are associated with agents.
    Tools — What tools and external systems can it use?
    The runtime supports configured built-in tools and plugins; skills are markdown instructions that teach agents how and when to use tools. Channel plugins connect messaging services; automation supports scheduled work and event-driven hooks.
    Execution — Where does work actually happen?
    OpenClaw runs on an operator-managed computer or server as a persistent Gateway process; agents use configured workspaces and tools on that host or in configured environments.
    Autonomy — How independently and for how long can it operate?
    A running Gateway can serve connected channels and configured automations continuously. What an agent may do depends on enabled tools, policies, access controls, and host security.
    Governance — Where are permissions, approvals, or human decisions required?
    Gateway security docs describe conservative defaults such as loopback binding, pairing for unknown DMs, and group allowlists. Tool access and approval behavior are configurable; a universal per-action human approval gate is not documented.
    Observation — How can humans inspect or monitor its work?
    The Gateway exposes health, status, logs, session history, and typed events for clients and control surfaces; these do not by themselves guarantee a complete organizational audit trail.
    Coordination — Can it delegate or participate in multi-agent workflows?
    One Gateway can host multiple isolated agents with separate workspaces, state directories, and session histories; bindings route incoming channel accounts to agents.
    Control Plane — What manages sessions, routing, tools, and agent state?
    The long-lived Gateway is the routing and control plane for channel connections, clients, sessions, APIs, and control UI; operators configure it and its agents on their own host.

    Organizational Intelligence Implication

    OpenClaw brings persistent runtime, channel routing, and agent state under an operator-managed Gateway. This can make tools and context available across recurring interactions, but creates a shared trust boundary: organizations must separate untrusted users and configure access, tool permissions, and review policies deliberately.

    Qualitative architectural relevance, not a score or ranking. Product features contribute to organizational capabilities; they do not replace them.

    Where it fits in the Swarm Loop

    Governance
    Relevant — Pairing, allowlists, tool policies, and host security constrain access, but require configuration.
    Planning
    Not documented — The reviewed sources do not establish this organizational capability.
    Memory
    Strong relevance — Workspace memory files persist across sessions, with daily notes and search supporting retrieval.
    Routing
    Strong relevance — Gateway bindings route channel accounts and messages to configured agents.
    Execution
    Strong relevance — Agents invoke configured tools and automations on operator-managed infrastructure.
    Observation
    Relevant — Gateway health, logs, sessions, and events expose operational evidence; full audit remains external.
    Learning
    Not documented — The reviewed sources do not establish this organizational capability.
    Simulation
    Not documented — The reviewed sources do not establish this organizational capability.

Agent Infrastructure

Developer infrastructure that provides execution, identity, memory, permissions, tools, protocols, evaluation, observability, or other foundational agent capabilities.

2 reviewed agents

  • Agent Infrastructure

    Model Context Protocol (MCP)

    An open protocol that lets AI applications connect to external data sources, prompts, and callable tools.

    Stewarded by Agentic AI Foundation (AAIF), under the Linux Foundation

    • Open protocol
    • Tool connections
    • Context exchange
    • Host-controlled consent

    Reviewed · Last reviewed

    View Agent Profile for Model Context Protocol (MCP)

    Source-backed facts

    What it does
    An open protocol that lets AI applications connect to external data sources, prompts, and callable tools.
    Architectural role
    Open protocol standardizing connections between AI application hosts and external context and tool servers.
    Primary user
    Developers building AI applications, connectors, and MCP servers.
    Interaction model
    An application host connects clients to servers through protocol requests; the host decides how to present and invoke server capabilities.
    Source model
    Open Source
    Source terms
    The project license is transitioning: new specification and code contributions use Apache-2.0, documentation other than specifications uses CC-BY-4.0, and some older contributions remain MIT.
    Deployment model
    Varies

    Provenance

    Reviewed

    Agentic Swarm editorial interpretation

    Through the Agentic Swarm Lens
    Context — What information and systems can it access?
    Servers can expose resources and prompts; the host application selects and supplies relevant context. MCP does not grant access to systems by itself.
    Memory — What state or memory persists?
    MCP does not provide an agent memory store. Resource access is not persistent memory or learning.
    Tools — What tools and external systems can it use?
    Servers can expose tools, resources, and prompts; protocol utilities include progress, cancellation, and error reporting. The current specification is stateless at its core; optional extensions add capabilities such as asynchronous tasks.
    Execution — Where does work actually happen?
    MCP defines communication between hosts, clients, and servers, not where an agent runs. Servers may be connected through local or remote transports.
    Autonomy — How independently and for how long can it operate?
    MCP is not an autonomous agent; the host decides when to invoke a connected capability.
    Governance — Where are permissions, approvals, or human decisions required?
    The specification says users must consent to and understand data access and operations. The host implements the UI and enforcement; MCP alone cannot ensure a host follows the requirement.
    Observation — How can humans inspect or monitor its work?
    Progress, cancellation, and error reporting are protocol utilities; MCP itself does not establish a complete audit trail.
    Coordination — Can it delegate or participate in multi-agent workflows?
    Connects applications and servers; it does not define agent teams or agent-to-agent delegation.
    Control Plane — What manages sessions, routing, tools, and agent state?
    No central MCP control plane. The host manages its clients and connections; each server implements its own capabilities and access behavior.

    Organizational Intelligence Implication

    A shared protocol can make context and tools easier to connect across applications. Organizations still need to select trusted servers, define scoped permissions, implement consent and approval flows, and retain their own records of consequential actions.

    Qualitative architectural relevance, not a score or ranking. Product features contribute to organizational capabilities; they do not replace them.

    Where it fits in the Swarm Loop

    Governance
    Relevant — The specification sets consent and user-control principles, but enforcement remains with each host.
    Planning
    Not documented — The reviewed sources do not establish this organizational capability.
    Memory
    Not documented — The reviewed sources do not establish this organizational capability.
    Routing
    Not documented — The reviewed sources do not establish this organizational capability.
    Execution
    Relevant — MCP standardizes tool invocation, while the host and server determine whether and how effects occur.
    Observation
    Limited / external — Progress and errors can be reported; complete operational audit and traceability require separate systems.
    Learning
    Not documented — The reviewed sources do not establish this organizational capability.
    Simulation
    Not documented — The reviewed sources do not establish this organizational capability.

  • Agent Infrastructure

    OpenAI Agents API

    OpenAI's Agents API gives developer applications access to a managed Codex harness for running agent tasks.

    Developed by OpenAI

    • Managed Codex harness
    • Durable sessions
    • Sandbox execution
    • Subagent orchestration

    Reviewed · Last reviewed

    View Agent Profile for OpenAI Agents API

    Source-backed facts

    What it does
    OpenAI's Agents API gives developer applications access to a managed Codex harness for running agent tasks.
    Architectural role
    Managed agent infrastructure exposing OpenAI's Codex harness and session orchestration through an API.
    Primary user
    Developers integrating long-running agents into their applications.
    Interaction model
    An application creates a configured session, sends input, receives streamed events or webhooks, and can continue or steer the work.
    Release stage
    Beta
    Source terms
    The API is a managed service with an open-source Codex harness. A standalone source license for the hosted service is not documented in the reviewed sources.
    Deployment model
    Varies

    Provenance

    Reviewed

    Agentic Swarm editorial interpretation

    Through the Agentic Swarm Lens
    Context — What information and systems can it access?
    Each agent uses developer-supplied instructions, inputs, tools, and its configured execution environment; connected data depends on the application's tools and MCP servers.
    Memory — What state or memory persists?
    A durable session retains turns and items; OpenAI documents context compaction and recovery. Cross-session user-profile or learned memory is not documented.
    Tools — What tools and external systems can it use?
    The harness supports application tools and MCP servers, with optional sandbox operations such as running code and editing files. The application chooses an OpenAI-hosted sandbox, a self-hosted sandbox, or no sandbox.
    Execution — Where does work actually happen?
    The harness is managed by OpenAI; code and file work can run in an OpenAI-hosted or self-hosted sandbox, or with no sandbox.
    Autonomy — How independently and for how long can it operate?
    The managed harness can continue long-running work, be steered, and delegate parallel subtasks when multi-agent orchestration is enabled.
    Governance — Where are permissions, approvals, or human decisions required?
    Approval behavior is application-specific; the Agents API overview does not document a general built-in approval policy.
    Observation — How can humans inspect or monitor its work?
    Applications can stream session output and events or use webhooks to learn when work completes or needs input.
    Coordination — Can it delegate or participate in multi-agent workflows?
    When enabled, the harness can create, message, wait for, and interrupt subagents that work in parallel with separate context.
    Control Plane — What manages sessions, routing, tools, and agent state?
    The application configures agents, tools, environments, and sessions; OpenAI manages session state, orchestration, context compaction, and recovery.

    Organizational Intelligence Implication

    The managed harness can reduce the infrastructure an application must build for persistent sessions, execution, and delegation. Organizational context, tool permissions, approval policy, and accountability remain substantially shaped by the integrating application.

    Qualitative architectural relevance, not a score or ranking. Product features contribute to organizational capabilities; they do not replace them.

    Where it fits in the Swarm Loop

    Governance
    Not documented — The reviewed sources do not establish this organizational capability.
    Planning
    Relevant — The managed harness can decompose work into subtasks and coordinate subagents.
    Memory
    Relevant — Durable session state and context compaction preserve task continuity, not documented cross-session user memory.
    Routing
    Not documented — The reviewed sources do not establish this organizational capability.
    Execution
    Strong relevance — The API runs agent work and can provide sandboxed code and file execution.
    Observation
    Relevant — Streamed events and webhooks expose run progress and completion to the application.
    Learning
    Not documented — The reviewed sources do not establish this organizational capability.
    Simulation
    Not documented — The reviewed sources do not establish this organizational capability.

Multi-Agent & Orchestration

Frameworks and systems used to coordinate multiple agents, route work, delegate tasks, manage handoffs, or control agent-to-agent execution.

1 reviewed agent

  • Multi-Agent & Orchestration

    Google Agent Development Kit (ADK)

    Google ADK lets developers define agents, tools, workflows, and context services for applications they build.

    Developed by Google

    • Agent framework
    • Multi-agent workflows
    • Configurable orchestration
    • Session and memory services

    Reviewed · Last reviewed

    View Agent Profile for Google Agent Development Kit (ADK)

    Source-backed facts

    What it does
    Google ADK lets developers define agents, tools, workflows, and context services for applications they build.
    Architectural role
    Open-source, code-first framework for building, debugging, evaluating, and deploying agents and multi-agent workflows; it is not itself a hosted end-user agent.
    Primary user
    Developers building and deploying agent applications.
    Interaction model
    Developers define agents, tools, and workflow structures; the end-user experience depends on the application.
    Source model
    Open Source
    Source terms
    Google's ADK Python repository uses Apache-2.0. This does not establish the licensing of models or hosted deployment services.
    Deployment model
    Varies

    Provenance

    Reviewed

    Agentic Swarm editorial interpretation

    Through the Agentic Swarm Lens
    Context — What information and systems can it access?
    Agent instructions, session events/state, and searchable cross-session memory are available when the application configures the corresponding services.
    Memory — What state or memory persists?
    ADK distinguishes current-session Session/State from searchable cross-session Memory. Persistence depends on the selected service; in-memory data is lost when the application restarts.
    Tools — What tools and external systems can it use?
    Agents can use optional prebuilt or custom tools and integrations, Workflow compositions include agents and executable nodes, with developer-defined control flow
    Execution — Where does work actually happen?
    Deployment is application-configured; official docs describe local development and deployment options including Google Cloud Agent Runtime and Cloud Run.
    Autonomy — How independently and for how long can it operate?
    The developer configures agent behavior and orchestration, from individual agents to sequential, loop, parallel, graph, and collaborative patterns.
    Governance — Where are permissions, approvals, or human decisions required?
    A default built-in human-approval policy is not documented in the reviewed ADK guides.
    Observation — How can humans inspect or monitor its work?
    Callbacks provide logging/monitoring hooks and ADK documents agent evaluation; actual observability depends on the application and configured services.
    Coordination — Can it delegate or participate in multi-agent workflows?
    ADK supports composed multi-agent workflows, including parallel execution and a coordinator agent with subagents. Agent routing is documented as experimental.
    Control Plane — What manages sessions, routing, tools, and agent state?
    The developer selects model, tools, workflow, session/memory services, and deployment environment; ADK does not provide one mandatory hosted control plane.

    Organizational Intelligence Implication

    ADK makes orchestration and context services design choices for the application developer. It can support coordinated agent work and evidence gathering, but does not itself impose organization-wide approval, memory, or control-plane policy.

    Qualitative architectural relevance, not a score or ranking. Product features contribute to organizational capabilities; they do not replace them.

    Where it fits in the Swarm Loop

    Governance
    Not documented — The reviewed sources do not establish this organizational capability.
    Planning
    Relevant — Developers compose task workflows from agents and executable nodes.
    Memory
    Relevant — Session and searchable cross-session memory services can be configured.
    Routing
    Relevant — Composed workflows and experimental agent routing can direct tasks among agents.
    Execution
    Strong relevance — The framework builds and deploys agents and executable workflow nodes.
    Observation
    Relevant — Callbacks and evaluation support monitoring and examining agent behavior.
    Learning
    Not documented — The reviewed sources do not establish this organizational capability.
    Simulation
    Not documented — The reviewed sources do not establish this organizational capability.

Don't ask only what an agent can do.

Instead ask:

  1. What context does it have?
  2. What tools can it access?
  3. What decisions can it make?
  4. What memory does it retain?
  5. Who authorizes its actions?
  6. How is its work observed?
  7. How does the organization learn from it?
  8. How does it coordinate with other agents?

From agents to organizations

Individual agents are only one part of an AI-native organization. Explore how context, governance, workflows, memory, humans, and agents combine into Organizational Intelligence.

Explore Organizational Intelligence Assess Your Organization

The Swarm Loop · Organizational Intelligence vs. Org Charts · Explore the Simulator

About this Landscape

An independent map of the agents, runtimes, frameworks, and infrastructure shaping AI-native organizations.

Agentic Swarm is an independent research and educational resource. It is not affiliated with, endorsed by, or sponsored by the organizations listed in the Agent Landscape unless explicitly stated. Product names and trademarks remain the property of their respective owners.