← All articles
Agentic AI

Background Agents Arrived — and Brought Rationing With Them

Vishal Sharma·July 19, 2026·7 min read

In three weeks, asynchronous agents crossed from feature to platform: background by default, drivable from a phone, governed by admins. In the same releases, vendors started capping how many an agent may spawn. Both halves of that sentence matter.

A snapshot as at 19 July 2026, based on vendor changelogs from the preceding three weeks.

Changelogs are an underrated form of industry analysis. They are dull, specific, and — unlike announcements — they tell you what a company actually believed was worth engineering. Read across the major agent tools for the three weeks to 19 July 2026, and two changes appear simultaneously in the same releases.

The first: asynchronous agents became the default rather than a feature. The second: vendors began rationing them. These are not in tension. They are the same event viewed from the engineering side and the economics side.

Asynchronous went mainstream

The evidence, dated:

  • 25 June — Codex Remote reached general availability, with authenticated pairing between a phone and a host machine.
  • 29 June — Cursor shipped an iOS app in public beta with remote control of desktop agents and push notifications for agent status.
  • 30 June — Cursor added team-level MCP servers, centrally configured and distributed by administrators with organisational group access controls.
  • 9 July — Codex was integrated into the ChatGPT desktop application, adding PR review with inline annotations.
  • 10 July — Cursor added cloud agent hooks for observing prompts, responses, reasoning and subagents.
  • 17 July — Claude Code made subagents run in the background by default, and made forking a conversation produce a new background session rather than an in-session subagent.

Taken together this is a genuine change in interaction model. The assumption underneath a chat assistant is that a human is waiting. Once agents run in the background, that assumption dissolves, and a set of previously irrelevant questions become product requirements: How do I know it finished? How do I inspect what it did? How do I stop it from my phone? Push notifications and remote control are not conveniences here — they are the necessary consequences of work that outlives your attention.

The administrative additions point the same way. Team-configured MCP servers with group access controls, and hooks for observing agent internals, are the fingerprints of enterprise deployment. Nobody builds admin-distributed configuration for a personal tool.

And then the caps appeared

Here is the part I found genuinely interesting. The same Claude Code release that made subagents background-by-default also introduced per-session caps: 200 subagent spawns and 200 web searches, both configurable by environment variable. MCP calls exceeding two minutes are automatically pushed to the background.

Think about what that combination implies. Making subagents background-by-default removes the natural brake on spawning them — you no longer wait, so you no longer feel the cost. A hard numeric ceiling in the same release is the engineering team observing that once you remove the friction, something has to bound the recursion. An agent that can spawn agents, none of which block, is a system with no inherent termination condition.

Codex's patch notes in the same period mention improvements to dangerous-command detection. Microsoft's Agent Framework releases through late June and early July repeatedly feature progressive MCP disclosure — agents loading and unloading tool schemas on demand rather than holding them all.

The context budget is the real constraint

That last item deserves its own heading, because it is the quiet architectural story of 2026.

MCP's own maintainers observed in April 2026 that tool metadata across dozens of integrations consumes a large share of the context window before any reasoning begins. This is the paradox of a successful integration protocol: every server you connect makes your agent more capable in principle and less capable in practice, because the descriptions of what it could do crowd out the room to think about what it should do.

Progressive disclosure — load schemas on demand, drop them when done — is the obvious response, and it is notable that it is appearing in a major enterprise framework rather than in research. It is also why the incoming MCP revision makes tools/list cacheable with an explicit time-to-live. Both are treating tool metadata as a resource to be managed rather than a manifest to be loaded.

The generalisation worth carrying: context is a budget, and every integration spends some. Teams that connect servers to an agent because they can, without measuring what the tool manifest costs them, will find their agents getting slower and less reliable for reasons that never appear in any single component's metrics.

What this means for how you deploy

  • Budget for runaway loops before you enable background execution. If your platform does not impose spawn caps, impose your own. The vendors added them for a reason and they had more telemetry than you do.
  • Instrument agent economics as a first-class metric. Token spend per completed task, subagent spawn counts, retry rates. Once work happens asynchronously, cost becomes invisible until the invoice arrives.
  • Audit your tool manifest the way you audit dependencies. Every connected MCP server should justify its context cost. Progressive disclosure helps, but the discipline of asking "does this agent need this tool" helps more.
  • Adopt the observability hooks now. Cursor's cloud agent hooks and equivalent facilities exist because inspecting an agent after the fact is how you debug asynchronous work. Retrofitting observability after a bad run is considerably less pleasant.
  • Expect the admin surface to matter. Centrally distributed MCP configuration with group controls is how these tools will be governed in organisations. Deciding your policy before the tools are widespread is easier than clawing it back afterwards.

The honest caveat

Everything above comes from changelogs, and changelogs have a specific evidentiary limit: they are reliable about what shipped and silent about whether it helped. I can establish that background subagents became the default on 17 July. I cannot establish, and have found no current study establishing, that any organisation is getting better outcomes from them.

What the release notes do establish is where serious engineering effort is being spent — and right now a striking share of it is going into governing agents rather than making them more capable. Caps, hooks, admin controls, progressive disclosure, dangerous-command detection. That is what a technology looks like when it moves from demonstrating that something is possible to making it survivable in production.

Making subagents background-by-default removes the friction that used to limit how many you spawn. Shipping a hard cap in the same release is an engineering team saying so out loud.

Sources

Agentic AIDeveloper ExperienceMCPCostEnterprise Architecture

Want to see it in action?

Try the live Document Intelligence demo.

← More articles Try the demo
Background Agents Arrived — and Brought Rationing With Them | Vishal Sharma Cloud