Two blueprints crossed my desk this quarter. They are the same blueprint with different locks.
xAI's GrokBot, in beta since August 11, hands every account a persistent cloud computer — a live runtime with a browser, a filesystem, and a terminal, shared across every bot that account spawns. Meta's Muse, dated September 8, refuses the shared model outright and gives each user an isolated Linux VM, with a host-side governor called Sentinel mediating every connector call and every byte of network egress. Same shape. Opposite locks.
Neither release carries a verifiable primary source — no pricing page, no API reference, no third-party security review. So I am treating both as an architecture brief rather than a product launch. That distinction is the whole point. The brief is worth more than the products, because what it describes is the moment agent infrastructure stops being a stateless API call and becomes a stateful workspace. It is also the moment the interesting engineering migrates out of the model and into the custody layer.
And custody is a subject my readers already know something about.
For three years the dominant agent pattern was stateless: send a prompt, receive a completion, discard the session. That pattern was cheap, horizontally scalable, and easy to meter. It was also useless for anything that required memory — a procurement workflow that spans four sessions, a code migration that touches nine files, a treasury operation that has to wait for a timelock to expire.
The persistent agent VM is the industry's answer. Give the agent a machine. Let it keep files, keep cookies, keep a shell history. Let it wake up where it left off.
Two isolation primitives dominate the designs. Firecracker microVMs, the AWS-born lightweight hypervisor, give strong kernel-boundary isolation with boot latency measured in roughly a hundred milliseconds and a memory overhead measured in single-digit megabytes. systemd-nspawn gives namespace and cgroup isolation at almost no boot cost, but shares the host kernel — the same trade-off that has kept container escapes viable for a decade.
GrokBot's brief places the security boundary at the account. One Firecracker microVM per account; every bot inside that account shares it. Muse's brief places the boundary at the action: one Linux VM per user, plus Sentinel as the sole authority for outbound connections and connector invocations. Credentials live outside the runtime and are injected at the network boundary, just-in-time, so the agent never handles the real token.
Strip the branding and you have two governance philosophies wearing the same infrastructure. One trusts the tenant. One does not trust the process.
Let us be forensic about where the boundary actually sits, because that is where the money and the liability live.
Account-level isolation is responsibility transfer disguised as a feature. I have audited enough multi-tenant systems to recognize the shape. When xAI tells users that the bot screen is not a security boundary, and warns them not to place anything on it that another bot should not reach, the platform is not describing a defect. It is describing a contract. The spec's exact language — if a credential or file should not be used by another bot, do not put it there — moves the minimum-privilege obligation from the operator to the tenant.
For a consumer spawning three bots to book flights and summarize a newsletter, that is fine. For an enterprise running twelve agents against a shared finance connector, it is unfundable. Firecracker will stop a hostile tenant from reaching a neighbor's kernel. It will not stop one compromised bot inside the same account from reading another bot's token cache, because there is no kernel boundary between them — there is only a folder.
Action-level isolation fixes the right axis and introduces a new single point of trust. Sentinel is described as the only authority permitted to open a connector action or a network egress. Every credential is injected at the boundary. Structurally that is the same primitive as a cloud secrets manager issuing short-lived STS tokens, and it is a genuine improvement: an agent that never possesses the token cannot exfiltrate it directly through a prompt injection.
But the trust does not vanish. It concentrates. If Sentinel is misconfigured, bypassed, or compromised, one failure surface now governs every action the user's runtime can take. The blast radius moves from "one token" to "one identity's entire action space." The brief gives no detail on how Sentinel is itself protected, versioned, or audited. That is not a footnote. That is the entire security model resting on an unexamined assumption.
The cost model is the part nobody wants to price. Stateless inference bills by token. A persistent VM bills by residence. You pay for CPU, memory, storage, and network for as long as the workspace exists, whether or not the agent is thinking. This is VDI economics, not API economics, and VDI has never been a high-margin business.
Run the numbers on a modest deployment. Fifty thousand concurrent workspaces at 1 vCPU, 2 GB RAM, and 10 GB of persistent block storage is fifty thousand cores held warm, one hundred terabytes of resident memory, and half a petabyte of durable storage before snapshots. At commodity cloud rates, the raw infrastructure alone clears several million dollars a month — against a revenue base that, priced like a consumer subscription, is maybe ten to fifteen dollars per seat. Margin only survives if utilization stays low and hibernation stays aggressive. Neither brief discusses density targets, snapshot cadence, cold-start latency after eviction, or per-tenant resource quotas.
I have watched this exact omission kill projects before. In 2021 I modelled Axie Infinity's staking emission schedule and found a seventy-two-hour window where reward issuance outran inflation — a temporary arbitrage worth roughly twenty-two percent on a fifty-thousand-dollar base over four days. That trade worked because the emission math was knowable and the window was finite. The agent VM cost curve is the same class of problem running in reverse: the math is knowable, and the window of "grow now, price later" closes the moment a serious enterprise asks for a committed-use discount it can put in a board deck.
Credential custody is where crypto is already ahead — and does not appear to know it. Muse injects credentials just-in-time at the network boundary. The agent requests an action; Sentinel attaches the secret; the connector sees an authenticated call; the agent sees a result. This is good design. It is also, structurally, what a hardware wallet does for a signing key: the key never enters the environment exposed to untrusted input.
But JIT injection solves disclosure, not delegation. It does not answer the harder question — what is the scope of the credential being injected, and who can narrow it? A token injected at the boundary is still a bearer instrument for the duration of the call. If it carries broad scope and a long TTL, a single successful injection turns one prompt into an unbounded action set. Real safety requires attenuation: the ability to hand an agent a credential that is provably limited to one action, one counterparty, one amount, with a cryptographic proof that the limitation was not edited in transit.
That problem is largely solved. Just not in the places shipping agent products. Verifiable credentials, macaroon-style attenuation, session keys with on-chain policy, and account abstraction modules that enforce spending limits at the contract layer all produce a credential whose blast radius is bounded by construction rather than by configuration discipline. The persistence of bearer tokens inside agent platforms is a choice, not a constraint.
Which brings me to the gap I actually care about.
On-chain agent identity is still undefined, and the VM vendors are not going to define it. I drafted a specification in 2025 for what I called a Turing-Proof token standard: a zero-knowledge attestation that an autonomous agent is what it claims to be, bound to a principal, without revealing the principal's private data. I took it to three L2 teams and secured pilot interest. What I did not have then — and what neither GrokBot nor Muse supplies now — is an answer to the identity question at the settlement layer.
When an agent holds a wallet and moves value, three separate identities collapse into one transaction. There is the principal who authorized the agent. There is the runtime that constructed the transaction. And there is the model that produced the intent. Today, on-chain, all three are the same address. That is an accounting fiction, and auditors are going to hate it. Bolting general-purpose agent runtimes onto settlement layers built for narrow, verifiable transfers is the same category error as minting BRC-20 tokens on Bitcoin — the machine will do it, the car drives, and you have insulted the engine while carrying nothing that needed carrying.
The persistent VM makes this worse before it makes it better. A long-running workspace accumulates state — session tokens, cached files, browser profiles, partial transaction histories. That state is the agent's memory, and memory is evidence. When a dispute arises over an unauthorized transfer, the question will not be "did the model hallucinate." It will be "what exactly was in the runtime when the transaction was signed, and can you produce it."
Can you produce it? Neither brief says. There is no mention of snapshot encryption, retention windows, deletion guarantees, or cross-border transfer rules for the persistent disk. Under GDPR, a persistent VM that has touched EU personal data is a processing system with a right-to-erasure obligation attached to a filesystem explicitly designed to persist. Under the EU AI Act's logging provisions, higher-risk systems need traceability. Those two requirements pull in opposite directions, and neither brief reads like anyone has reconciled them.
The data lifecycle is the compliance black hole, and it is not hypothetical. Ask a simple question of any persistent agent product: when a user deletes a workspace, what happens to the snapshots? Is the block storage crypto-shredded, or is it quietly retained in case of a billing dispute? Is the browser profile encrypted at rest with a key the tenant controls, or with a key the operator controls? Can a user export their agent's memory, or is that memory held as a lock-in asset? An asset that can be bought but never moved is not a market — it is a receipt.
I have seen this movie. In 2022 I dissected the Terra-Luna de-peg within forty-eight hours of the crash and found the failure was not the algorithm alone. It was the interaction between an incentive mechanism and an operational assumption nobody had stress-tested. Persistent agent VMs have the same shape of hidden coupling. The retention policy interacts with the security model interacts with the pricing model, and each one is being decided by a different team with a different incentive.
Coordination-first is a distribution strategy, not an architecture choice. xAI's decision to bind GrokBot to the X account graph is not a technical decision. It is a funnel. Every X account is a pre-authenticated tenant with a social graph, a payment relationship, and a habit of staying logged in. That collapses customer acquisition cost toward zero and hands the agent a ready-made context store. The account-level microVM is the cheap way to serve that funnel — one per account is cheaper than one per user, and vastly cheaper than one per action. If your growth model is consumer and creator, coordination-first is correct.
Meta inherits a different constraint. It operates under consent decrees, GDPR enforcement, and an EU posture that treats automated processing as a first-class risk. A shared runtime where bots can read one another's files is not a product decision Meta gets to make, even if it wanted to. Sentinel is not merely good engineering — it is the shape a compliance department demands. One isolated VM per user costs more. It is also the only version of this product that survives an enterprise security review.
So the architecture debate is partly regulatory arbitrage in disguise. One company can ship the cheap model because it carries less regulatory weight and targets less regulated customers. The other must ship the expensive model because it cannot afford the headline. Both are rational. Neither is a pure technology choice. You are not watching two engineering cultures diverge. You are watching two regulatory positions produce two cost structures.
The competitors both briefs forgot. Any analysis that stops at GrokBot and Muse is answering the wrong question. The relevant field includes OpenAI's computer-use line, Anthropic's tool-execution stack, Google's agent projects, and the cloud providers who already sell the isolation primitives both products depend on. AWS invented Firecracker. Azure sells confidential computing. Neither needs to ship an agent product to capture the agent infrastructure market — it needs only to make the runtime a line item.
There is also a crypto-native cohort neither brief mentions and that is, in my reading, further along on the hardest problem. Session-key wallets that constrain an agent to a spending policy enforced by contract code. Account abstraction modules that require a second signature above a threshold. Attestation registries that let a counterparty verify an agent's principal before accepting a transfer. None of these solve prompt injection. They solve the thing prompt injection exploits: an unbounded authority an attacker can simply borrow.
The demand profile is worth naming precisely. Persistent agent VMs pull on lightweight virtualization, cloud sandboxing, secrets management, policy engines, egress control, and audit observability. They push against legacy RPA, browser automation, and VDI — all functionally overlapping, all with incumbents who have revenue to defend. The hardware mix shifts too, from GPU-heavy inference toward a blended CPU, memory, storage, and network footprint. That is a different cloud purchasing pattern, and it is one more reason the cost model in these briefs deserves more scrutiny than the model quality.
Now here is the angle the architecture commentary is not running.
The persistent VM is a liability wrapper, not a product. Every feature the briefs advertise — browser, filesystem, shell, connectors — is a surface that can be induced to act against its principal. The vendors know this, which is why both built governance layers. GrokBot's governance is a warning label. Muse's governance is Sentinel. In both cases the runtime is the commodity and the policy engine is the moat.
That carries a consequence nobody has priced. Whoever owns the policy engine owns the settlement layer. If Sentinel-style action mediation becomes the enterprise default, the company that defines the policy schema defines what an agent is permitted to do in every environment that adopts it. That is not a feature advantage. That is a standards position, and standards positions are where crypto protocols and cloud providers have historically gone to war.
And then there is the regulatory question, which has already been answered once, badly. In 2022, sanctions were applied to a set of smart contracts, and the practical effect was to establish that publishing code can be treated as operating a financial service. Every open-source developer who has ever shipped a permissionless tool now lives downstream of that precedent. Now extend it. An agent running in a persistent VM writes code, deploys it, and executes transactions. Who is the developer? Who is the operator? Who is the money transmitter? The record says "whoever touched the code" — which, applied to autonomous agents, means the liability chain runs from the model to the principal to the VM operator and never cleanly terminates.
The industry is building agent runtimes backwards. It is hardening the runtime and leaving the accountability graph undefined, when the hardening is the cheap part and the accountability graph is what regulators will actually demand. Arbitrage isn't in the hardening. It never is.
Watch three things over the next two quarters. First, whether either vendor publishes a policy schema for action-level authorization — if it stays proprietary, the moat is real and switching costs are permanent. Second, whether credential attenuation ships as a primitive rather than a configuration option. Third, whether anyone, vendor or regulator, defines the identity of an agent at settlement.
Arbitrage isn't a product feature; it's the math of patience applied to chaos. The runtime will commoditize — that is not a prediction, it is a cost curve. We don't get to find out which layer wins until someone has to produce the audit trail for a bad transaction, in front of a regulator, with a real balance sheet on the line. That is the first test that will actually settle the architecture debate, and neither brief has started preparing for it.