Skip to content

Durable Multiplayer Agent Platforms: A Literature Review of Sierra Pinecone, Shopify River (Aquifer), and Anthropic Managed Agents

Research date: Aug 3, 2026. This is a literature review of the primary sources published by the three organizations. Every factual claim is cited inline to a real URL (official blog posts of the respective companies or the Anthropic engineering blog); nothing is paraphrased from secondary coverage. Numbers reported by the companies are self-reported and noted as such. Companion article in this workspace: search-gateways.md.

TL;DR

Three independently built systems — Sierra's internal agent Pinecone (with its Agency sandbox platform and MCP Gateway), Shopify's Slack-native coding agent River (on the Aquifer platform), and Anthropic's hosted Managed Agents service — converge on one architecture:

Virtualize the agent like an OS virtualized hardware: Session (durable memory) · Harness (the brain) · Sandbox (the hands). The harness does not live in the sandbox; the session log is the canonical, durable truth; sandboxes are disposable "cattle."

  • All three split the agent loop ("brain") from the execution environment ("hands") — Anthropic describes this as "decoupling the brain from the hands" (https://www.anthropic.com/engineering/managed-agents), and Shopify states its design constraint: "Cells die, sandboxes die, machines die. The conversation doesn't" (https://shopify.engineering/under-the-river).
  • Both company-internal systems exist to make the corpus of sessions the compounding asset: public-by-default work is mined back into skills, prompts, and defaults — "The agent gets smarter without requiring model retraining" (https://shopify.engineering/under-the-river).
  • Neither Pinecone nor River/Aquifer is open source; the closest public engineering write-ups are the two blog series below plus Anthropic's essay, which Shopify explicitly cites as validation of its design (https://shopify.engineering/under-the-river).

1. Primary sources

# Source Date What it documents
S1 Sierra, AI-pilling our company: lessons learned — https://sierra.ai/blog/ai-pilling-our-company-lessons-learned 2026-07-09 Why Sierra collapsed role-specific agents into one agent; MCP Gateway concept; identity model
S2 Sierra, Pinecone: Harnessing the wisdom of the workforce — https://sierra.ai/blog/pinecone-harnessing-the-wisdom-of-the-workforce 2026-07-15 Pinecone product surface; 3-component architecture (app server / Agency / runner) with flowchart; adoption numbers
S3 Sierra, Building Sierra's MCP Gateway: An engineering iceberg — https://sierra.ai/blog/building-sierras-mcp-gateway-an-engineering-iceberg 2026-07-22 Credential brokering; cross-customer access control; identity; adoption (89% of employees, 45 services)
S4 Sierra, Agency: Secure, scalable sandboxes for agents — https://sierra.ai/blog/agency-secure-scalable-sandboxes-for-agents 2026-07-29 Agency: Kubernetes control plane + stateful runner fleet; hibernation via FSM + checkpoint replay; security architecture; latency figures
R1 Shopify, Under the River — https://shopify.engineering/under-the-river 2026-05-28 River surface; Aquifer decomposition (Session/Harness/Sandbox); session cells; profiles; usage numbers
R2 Shopify, Building an agentic harness that outlasts the model — https://shopify.engineering/building-an-agentic-harness-that-outlasts-the-model 2026-07-29 Dispatch AppSec harness: partitioned multi-agent scanning; costs
A1 Anthropic, Scaling Managed Agents: Decoupling the brain from the hands — https://www.anthropic.com/engineering/managed-agents 2026-04-08 Managed Agents interfaces (session/harness/sandbox); interface signatures; TTFT gains

The Sierra posts are a series ("AI-pilling Sierra"); the post S1 announces follow-up deep dives by Allen Chen (Pinecone technical architecture), Mihai Parparita (MCP Gateway), and Rohith Ravi (Agency) — S3 and S4 are the published MCP Gateway and Agency deep dives. As of this review, no separate deep dive by Allen Chen on Pinecone's technical architecture had been published (only S2).

2. Convergent core: Session / Harness / Sandbox

2.1 The three primitives

Anthropic (A1) explicitly frames the design as virtualizing agent components, "an old problem in computing: how to design a system for 'programs as yet unthought of'." The three virtualized components:

  • Session — "the append-only log of everything that happened"; a durable, recoverable context object that lives outside the model's context window. Interface: emitEvent(id, event) to record, getSession(id) / getEvents(id, slice) to read positional slices (used for resume, rewind, and rereading lead-up context). Context transformation (compaction, trimming, prompt-cache-friendly organization) is pushed into the harness, not the session.
  • Harness — "the loop that calls Claude and routes Claude's tool calls to the relevant infrastructure." Stateless and disposable; rebuilt via wake(sessionId) after crash, resuming from the last event.
  • Sandbox — "an execution environment where Claude can run code and edit files." Disposable; provisioned via provision({resources}), called as a tool via execute(name, input) → string. If a container dies, the harness catches the failure as a tool-call error and Claude can retry on a freshly provisioned container.

Shopify (R1) documents the same decomposition with near-identical vocabulary: Session ("durable identity. Append-only event log. Postgres-backed. The canonical truth about what's happened so far"), Harness ("the agent loop. Reads history, calls the model, emits tool intents. Cheap to recreate, disposable"), Sandbox ("where the code runs... Disposable. Sometimes warm, often fresh"). R1 states the design constraint: "Cells die, sandboxes die, machines die. The conversation doesn't."

Sierra (S2) describes the same roles with different names: the app server (product surface: frontend, API, persistence, integrations, and the stream that sends agent output to every open tab), Agency (manages isolated, recoverable runner environments; reconciles each runner into a Kubernetes pod; Redis Streams for live communication; durable events and checkpoints for recovery), and the runner ("a Go process [that] supervises Codex or Claude Code, manages the development services, and brokers privileged operations"). S2: "Pinecone sessions are durable, even though the sandboxes they run in are not... Agency continuously records each session's state so a replacement runner can resume exactly where the previous one left off."

2.2 Why the harness must leave the sandbox

R1 derives three properties from keeping the harness outside the sandbox, "and you can't get any of them otherwise":

  1. Safety — "the agent loop is not in the same blast radius as rm -rf"
  2. Replaceability — swap models, runtimes, even languages on the harness side without disturbing the sandbox
  3. Observability — the entire decision stream is on the harness side, visible to one place

Anthropic (A1) documents the failure mode it solved: an early single-container design ("pets, not cattle") where a container failure lost the session, failures were undebuggable through the WebSocket event stream alone, and the harness's assumption that "whatever Claude worked on lived in the container with it" forced VPC peering for customer environments. A1 also reports a direct performance payoff: because containers are now provisioned only when a tool call needs them, inference starts as soon as the orchestration layer pulls pending events from the session log — "our p50 TTFT dropped roughly 60% and p95 dropped over 90%."

3. Orchestration and lifecycle

3.1 Control plane + stateful runners (Sierra Agency, S4)

Agency is "a native Kubernetes application" with two layers:

  • Stateless control plane — exposes CreateRunnerInstance / DeleteRunnerInstance APIs; authenticates with IAM; manages runner templates and permissions; tracks runner state in DynamoDB; translates each runner definition into a Kubernetes pod.
  • Stateful runner fleet — each runner gets dedicated compute, persistent storage (PersistentVolume backed by cloud block storage) for repositories and build artifacts, "everything needed to behave like a developer's workstation."

S4's stated requirements for a runner: secure enough for customer data; fast enough to spin up without losing flow state; cheap enough to never think twice; reliable for long-running tasks; "8+ cores, 24GiB ram, fast disk" to match laptops; dynamically provisionable. Sierra built Agency in-house, citing that sandbox providers at the time had hard limits on resources per sandbox, runtime, or concurrency, and that a third-party vendor handling customer data would have slowed Ghostwriter customer approvals.

3.2 Session cells (Shopify Aquifer, R1)

When a session goes live, Aquifer materializes a "session cell": "an ephemeral process on a host, running the Go runtime and the agent harness in the same process group." If idle, the cell exits; the next interaction gets a fresh cell, possibly on a different host, but "the session identity is unchanged, and the conversation is all there. The work picks up where it left off because the work lives in Postgres, not in memory. Cattle, not pets, at the session level." R1 explicitly refuses to recommend one orchestrator over another: "the answer matters less than the principle: pick the end-to-end substrate, and refuse to compromise on cattle-not-pets at the session level."

3.3 Hibernation, checkpoints, and message queues (Sierra, S4)

S4's central scaling observation: "There is usually 2 to 4 orders of magnitude difference between the number of active runner instances within the last 8 hours compared to the last 8 days" — unattended agents spend most of their time waiting. This motivates runner hibernation:

  • Applications and runners communicate asynchronously through queues, not synchronous network calls: the application enqueues messages to a runner's input queue; the runner enqueues to its output queue. Implementation: an in-memory queue, "like Elasticache Redis Streams," with event sizes limited to a few hundred KiB; round trips measured at p50 8ms, p99 40ms when both parties are online.
  • A runner instance is modeled as a Finite State Machine; any message can transition its state.
  • Because a runner is a singleton and only it writes its output queue, the output queue is a strictly ordered append-only log. The runner periodically emits checkpoint events; to restore after hibernation or crash, replay output queue events from the last checkpoint onward. Checkpoint and delta events are "opaque proto messages" to the control plane — the application-specific runner decides their contents.
  • To the applications (Pinecone, Ghostwriter) hibernation is transparent: "A runner simply wakes up and continues working."

3.4 Many brains, many hands (Anthropic, A1)

A1 generalizes the decoupling: "each hand [is] a tool, execute(name, input) → string... The harness doesn't know whether the sandbox is a container, a phone, or a Pokémon emulator," and "brains can pass hands to one another." Many brains = many stateless harnesses reading the same durable session; scaling brains is just starting stateless processes.

4. Security architecture

Security is designed in from the start in all sources; the recurring invariant is the agent never holds credentials:

  • Sierra (S2, S3, S4):
  • The runner harness runs in an environment with limited network and filesystem access; when it reaches an inference provider, GitHub, or anything else requiring authentication, "the network proxy approves (or rejects) the request, swaps in the appropriate credentials, and forwards the request" — "we let the agent assume it can do everything, yet trust nothing" (S2).
  • All inference goes through an LLM proxy outside the sandbox, enabling just-in-time key injection and token accounting "without cooperation or potential meddling by a compromised agent" (S4).
  • Runner hardening: non-root user, all capabilities dropped, read-only root filesystem; all internet traffic through a filtering egress proxy; runner pods scheduled on isolated Kubernetes nodepools; each runner type gets dedicated IAM roles; runner-to-control-plane calls carry pod identity to prevent impersonation (S4).
  • MCP Gateway (S3): one gateway connecting agents to the company's systems via Model Context Protocol (linked to https://www.anthropic.com/news/model-context-protocol). It enforces policy at every tool call, isolates customer data, and leaves an audit trail; Pinecone inherits each employee's access (S1). Cross-customer access is blocked by a multi-pass system: (1) a deterministic phase builds a list of candidate customers the data may be about; (2) a fast model narrows candidates; (3) a slower model determines the customer and data sensitivity. Legitimate cross-customer work (e.g., incident investigation) requires out-of-band explicit approval and is added to the audit log (S3).
  • Identity rules of thumb (S3): "Interactive work runs as the user"; scheduled or shared workflows run as service accounts with only needed permissions; customer-data automations require pre-authorized workflows declaring which customers and tools they may access.
  • Anthropic (A1): tokens must never be reachable from the sandbox where generated code runs. Two patterns: auth bundled with a resource (e.g., the repo access token is used to clone during sandbox initialization and wired into the local git remote, so push/pull work without the agent handling the token) and auth held in a vault (MCP OAuth tokens fetched by a proxy on behalf of the session; "The harness is never made aware of any credentials").
  • Shopify (R1): lists the "credentials proxy" as part of the Aquifer substrate, and its security-adjacent lessons in R2: "Deterministic code that owns credentials, Git, and storage so the agents don't have to."

5. Product surface and user interface

5.1 Sierra Pinecone (S1, S2)

  • Entry points: browser (web app with a prompt-bar home page), Slack, Linear, phone — "anywhere you work" (S2). Pinecone has "one Slack handle, one URL, and one unbroken thread from question to finished result" (S1).
  • Session as primary unit: a prompt ("identify a UX performance degradation", "fix this flaky test") provisions an isolated pod with a checked-out repository, warm build cache, running sidecars, hot-reloading dev servers, and a harness "in about a second." The session streams its work back: "text, tool calls, diffs, screenshots, files, and more. You can watch, interrupt, redirect, or close the tab" (S2).
  • Capabilities built around sessions (S2): Multiplayer (branch an entire session with your own MCP authorization; live development previews that hot-reload; point-and-click UI-change plugins); Brokered PRs and CI (sessions open their own pull requests, watch their own checks, a monitor sub-agent babysits the PR, answers machine-review comments, fixes failing tests, pings humans in Slack when judgment is needed); Automations (observe Slack channels and Linear tickets; morning digests of action items; webhook- or schedule-triggered); Skills (reusable playbooks, private, sharable, or default-on); Projects (multiple sessions grouped, coordinating through shared searchable context and inter-session messaging).
  • "Agent, singular": no persona/toolset/sandbox-profile dropdowns. "A classifier reads the prompt and selects the repository, environment, harness, model, and reasoning budget" (S2), and a session can pick up new tools mid-task (e.g., an analysis session discovers a bug and opens a coding session to fix it). S1 describes this evolution: role-specific agents (PINE for support, Pinewood for data analysis, Reggie Jr for sales) failed structurally — "the most important work happens across teams not within them" — and were collapsed into Pinecone.
  • Artifacts as input/output: "the agent is the UI, the system of record the backend" — GitHub keeps the PR, Salesforce the account, Linear the issue; "Replacing those systems means recreating decades of mature software" (S1).

5.2 Shopify River (R1)

  • Surface: company Slack only; "you talk to it by typing @river in a public channel." Constraint: "River only works in the open. No direct messages." Every conversation becomes a public Slack transcript.
  • Behavior: reads code, runs tests, opens pull requests, queries the data warehouse, looks at production traces, and "occasionally pushes back on a plan it thinks is bad." Median session: 19 minutes; median tool calls per session: 50.
  • Multiplayer as design: humans drop into an active thread with constraints or redirects; "River incorporates the new context without losing the conversation, and continues. The thread is searchable. The work is reproducible."
  • Corpus flywheel: "We mine that corpus. One person's hard-won fix becomes the next person's starting point because we feed the patterns we see back into River's skills, prompts, and defaults. The agent gets smarter without requiring model retraining."
  • Profiles, not platforms: a profile is data — "a system prompt, a set of skills, a set of extensions, a sandbox policy, model defaults. All built with Nix and shipped as bundles. Adding a new agent product means adding a bundle, not building a new platform." River is one profile; PR review is another; Vanilla (a headless agent) is another. The same substrate serves three consumers: Interactive (River), Automation (PR review, woken by external systems), Job (CI/batch, ephemeral, session log optional).
  • Preconditions (R1, "Part I"): the 2024 decisions to become a monorepo company ("World") and to build everything with Nix. Reported consequences: "CI had to scale by an order of magnitude, almost overnight. Merge queues became load-bearing. The build cache became a product." Payoffs include an AI agent "at the root of the repo," skills as files loaded on demand, and "Ask the repo a question" as a viable interface. R1's lesson: "Every change we made for agents was also the right thing for humans."

5.3 Shared design choices

  • Harness adapters over owning models: Sierra installs Codex and Claude Code in every sandbox behind "an adapter that speaks a common protocol based on AG-UI" — providing model/harness optionality and letting the platform improve as the harnesses improve (S2). S1: "Owning the layer above the models lets us route each task to the right model, fail over during downtime, and manage cost."
  • Primitives, not workflows: "We found early on that workflows didn't last long. The models got too smart... Instead, we built opinionated primitives: better context, environments, and company-specific tools" (S2). R1's R2 companion reaches the same conclusion at the harness level: "The most durable advantage you can develop is a harness tuned to the particularities of your software development ecosystem... You'll keep this part as new models come and go."

6. Scaling and measured outcomes (all self-reported by the companies)

Metric Value Source
Sierra: sessions in last month 75,000+ from 600+ people (as of mid-July 2026) S2
Sierra: engineering adoption 96% of engineering uses Pinecone daily S2
Sierra: PRs 70% of PRs opened through Pinecone in the last month S2
Sierra: growth "Usage has tripled every month since April, yet costs have fallen" S2
Sierra: MCP Gateway adoption 89% of employees; 45 services; ~2/3 of commits from non-founders S3
Sierra: runner queue round-trip p50 8ms / p99 40ms (events ≤ few hundred KiB) S4
Sierra: idle vs active runners 2–4 orders of magnitude difference (last 8h vs last 8d) S4
Sierra: runner resources 8+ cores, 24 GiB ram S4
Shopify: River sessions (30 days) 59,918 sessions in 5,170 channels; 7,000+ people; 3,536 River-coauthored PRs merged R1
Shopify: PR share 1 in 8 merged PRs coauthored by River R1
Shopify: session shape median 19 minutes, 50 tool calls R1
Shopify: scan costs (Dispatch) $50–300 full application scan; \(5–50 incremental diff scan; 80+ apps; 300+ findings; ~\)400k equivalent bounty value R2
Anthropic: TTFT after decoupling p50 −60%, p95 −90% A1
Anthropic: context anxiety example Sonnet 4.5 wrapped up tasks prematurely near context limit; behavior gone in Opus 4.5 A1

Note on trust: all usage numbers come from the companies' own posts. R1 states its numbers "come from the river_sessions domain table that River writes to itself," and that the numbers "are already wrong, in the upward direction" at publication. Sierra (S1) cautions that sessions and tool calls are "activity, not outcome," and that it does not yet measure downstream outcomes well.

7. Implementation reference: build order (synthesis)

This section is the reviewer's synthesis of the sources above, not a claim made by any of them.

  1. Substrate: monorepo + fully reproducible environments (Nix per R1; "same Nix-built environments in dev, CI, and production"). Rationale: R1's "agent-friendly ≈ human-friendly."
  2. Session log: append-only, Postgres-backed event store (R1) with emitEvent / getSession / getEvents-style APIs (A1); checkpoints embedded in the stream (S4).
  3. Stateless harness: wrap an existing harness (Codex/Claude Code) behind an AG-UI-style adapter (S2); rebuild via wake(sessionId) (A1).
  4. Sandbox plane: Kubernetes pods with persistent volumes (S4), hardened containers (non-root, dropped caps, read-only rootfs, S4), filtering egress proxy, LLM proxy with JIT credentials (S4, A1).
  5. Orchestrator: stateless control plane (DynamoDB state, IAM) + stateful runners; async message queues (Redis Streams) + checkpoint-replay hibernation (S4); "cattle, not pets" cells (R1).
  6. Credential gateway: single MCP-based gateway with per-user permission inheritance, audit log, and cross-tenant blocking (S3).
  7. Product surface: session streaming UI, branching/multiplayer, skills, PR/CI brokering (S2); public-by-default corpus with mining back into skills (R1).
  8. Telemetry: session-level domain table written by the system itself (R1's river_sessions pattern) as the flywheel input.

8. Gaps and open items

  • Sierra announced (S1) but has not yet published a separate technical deep dive on Pinecone's application-layer architecture by Allen Chen; S2 currently contains the most complete Pinecone architecture description.
  • S3 closes with "we're finally releasing the lock" (the MCP Gateway is community-owned inside Sierra) — no public open-source release of the gateway had been identified at the time of this review; the github.com/sierra-ai organization shows no public repositories.
  • Neither Aquifer nor Agency is publicly released. The closest public references to the pattern are A1 and the related Anthropic harness posts (e.g., Effective harnesses for long-running agents, https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents).
  • R2 (Dispatch) is a different Shopify system (application-security scanning) from River/Aquifer; it is included because it documents the same multi-agent orchestration patterns (partitioning, cross-model verification, harness-outlasts-model) with cost data.

References (all fetched and verified directly on Aug 3, 2026)

  1. Sierra — AI-pilling our company: lessons learned (Neil Rahilly, 2026-07-09). https://sierra.ai/blog/ai-pilling-our-company-lessons-learned
  2. Sierra — Pinecone: Harnessing the wisdom of the workforce (Allen Chen, Tess Rosania, 2026-07-15). https://sierra.ai/blog/pinecone-harnessing-the-wisdom-of-the-workforce
  3. Sierra — Building Sierra's MCP Gateway: An engineering iceberg (Mihai Parparita, 2026-07-22). https://sierra.ai/blog/building-sierras-mcp-gateway-an-engineering-iceberg
  4. Sierra — Agency: Secure, scalable sandboxes for agents (Rohith Ravi, 2026-07-29). https://sierra.ai/blog/agency-secure-scalable-sandboxes-for-agents
  5. Shopify — Under the River (Burke Libbey, Javier Moreno, River, 2026-05-28). https://shopify.engineering/under-the-river
  6. Shopify — Building an agentic harness that outlasts the model (Zack Deveau, 2026-07-29). https://shopify.engineering/building-an-agentic-harness-that-outlasts-the-model
  7. Anthropic — Scaling Managed Agents: Decoupling the brain from the hands (Lance Martin, Gabe Cemaj, Michael Cohen, 2026-04-08). https://www.anthropic.com/engineering/managed-agents
  8. Anthropic — Effective harnesses for long-running agents (2025-11-26). https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
  9. Anthropic — Model Context Protocol announcement. https://www.anthropic.com/news/model-context-protocol

Appendix: method

All facts above were extracted by direct fetch of the official URLs. Where a claim appears in multiple sources (e.g., the session/harness/sandbox decomposition), the primary articulations are cited. No numbers, names, or architecture details were taken from secondary coverage (e.g., press or third-party case studies); the only third-party citations that appear inside the sources are links made by the sources themselves (e.g., Anthropic's essay cited by R1; ACM 1968 productivity study and OpenAI/DeepMind specification-gaming links cited by S1/S3).