One agent, one box.
Bundling orchestration, tools, memory, and the model inside a single product is not a mistake. It is a rational default for a solo operator or a pilot. You get simplicity: one bill, one UI, one place to debug. Latency stays low because nothing crosses a boundary you did not ask for. Integration is tight because the vendor owns the whole path from prompt to side effect.
We still recommend that shape when the scope is one domain, one host, and one human who can eyeball every run. The case studies on this site do not argue against that. They describe what we had to add when “one capable assistant” stopped being true.
Where the bundled stack strains.
Four failure modes show up repeatedly once agent count, models, or compliance requirements grow. They are independent. You might hit one before the others, but they share a theme: the agent is doing work and judging whether that work was acceptable, inside the same runtime that benefits from saying yes.
- Self-supervisionThe runtime that executes the task also summarizes success. There is no independent check unless you bolt one on from outside, and most bundled products do not expose a clean hook for that.
- Lock-inRouting, memory, tool auth, and “agent identity” live in proprietary APIs. Moving one agent to another model or IDE means re-platforming management logic, not swapping a binary.
- Mixed fleetsClient A wants Claude in Cursor; client B is on a headless API worker; client C is still on a chat-only pilot. Coordinating purpose, handoffs, and shared audit across heterogeneous runtimes inside one vendor shell is awkward at best.
- Weak governancePermissions, spend caps, retention, and “who touched production last night” need answers that span agents. When management is an afterthought inside each session, you get screenshots and hope, not JSONL you can grep.
Execution is solved at the agent level. The bottleneck of intelligence is managing it.
Management is not the model.
Execution is what happens inside a run: read context, call tools, SSH, edit files, reply. That layer should stay as close to the work as possible: low latency, rich tools, a human watching the pane when stakes are high.
Management is everything that must stay true across runs and across agents: who is allowed to act, what job this agent exists for, where the record lives, how messages enter and leave, how you stop a run, and how you prove to a client or auditor what occurred. Management should not require the same vendor as execution.
Splitting the two is how you keep swap freedom (models, IDEs, hosts) without giving up fleet coherence. The management plane can be boring technology: chat, tmux, files, SSH, because boring is portable.
| Concern | Execution (per agent) | Management (fleet) |
|---|---|---|
| Purpose | context.md + sandbox rules for one name | 1:1:1:1 naming, scoped hosts, channel per agent |
| Verification | Tool results inside the run | Human in-channel, dispatch log, optional STOP |
| Coordination | Single-threaded work in pane 1 | Rocket.Chat dispatch, webhooks, routines in pane 2 |
| Governance | Enforced paths in sandbox.json | Per-agent JSONL audit, SSH boundaries, no shared secrets in prompts |
| Swap | Replace Cursor CLI or model without renaming the agent | Hibernation, static-linked apps, open-source harness |
A system suited to scale, without lock-in.
These are the properties we optimized for in JARVIS v4 after the bundled approach stopped scaling. None of them require our consulting engagement; they are what the open-source harness implements.
Independent record
Every inbound dispatch and outbound reply appends to logs/dispatch.log on disk, not inside the model’s memory. A human can contradict or approve in the same Rocket.Chat thread the agent uses.
Filesystem + SSH as API
Context, permissions, and apps are files you can diff and copy. SSH host per agent gives a boundary that survives vendor UI changes. See Agent OS.
One window, one server
Fleet scale comes from binding each context to one machine, not from stuffing every client into one mega-prompt. See one context window per server.
Anti-lock-in here means management logic lives in repos you control: MIT-licensed harness, static-linked app copies per agent, no single cloud control plane that must approve a model change. The execution runtime (today, Cursor in tmux pane 1) is an implementation detail behind a stable interface: messages in, scoped work, messages out.
Governance is not a dashboard slogan. It is default-deny sandboxes, channel-scoped identity, JSONL you can ship to SIEM if you need to, and blast radius you can state in one sentence per agent.
How the harness carries management.
The loop is deliberately dumb and therefore inspectable, as detailed in the JARVIS v4 case study:
- Allocate purpose
agents/<name>/context.mdstates identity, allowed SSH host, utilities, and routines. The model reads it every boot; humans edit it like config. - Dispatch work — Pane 2 monitors one Rocket.Chat channel per agent (~10s poll), logs the event, forwards to pane 1. Webhooks and site forms use the same front door.
- Execute under scope — Pane 1 runs the agent runtime with
.cursor/sandbox.json+rules/sandbox.mdc: machine enforcement plus prose the model is trained to respect. - Verify in the open — Replies go back to the channel via
rocketchat.py send, not private completion text. Stakeholders see the same thread; the log preserves it if the UI rotates.
That loop is the management layer. Swapping Claude for another model, or Cursor for a future CLI, does not throw away channels, logs, directory layout, or SSH mapping, as long as something can still read a message and write a reply in pane 1.
What you pay for the split.
More moving parts than a single SaaS agent. You operate tmux, SSH keys, and chat infrastructure, or pay someone to harden it once. Latency includes dispatch poll interval, not just model TTFT. Fleet-wide upgrades are file fan-out, not a vendor button.
We accept that cost because the alternative at 164 agents was either one omniscient context (unsafe) or 164 siloed products (unauditable). Management in the open was the third option.
Intelligence needs a manager.
This page is the architectural argument behind Agent Accelerated consulting: we design and run the management plane: dispatch, context, supervision, logging, so execution can stay fast and swappable. If you are still in the “one bundled agent” phase, stay there until scale forces the split; when it does, the shape here is what we ship in production and open-sourced under MIT.
Start a conversation All case studies