cd /news/ai-agents/you-re-running-a-fleet-nobody-staffe… · home › topics › ai-agents › article
[ARTICLE · art-157059] src=fromtheterminal.substack.com ↗ pub= topic=ai-agents verified=true sentiment=· neutral

You're Running a Fleet. Nobody Staffed the Ops Team.

A developer built agent-usage-guard, a Claude Code mod that adds machine-wide admission control to autonomous agent sessions after a single research prompt spawned 394 subagent calls, 341 running concurrently, pushing 84M context tokens through the API in ten minutes and exhausting a five-hour usage window. The tool fires hooks before agents start, before prompts are sent and before tool calls run, defaulting to four concurrent agents, twelve starts per ten minutes and 10M subagent tokens per ten minutes, refusing at 95% of a window and failing open. Separately, Nvidia released OpenShell, a gateway, supervisor and sandbox runtime that enforces file, syscall and network limits at the kernel level, keeps credentials out of agents, and formally verifies policy changes for new access before human review.

read6 min views7 publishedOct 25, 2026
You're Running a Fleet. Nobody Staffed the Ops Team.
Image: Fromtheterminal (auto-discovered)

The most interesting agent tooling this week wasn't a model or a smarter harness — it was plumbing, and the plumbing says we stopped running assistants and started running fleets.

1. One Prompt Spawned 394 Subagents. The Bill Landed in Ten Minutes. #

The clearest account of the new failure mode comes from a Claude Code mod built after a single research prompt spawned 394 subagent calls, 341 of them running at once, pushing 84M context tokens through the API in ten minutes. Session over, five-hour window gone. Sixty days of logs held 12 lockouts and 166 ten-minute windows with agent bursts, and it generalizes: half a weekly plan consumed by recursive spawning, multi-agent runs burning roughly fifteen times the tokens of a chat session.

The diagnosis beats the anecdote. Lockout isn't caused by any one of large context, rapid tool loops, parallel agents or blind retries — it's the product of all four, which is why it arrives as a cliff rather than a slope. The guard removes one factor at a time and acts before the spend rather than reporting it after: hooks fire before an agent starts, before a prompt is sent, before a tool call runs. Limits are machine-wide, because four sessions each politely staying under their own cap is how you hit the real one. The defaults are mundane and sane — four agents at once, twelve starts per ten minutes, 10M subagent tokens per ten minutes, no subagents spawning their own, ask at 80% of a window and refuse at 95%. With nobody at the keyboard it refuses and tells the model why, so the agent batches or waits instead of burning the window on retries. And it fails open: a broken governor should never break the session.

Strip the branding and this is admission control, the oldest idea in distributed systems, arriving in your editor two years after your agents started behaving like a thundering herd. Concurrency and context are capacity, and capacity needs a limiter.

Why it matters:

  • For ICs: Your usage window is a shared resource across every session on your machine. Cap fan-out and recursion depth before the run that matters gets locked out.
  • For leaders: Agent spend is bursty by construction, so averages hide it. Alert on peak concurrency and tokens per ten minutes, not monthly totals.
  • For founders: Quota exhaustion is an incident class with no runbook. Predicting, throttling and attributing agent spend is wide open.
  • The broader pattern: every autonomous system eventually grows a governor. The question is whether you write it before or after the outage.

2. Nvidia Shipped a Runtime for Agent Fleets. Permission Stopped Being a Prompt. #

Spend is the cheap failure; access is the expensive one, which makes a safe, private runtime for fleets of autonomous agents out of Nvidia the more consequential release. It is honest about the tradeoff: agents are useful precisely because they read files, install packages, call APIs and use credentials, so the answer can't be to take those away. Instead each agent runs in a sandbox with kernel-level enforcement on file access, system calls and network connections, and credentials never reach the agent at all — the gateway injects them only into requests bound for approved endpoints.

The part worth copying is not the sandbox but the workflow around the policy. Agents constantly need access they didn't have yesterday, so the real question is who approves the diff. Before a policy change applies, the system runs formal verification over it to flag what new access it would grant — reaching a new host with credentials, calling a new API method — and sends those changes to human review. That's the difference between a sandbox and a security program: one blocks the agent, the other tells you what you just agreed to. It ships as a gateway, supervisor and sandbox, with Helm charts and a hard dependency on your network plugin actually enforcing NetworkPolicy: the target is a cluster, not a laptop.

Compare that to how most teams do agent permissions today: a line in a config file asking the model not to touch production. That's a code of conduct, not a control. Only moving the boundary down to the syscall survives an agent that is confused, jailbroken, or unlucky with a package it installed.

Why it matters:

  • For ICs: Treat prompt-level restrictions as documentation. If an agent can read a credential, assume it can leak it; a credential-injecting proxy is the fix.
  • For leaders: Write down what each agent class may touch, then pick a runtime that enforces it. "The agent runs as the developer" is the default, and it is indefensible on paper.
  • For founders: The reviewable policy diff — what would this let the fleet do that it couldn't before — is the piece most agent platforms still lack.

3. A Vendor Just Open-Sourced the Software Factory It Was Selling #

The third move is about owning the layer above both. The company behind one of the better agent control planes open-sourced its core under Apache 2.0: the desktop app, the daemon that runs Claude Code and Codex sessions on your machines, the cloud API, the Postgres sync proxy, and the data model underneath — orgs, teams, projects, tasks, sessions, plans, diffs, pull requests, and the Jira, Linear, GitHub and Slack integrations.

The stated reason is the sharpest argument in this space right now: once your agent can read and patch the source of every tool you use, closed-source tools turn frustrating, because you can't fix them, can't customize them, and wait on someone else's roadmap. Agents invert the economics of open source: modifying a dependency used to cost an engineer's week, and now it costs a session. A black box in the middle of your software development lifecycle is no longer only a vendor risk, it's a throughput tax.

The published data model matters too: sessions, plans, diffs and comments as first-class entities is a claim about the unit of agent work — not the chat, but the task with a reviewable trail attached. Self-hosting is rough today, and open-sourcing a control plane widens the security surface in a week when a popular model proxy shipped a compromised release. But it shows where the moat moved: not the harness, which is commoditizing, but the record of what your fleet did and why.

Why it matters:

  • For ICs: Prefer tools your agent can patch. Fixing a tool in-session is a real selection criterion now, not a philosophical one.
  • For leaders: Insist on an exportable record of agent work — sessions, plans, diffs, approvals. That trail is the audit story you will be asked for.
  • For founders: Selling a closed harness is a shrinking business. Selling the control plane, the policy and the record is not.

The Verdict: Real or Hype? #

Admission control for agent spend and concurrency → Real. The failure is measurable and already costing people working days; the fix is boring and ships today. Kernel-enforced agent sandboxes with reviewed policy changes → Real but early. The enforcement is sound, but the cluster-shaped deployment puts most teams a quarter away from it. Open agent control planes → Real. Once an agent can patch any tool it touches, closed devtools lose on velocity, not ideology.

── more in #ai-agents 4 stories · sorted by recency
── more on @claude code 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
→ Live at https://your-agent.zahid.host ✓
Get free account → Pricing
from €0/mo · no card required
LIVE [news/you-re-running-a-fle…] indexed:0 read:6min 2026-10-25 · —