Tool Calling Moved the Bottleneck From Prompts to Permissions

The test suite is the clock now. When a background agent picks up a ticket, the four minutes it spends waiting on continuous integration is the longest single pause in its working rhythm, longer than reading the stack trace and longer than the edits themselves. The average autonomous coding session grew from roughly four minutes in early 2025 to about twenty-three minutes in 2026, and each of those sessions now fires around 47 tool calls, the model reaching out to a shell, a test runner, a linter, a package registry, then reaching again.

Software design has been reorganising itself around that loop ever since. The unit of design stopped being the response and became the trajectory: a sequence of permitted actions, observations and retries that has to end somewhere a human can audit. Everything interesting about the 2026 toolchain follows from one asymmetry. A bad answer is cheap. A bad action is not.

What a tool call actually does

A language model doesn't run anything. It emits a structured object, usually JSON, naming a function and its arguments, and something else decides what happens next. That something else is the harness, and its job is unglamorous: parse the object, check it against a declared schema, decide whether this call is permitted in this context, execute it against the real system, then return the result as text into the context window where the next decision gets made.

The analogy that holds up is a ship's telegraph. The officer on the bridge doesn't turn the propeller. He rings an order down the tube, and the engine room either obeys or reports back that it can't. What the officer knows about the world is limited to what comes back up the tube, so the quality of the instrument matters as much as the quality of the officer.

This is why tool output design has quietly become interface design. A test runner that returns "3 failures" and nothing else leaves the agent blind and prone to retrying the same broken fix. A test runner that returns failing suite names, line numbers and the assertion diff gives the loop something to steer on. The same model, wired to two different tools, produces two entirely different failure rates.

Why the chat window ran out of road

The chat interface made the human the message bus. Every step that needed a decision, a permission or a paste of output went through a person, and each round trip cost latency, attention and context capacity that the model couldn't spend on the actual problem. Ask a chat assistant to fix a failing build and you spend four turns establishing which build, which branch, and whether it's allowed to touch the payments module.

Chat works for retrieval because retrieval ends when the answer arrives. Execution doesn't end, it branches. The architectural fix was to move the human from between the steps to the two ends of the session: intent at the front, review at the back. That single change is what turned a copilot into a background process, and it's why sessions got longer while individual turns stayed about the same length.

Session length became the metric, and the metric hides a multiplication problem

Anthropic's analysis of agent autonomy, published in February 2026 and drawn from millions of Claude Code and API interactions, found that among the longest sessions the time an agent worked before stopping nearly doubled in three months, from under 25 minutes to over 45. The increase was smooth across model releases, which points at something less obvious than raw capability: people were granting more rope as they learned to trust the harness. Median turn duration held flat near 45 seconds throughout.

Read those two numbers together and the mechanism becomes visible. A 23-minute session divided across turns of roughly 45 seconds is a session built from many steps, not from longer deliberation inside each one. METR's long-task measurements found the length of software work agents can complete doubling on a roughly seven-month cadence, and the same logic applies inside a single run. The frontier is a count of steps rather than a depth of thought. Step counts are where reliability gets brutal, because per-step accuracy compounds rather than averages.

An engineer scoping a harness at 99% per-step reliability can expect a clean 47-call run about 62% of the time. Getting to a dependable background agent means chasing two nines, then three, and every additional nine costs real work in validation, deterministic retries and hard checks wrapped around the probabilistic core.

The integration layer settled before the governance did

The plumbing that lets an agent reach all those tools standardised faster than most people expected. The Model Context Protocol, introduced by Anthropic in November 2024, was donated to the Agentic AI Foundation under the Linux Foundation in December 2025, and it now carries backing from Anthropic, OpenAI, Google DeepMind and Microsoft. The public registry went from roughly 1,200 server names at the end of 2025 to nearly 48,000 by late October 2026, with about two thirds of active servers exposing a remote endpoint.

What the protocol does is narrow and useful. It gives models a uniform way to discover tools and call them. What it doesn't do is the part enterprises actually need. It has no native story for multi-tenancy, rate limiting, cost attribution or per-agent identity, so teams are building those as gateways and proxies bolted in front of it. A protocol that's excellent at describing what a tool can do says nothing about who is allowed to call it, from which environment, at whose expense.

The security record is following the usual curve for fast-adopted plumbing. The vulnerability database now carries a running list of MCP-related CVE records that didn't exist eighteen months ago, and the dominant risk isn't a broken server. It's a poisoned one, where a tool description instructs the model to do something the developer never intended. An agent that reads its tool list as trusted context can be reprogrammed by a malicious schema.

The failure moved from the answer to the action

A hallucinated paragraph is embarrassing. A hallucinated delete is an incident. That difference in consequence explains why so much engineering effort in 2026 goes into blast radius rather than intelligence: sandboxed filesystems, scoped tokens, dry-run modes, git branches as a rollback mechanism, and approval gates on anything that touches production or money.

Error propagation is the harder half of it. In a 47-call session, mistake number 12 doesn't stop the run, it becomes an input to calls 13 through 47, and the agent's output often looks more confident as its context fills with its own wrong premises. This is the gap where the verification layer hasn't kept pace with the agents doing the work, and it's why the review step at the end of a session can't be a diff skim.

The practical answer emerging across teams is to make the trajectory observable rather than just the result. Traces that record every tool call with its arguments, raw output and timing, replayable in a clean environment, are becoming the new unit of code review. You read the session, then you read the patch.

What verification can't yet measure

The unsolved problem is credit assignment inside a session. When a 23-minute run produces a pull request that passes its tests, the green suite tells you the tests pass, not that the change is right, and nothing in the trace indicates which of the 47 calls carried the actual insight. Failure is easy to locate because a red test points at it. Success leaves no signal about which step mattered, which makes it hard to tune a harness, compare two tools, or separate the contribution of a better model from the contribution of a better interface.

Benchmarks have spent three years measuring what a model can do in one shot. What now determines whether software ships is what a model does across 47 shots with consequences between them, and there's no settled metric for that beyond whether the patch was accepted. Test suites and human review are both proxies, and both can be satisfied by work that shouldn't have merged.

The bottleneck has moved to the verification surface, and it's a measurement problem no one has solved: a passing suite can't distinguish a patch that works from a patch that happens to satisfy the assertions, and no one can score a long trajectory without reading every call in it. Until that changes, every background agent in production is running on the judgement of whoever scoped its sandbox.