Anatomy of a Modern AI Agent: Muse vs Grok Bot in 2026

Modern AI agent architecture is starting to look less like a chat product and more like an operating system. The model still reasons, but the surrounding machinery now carries memory, runs tools, keeps browser sessions alive, schedules work, guards credentials, and decides whether an action may leave the machine.

Meta's Muse and Grok Bot make that shift unusually visible. Both products give an AI agent a persistent cloud computer. Both support background work, reusable skills, browser use, and human approvals. Yet they organize trust very differently, which makes them a useful pair for understanding where the agent ends and the security system begins.

This is an evidence-led teardown, not a product review. We separate confirmed public documentation from interpretation and unknowns. That distinction matters because these systems change quickly: one central Grok Bot infrastructure detail became public between the research cutoff and publication.

Last verified: September 21, 2026.

Modern AI agent architecture has six planes

A modern AI agent is a reasoning model inside an orchestrated system that can observe, decide, act, and preserve state. The useful architecture separates six planes: cognition, orchestration, execution, state, identity, and control. Reliability comes from the contracts between those planes, not from model intelligence alone.

That separation is more than a diagramming preference. It tells you where a failure belongs. A hallucinated action is a cognition problem. An infinite retry is an orchestration problem. A shell escape is an execution problem. A stale user preference is a state problem. A leaked OAuth token is an identity problem. An unauthorized email is a control problem.

1. Cognition

The cognition plane is the model and its immediate reasoning interface. It interprets the goal, chooses tools, generates structured calls, evaluates observations, and decides what to do next. This plane sets the capability ceiling, but it does not define the whole agent. Model versions can change while the surrounding computer, policy, and memory architecture stays mostly intact.

2. Orchestration

The orchestrator assembles context, runs the loop, invokes tools, delegates work, handles errors, compacts history, and decides when to stop. Grok Bot exposes this through named Bots, skills, routines, group coordination, and task handoffs. Muse describes a main harness that can coordinate concurrent subagents and scheduled work inside a per-user cloud computer.

3. Execution

Execution is where intent becomes an effect. It includes the shell, code runner, browser, filesystem, network, connectors, and any remote service the agent can call. The execution plane determines whether the agent is merely drafting advice or operating real software under a real identity.

4. State

State covers the working transcript, durable files, memory, schedules, checkpoints, and run history. It lets an agent resume after a pause and build context across sessions. It also creates hard questions: what deserves to persist, which fact supersedes another, how provenance is preserved, and whether deletion reaches backups, indexes, and summaries.

5. Identity

Identity is the authority under which the agent acts. It includes browser sessions, API tokens, OAuth grants, service accounts, user roles, and payment confirmation. The central security question is not whether the agent promises to protect a secret. It is whether model-controlled code can ever read the secret value.

6. Control

Control governs what may happen. Policies, approvals, isolation, audit logs, rate limits, network rules, and administrative settings all live here. A mature control plane assumes the cognition plane will sometimes make the wrong choice and still keeps the resulting effect inside a bounded authority.

The agent loop turns a model response into a trajectory

A chatbot can answer with one model call. An AI agent works through a trajectory. It receives a goal, assembles context, proposes an action, passes that proposal through policy, executes in a bounded environment, observes the result, updates state, and loops until it finishes or needs the user.

The distinction between a response and a trajectory changes engineering priorities. You need resumability, idempotent retries, explicit stop conditions, partial-completion reporting, and a record of what the agent proposed versus what the environment accepted. The AI agent trajectory becomes the unit you debug, audit, and evaluate.

This is also why an agentic workspace needs more than a prompt box. The useful surface exposes sources, intermediate work, approvals, results, and a durable place to continue.

Persistent computers are the new product primitive

The most consequential shared design choice is persistence. A durable AI agent computer lets files, browser sessions, installed tools, task state, and long-running work survive the end of a conversation. It also turns a temporary assistant into a continuing principal inside a user's digital environment.

The Grok Bot overview says each named Bot works on a persistent cloud computer with a browser, filesystem, and terminal. Bots can coordinate in parallel, pass task ownership, retain context, and continue while the laptop is closed. The key boundary is per user, not per Bot: all of one user's Bots share the same computer, files, browser sessions, and app logins.

Meta describes Muse as living in a dedicated per-user Secure VM with its own browser, storage, CPU, memory, connectors, and durable state. The VM can compile code, run custom skills, coordinate concurrent subagents, and execute scheduled work. The user VM is the system of record, while limited inference and telemetry leave through constrained paths.

Persistence creates product power and security debt at the same time. A long-lived browser session saves repeated setup, but a stolen session lasts longer. Shared files make handoffs effortless, but widen the blast radius between Bots. Memory makes behavior feel coherent, but introduces conflicts, stale facts, provenance, and deletion obligations.

The same shift is reaching vertical workflows. In agentic video production, for example, a persistent agent can carry a brief, sources, brand rules, intermediate assets, and approvals through a multi-stage job instead of generating one isolated clip. Our earlier teardown of Runway's agentic production approach shows the same move from one model call toward an orchestrated production system.

Muse vs Grok Bot: two trust centers

Muse and Grok Bot can produce similar user experiences: browse a site, read a file, draft a message, ask for approval, and continue later. Their public architectures place the hard trust boundary in different places.

Grok Bot treats the user computer as the collaboration boundary

Current Grok Bot enterprise documentation identifies the hosted computer as one persistent Firecracker microVM per user, with its own kernel, memory, and virtual devices. That gives hardware-level separation between users. Within a user account, the design deliberately favors sharing: every Bot uses that one computer.

The docs are explicit that Bots separate personalities and workspaces, not compute. A file, browser login, or command-line credential available to one Bot may be available to the rest of that user's roster. If a workload needs a distinct computer and credential set, the documented answer is a separate Cursor user.

This is a coherent product bet. Named Bots can pass work without re-authentication, share a durable disk, and keep role-specific memory while using the same operational environment. The security consequence is equally coherent: a Bot name is not a sandbox.

Muse treats the model-controlled cell as compromised by default

Muse's public architecture draws another boundary inside the user VM. Meta's technical security report says the agent harness, workspace, tools, and agent-executed binaries run in a systemd-nspawn runtime cell. Root inside the cell maps to an unprivileged host user. The cell gets a separate Debian root filesystem, its own virtual network interface, filtered system calls, and reduced capabilities including no CAP_SYS_PTRACE and no CAP_NET_ADMIN.

Security-sensitive services stay outside that cell. Independent classifiers inspect model traffic. Privilege-separated workers run built-in connector logic. authd stores credentials and mints surrogates. Durable state sits in Postgres outside the runtime cell. Sentinel alone decides whether connector actions and network egress may proceed.

The design goal is not to make the agent impossible to manipulate. Meta says Muse remains fallible and prompt injection remains open. The goal is to keep a manipulated agent from rewriting its own guardrails, directly reading credentials, changing the network route, or quietly sending data to an attacker.

What changed between the research cutoff and publication

The September 11 research dossier correctly described Grok Bot's persistent computer and shared-Bot boundary, but at that point the public evidence did not identify the underlying isolation primitive. The dossier therefore marked container, microVM, or VM as unknown.

That gap closed before publication. SpaceXAI's current team documentation now says each user runs on a dedicated Firecracker microVM with hardware-level separation. It also documents network policy modes, durable-disk behavior during computer recreation and termination, backend-held OAuth tokens for plugins, and the boundary between a member's hosted computer and optional local execution.

The correction narrows the unknowns rather than eliminating them. Public docs still do not fully explain image-patching cadence, host hardening, snapshot and backup encryption, telemetry retention, or how browser state is protected at rest. They now disclose the tenant-isolation primitive and computer lifecycle at a useful product-security level.

Methodology: the original dossier was completed September 11, 2026 from primary product and security documentation, reputable launch reporting, and explicitly labeled secondary evidence. We rechecked every claim against live primary sources on September 21, compared documentation update dates, dropped unverified model-internal details, and revised claims when newer first-party evidence changed the boundary.

How modern AI agent architecture protects credentials

An AI agent can only be as trustworthy as its identity path. If arbitrary model-generated code can read a bearer token, then prompt injection can become credential theft. The stronger design is capability without possession: let the agent request an authorized action without receiving the underlying secret.

Grok Bot: backend-held connector tokens and user handoff

For plugins, SpaceXAI's security documentation says OAuth tokens remain on the Cursor connector backend and Bots invoke tools without receiving those tokens. For passwords, passkeys, two-factor codes, CAPTCHAs, and payment confirmations, the Bot hands control to the user. Supported secret requests mask the value, exclude it from the transcript, and keep it from the model.

The boundary is less strict for anything the user leaves inside the shared computer. Command-line credentials, authenticated browser sessions, and files remain available across the user's Bot roster. The docs therefore recommend scoped service accounts, removing temporary files, signing out unused browser sessions, and revoking connectors when work ends.

Muse: credential surrogation at the network boundary

Muse makes credential separation a host service. Code inside the runtime cell sees a surrogate token minted by authd. After Sentinel authorizes the concrete outbound request, it swaps in the real credential at the network boundary. The agent never receives the token it would need to exfiltrate.

Built-in connector commands inside the cell only parse arguments and pass typed values or already-open file descriptors over authenticated Unix sockets. A sandboxed worker outside the cell performs the operation with an explicit credential allowlist. A calendar worker cannot turn an argument into a request for an email credential.

This pattern matters beyond Muse. Whether tools arrive through bespoke connectors or standards such as MCP integrations, the useful security question is the same: does the agent get a secret, or does it get a narrowly scoped capability to request an action?

Browsers are both the universal tool and the hostile input channel

A browser gives an AI agent access to software that has no API, but it also mixes instructions, private data, authentication, and adversarial content in one surface. A page can contain useful text, hidden instructions, misleading labels, download links, and a form that triggers an irreversible effect.

Muse runs an up-to-date Chromium browser inside the Secure VM but keeps the Chrome DevTools Protocol broker outside the runtime cell. The browser subagent receives an accessibility-tree snapshot instead of the raw DOM. It cannot run page JavaScript, use script verbs, execute inside the browser process, or open DevTools. The agent pauses while the user takes control or while secure storage fills a credential field.

That narrower interface reduces attack surface, but it does not make visible text trustworthy. A malicious page can still present an instruction that looks relevant to the task or mislabel a control. Meta therefore layers model training, untrusted-input labels, independent classifiers, restricted browser capabilities, Sentinel-mediated egress, and human approval.

Grok Bot's browser sessions persist across tasks and Bots on the shared computer. The product documentation focuses on user takeover, secure secret entry, approval rules, and enterprise network controls. It also acknowledges that sites can block automation, expire a session, or require a human step, and directs the Bot to hand those cases back rather than bypass them.

Prompt injection is a systems failure mode

Prompt injection becomes dangerous when three conditions meet: the agent can read private data, it processes untrusted content, and it can communicate outward. Meta's report uses Simon Willison's term for that combination, the lethal trifecta. A model-level refusal only addresses one layer of the problem.

The stronger question is what happens after the model says yes to a hostile instruction. Can it read the secret? Can it open a raw socket? Can it change the proxy? Can it modify the connector? Can it send to a new destination without a separate authority checking the request? Can the approval payload differ from the eventual effect?

Muse's answer is defense in depth. The runtime cell limits system access. privsep narrows connector execution. authd controls credential material. Sentinel evaluates every connector action and concrete network request. For tainted egress, Meta says eBPF programs attribute network traffic to processes and Linux Security Module hooks propagate taint after a process reads user or external data.

Grok Bot's answer is a mix of hardware tenant isolation, no access by default, connector policy, user and team approval rules, Auto Review, optional enterprise network allowlists, action recording, and human takeover. Its approval documentation cautions that model-based Auto Review should complement, not replace, least privilege and explicit approval boundaries.

Public reaction reflects the same split. Early Muse discussions praised the usefulness of background action while repeatedly returning to permissions, data use, and whether users would connect email or payments. A more technical thread asked the right test question: does a second model merely judge an action, or does an independent capability system make the final decision? Those are different controls.

One sensitive request, two enforcement paths

Consider a task that sounds ordinary: read a contract in email, summarize the liability clause, and send the answer to a lawyer. The task crosses private data, an external document, legal interpretation, a connected identity, and an outbound side effect.

In Grok Bot, the Bot works inside the shared user computer, accesses the logged-in service, drafts the result, and reaches an approval boundary governed by explicit rules and Auto Review. A user can allow once, deny, or save a matching rule. Secret entry and verification remain human steps.

In Muse, a cell-side command sends typed arguments to a privilege-separated connector worker. The contract enters the untrusted cell for processing. The outbound send reaches Sentinel with destination, purpose, and request details. If policy requires consent, execution pauses for an approval outside the chat. authd provides the real credential only after authorization.

The user may perceive both flows as one approval dialog. Architecture review has to look underneath that surface and ask which components can alter the request, which service owns the credential, and which layer can enforce a denial.

Skills and routines turn sessions into institutions

An AI agent skill packages instructions, inputs, decision rules, validation, output shape, and approval boundaries. A routine adds a schedule or event trigger. Together they let a successful one-off trajectory become a repeatable operating process.

Grok Bot supports shared private skills, teach-by-demonstration, and background routines that run while the laptop is closed. Its skills and routines guide recommends testing the workflow once, saving the method as a skill, and only then automating it. It also advises keeping sending, publishing, purchasing, deletion, and production changes behind approval.

The hard engineering work starts after scheduling. A routine needs current inputs, a stale-data policy, idempotent retries, a failure destination, a partial-completion format, and a clear owner. Otherwise persistence turns a small mistake into a repeated one.

You can see the same pattern in narrower automation systems. A workflow that creates a video after an event still needs a trigger contract, a render status check, and a continuation path. Our guide to event-driven video automation is a concrete example of that small but complete loop.

What the public architecture still does not reveal

Disclosure is not proof, and silence is not evidence of absence. The responsible label for an undocumented feature is unknown, not missing. Both vendors now publish useful architecture, but important implementation details remain outside the public record.

Open questions for Grok Bot

• How are browser sessions and durable disks encrypted, backed up, and deleted?
• What host hardening, image patching, and microVM monitoring operate beneath the published Firecracker boundary?
• Which network controls exist for non-enterprise users, whose computers default to allow-all without an organization policy?
• How are Bot memories, conversation summaries, files, and durable disk state reconciled after a computer recreation?
• How does the independent review model bind the approved action to the eventual computer or tool effect?

Open questions for Muse

• Which hypervisor and host-isolation layer underpin the per-user Secure VM?
• How are episodic memory, user facts, retrieval indexes, files, and compaction summaries represented and reconciled?
• How do deletion requests propagate through continuous VM backup and telemetry?
• What exact data reaches model training after filtering, and what provenance accompanies it?
• How will the announced Confidential VM change operational access, recovery, and user-held key management?

A practical review checklist for any AI agent

Model benchmarks tell you whether an AI agent may choose a good action. They do not tell you whether the system will execute it safely. A security or architecture review should follow the effect path from user intent to external consequence.

1. Which process can read the real credential, and can model-controlled code modify that process?
2. Which independently enforced layer authorizes outbound network requests and connector effects?
3. What is the unit of isolation: process, container, microVM, full VM, user account, Bot, or task?
4. What state survives a crash, hibernation, rebuild, account deletion, or revocation?
5. Is approval bound to the exact target, action, purpose, value, task, and time window?
6. Can a user reconstruct the proposal, decision, effect, observation, retry, and failure from an audit trail?
7. What deterministic protection remains after the model follows an adversarial instruction?

If a vendor cannot answer these questions, another benchmark point will not close the gap. The unresolved problem is not intelligence. It is authority.

What this architecture means for business software

The AI agent layer will not erase specialized software. It changes how software is invoked. A user can state an outcome, while the agent selects tools, carries state, requests approvals, and returns a finished artifact or an exception that needs judgment.

That makes tool design more demanding. Actions need stable schemas, clear scopes, idempotency, observable progress, safe retries, and results that can be handed to another step. A tool that works only when a human babysits every screen is difficult to compose into an agent trajectory.

For media workflows, an AI video generation platform is a specialized execution system, not a place to hand every secret to a general AI agent. ngram exposes an MCP endpoint so supported external agents can start a video job while rendering continues server-side and the result returns as a link. The agent coordinates intent and approvals, while the specialized system owns the production pipeline and durable job state.

Frequently asked questions

What is the architecture of a modern AI agent?

A modern AI agent combines a reasoning model with an orchestration loop, execution environment, durable state, identity system, and control plane. The model proposes actions, but the surrounding system decides what context it sees, which tools it can call, how effects run, what persists, and when a human must approve.

How is an AI agent different from a chatbot?

A chatbot mainly returns a response. An agent pursues an outcome through multiple steps, calls tools, observes results, updates state, and may continue in the background. The difference is not conversational style. It is durable execution authority.

Why do AI agents need persistent computers?

Persistence lets files, browser sessions, tools, schedules, memory, and task progress survive between conversations. It supports longer jobs and cleaner handoffs, but it also enlarges the security and deletion surface because credentials and state can outlive the original request.

Does Grok Bot use a virtual machine?

Yes. Current SpaceXAI documentation says each user receives one persistent Firecracker microVM with its own kernel, memory, and virtual devices. Every Bot belonging to that user shares the same computer, so Bot identities are not separate compute or security boundaries.

How does Muse protect credentials?

Muse stores credentials in authd outside the model-controlled runtime cell. Agent-side code receives a surrogate token. Sentinel authorizes the concrete outbound request and substitutes the real credential at the network boundary, which prevents the agent from reading and leaking the original token.

Can approvals solve prompt injection?

No. Approvals reduce risk at consequential boundaries, but users can misunderstand prompts, approve too broadly, or become fatigued. They work best alongside isolation, least privilege, credential separation, egress controls, narrow capabilities, and an audit trail that binds the approved request to the executed effect.

What should an engineering team evaluate before adopting an AI agent?

Trace one real sensitive workflow end to end. Identify the secret holder, isolation boundary, egress authority, approval scope, durable state, retry behavior, and audit record. Then repeat the exercise under the assumption that the model follows a malicious instruction.

The model is the brain. The agent is the institution.

Muse and Grok Bot point toward the same product future: agents with persistent computers, reusable procedures, background work, memory, browser access, and real authority. Their biggest difference is not which model sits at the center. It is how each system contains, shares, and governs that authority.

Grok Bot shows how a roster of named teammates can share one working environment and coordinate with low friction. Muse shows how an agent can remain powerful while secrets, connectors, browser brokerage, durable state, and network permission live behind system-enforced boundaries.

The next generation of agent documentation will be judged less like a model card and more like a distributed-systems design review. The decisive questions are about authority, failure containment, and durable state. Intelligence matters, but governance is what turns intelligence into software you can trust with work.

If your use case is agent-driven video production, start a video in ngram and keep the same review questions in view: what the agent can see, what the media system retains, and which action still needs a person.