The Bottleneck in Multi-Agent Systems Isn't the Model—It's the Engineering Outside It

Many software engineers are going through an identity crisis: agents have taken over a huge chunk of writing code, making their own skills feel less relevant. In *The new set of problems for engineers to solve*, Katelyn Lesse, Head of Platform at Anthropic, makes the opposite case: models will keep getting stronger, but whether multi-agent systems can actually get real work done depends on whether engineers can solve a new set of engineering problems.

I agree with this assessment. When I previously wrote Agent Harness Is the Operating System Layer of the AI Era, I was talking about the layer wrapping a single agent: the loop, tools, context, and memory. When you zoom out to hundreds or thousands of long-running, collaborating agents, the problem shifts from "how to keep a single agent running reliably" to a distributed systems problem.

How Single Agents Evolved into Multi-Agent Systems

Agents started out as human-in-the-loop chat. Once models could run longer on harder problems, agent systems began moving to the cloud. At the same time, as models got better at collaboration, people started building simple multi-agent systems: an orchestrator dispatching a few sub-agents per task, or dedicated agents that don't execute tasks themselves but instead score outputs and offer feedback.

Now, people are building truly large-scale multi-agent systems for serious research, scientific discovery, and hardware design. Imagine thousands of agents working continuously toward a single goal—new engineering problems are already emerging. Katelyn groups them into four categories.

Runtime: Agents Are Not Stateless Services

For years, the software industry has been built on Kubernetes. It was designed for stateless applications that can be replicated across multiple pods, or stateful sets with stable, numbered identities.

Agents are a completely different workload. Each agent is fundamentally an isolated, stateful singleton. Between bursts of work, it might sit idle for an arbitrary amount of time, spending most of its lifecycle waiting—on tools, on model inference, on other agents, or on a human reply. The workload is also highly bursty: some tasks demand fast cold starts, others require zero wasted compute while waiting, and still others need to handle massive concurrency.

People are already pushing this forward: AI infrastructure companies are building new filesystems and sandboxes, and a team at Google is working on a new runtime called Agent Substrate. Still, there is plenty of room left for engineers to build.

Identity and Authorization: On Whose Behalf Does an Agent Act?

Authentication—identifying *which* agent performed an action—can borrow battle-tested building blocks from microservices, such as using short-lived certificates as workload identities instead of static keys.

Authorization is much harder: what is an agent actually allowed to do? Many agents act on behalf of a human, accessing systems directly using that person's identity and credentials. The first problem is auditing: after the fact, it is hard to tell whether an action was taken by the human or the agent. A deeper problem is consent: when a multi-agent system runs continuously for weeks, how can a human meaningfully approve what it is allowed to do? Auto-approving tool calls is a starting point, but as systems scale, we need much more granular permission models.

Going a step further—giving agents their own independent identities—lacks mature solutions even more. And when multiple agents collaborate, on what basis should one agent trust a request coming from another? Right now, there is no good answer.

Security and Isolation: If One Agent Is Compromised, How Far Does It Spread?

Over the past few months, vulnerabilities have been discovered faster than the industry can patch them, many in core software that countless systems depend on. Imagine thousands of long-running agents running on top of this software, writing untrusted code while reading untrusted content—those unpatched vulnerabilities become far more dangerous. Hardening kernels, browsers, runtimes, and common libraries is therefore one of the most urgent tasks for engineers right now.

Multi-agent systems add another layer of trouble. A compromised agent can pass injected instructions to other collaborating agents; those instructions might even get written into memory and treated as trusted context by future agents. When the first agent is compromised, what percentage of the entire system is at risk? That is the blast radius. Consequently, when agents execute actions, they must be placed inside strongly isolated sandbox environments.

Monitoring and Kill Switches: The Hardest Part Is Knowing When It Goes Off Track

Finally, we need tools to verify that these systems are heading in the right direction, and to catch and cut them off in time when they go off track. This includes cross-agent OpenTelemetry tracing—with guarantees that an agent cannot tamper with its own traces or those of other agents. It also includes a monitoring-triggered kill switch capable of bringing the entire system to a true, immediate halt and revoking all credentials at once.

The truly difficult part is figuring out when a system has started to go off track. An agent's persistence in trying to solve a problem can look almost identical to malicious behavior. For example, if it repeatedly tries to access a domain that isn't on the allowlist, it is hard to automatically tell whether it is creatively working around an obstacle or has been hijacked by a prompt injection attack.

My Own Small-Scale Version

I don't have thousands of agents at my disposal, but when maintaining perryOS, I regularly run several agents in parallel: one main agent breaks down tasks and reviews the work, while other agents handle the frontend, backend, and copywriting. Even at this much smaller scale, all four categories of problems show up in miniature.

• Isolation: Only one agent is allowed to touch a given file at any time; when multiple agents need to modify the same area of the codebase in parallel, each gets its own separate git worktree.
• Authorization: Sub-agents never run git add or commit; the main agent reviews the changes and commits them centrally. This is effectively a permission boundary: worker agents can modify files, but they cannot write changes into version history.
• Monitoring: Relying on the on-screen status to tell whether an agent has finished is unreliable. Some agents show "completed" when they've actually just paused mid-task, so I always inspect their output to confirm the work is genuinely done before dispatching the next step.

Every one of these rules was added after learning the hard way; not a single one emerged naturally just because the models got smarter. In fact, the more capable the model becomes, the more important these rules get—because the agent can do a lot more while you aren't looking.

What I'm Still Unsure About

Katelyn leads platform engineering at a frontier lab, so her article is written from the perspective of cloud-scale multi-agent platforms. Thousands of agents collaborating to crack scientific problems is still mostly a vision today, and solutions mentioned in the piece—like Agent Substrate and short-lived workload certificates—are still in their early stages rather than settled standards.

For individuals and small teams, I still haven't figured out how much of this stack we actually need to build out. Running agents under a human identity and letting them read web pages carry the exact same risks in a small setup, but whether it's worth the cost to build dedicated sandboxes and a one-click credential-revoking kill switch just for a handful of agents is a question I don't have an answer to yet.

Questions I Want to Figure Out Next

• When one person runs a few agents in parallel, what is the minimum viable kill switch: is killing the process enough, or do you also need a way to revoke the credentials it holds?
• When an agent reads web pages and external documents, how do you prevent injected instructions hidden in that content from being written into long-term memory and treated as rules by future agents?
• When an agent runs under my identity, how should its actions be audited after the fact so they can be distinguished from actions I took myself?

References

• *The new set of problems for engineers to solve*: Published on X by Katelyn Lesse (Head of Platform at Anthropic), October 26, 2026. The evolutionary path of multi-agent systems and the four categories of engineering problems—runtime, identity and authorization, security and isolation, and monitoring and kill switches—are drawn from this article.