Anthropic Platform Lead: Multi-Agent Deployment Stuck on Infrastructure, Identity, Isolation, and Kill Switches
Anthropic platform lead Katelyn Lesse believes that no matter how powerful the models become, multi-agent systems producing trustworthy results still depends on engineers getting infrastructure, identity and authorization, security isolation, observability, and kill switches right—and most of these problems remain unsolved. She points out that agents are isolated, stateful, single-instance workloads, unlike the stateless replicas Kubernetes excels at, and names new runtimes such as Google's Agent Substrate. She also warns that a compromised agent can pass injected instructions to its peers, with a system-level blast radius, so actions should run inside strongly isolated sandboxes.
View original postsoftware engineers are going to have to tackle a new set of problems to unlock powerful multiagent systems to solve the world's hardest problems - right now is one of the most interesting moments in history to be an engineer. https://t.co/YsQ0xta4KR
View original
software engineers are going to have to tackle a new set of problems to unlock powerful multiagent systems to solve the world's hardest problems - right now is one of the most interesting moments in history to be an engineer. https://t.co/YsQ0xta4KR
Body · AI translation
In the multi-agent era, engineers must solve infrastructure, identity, isolation, and emergency stop
Anthropic platform lead @katelyn_lesse believes that engineers' "identity crisis" is being viewed backwards: no matter how strong models become, for multi-agent systems to produce trustworthy results, people still need to get infrastructure, identity and authorization, security isolation, observability, and emergency stop right; most of these problems remain unsolved, and they are precisely the main battlefield for engineers over the next year or two.
Background: from human-machine conversation to swarms of persistent agents Agents have moved from "chat with a human in the loop" to longer-horizon, cloud-based operation; then came orchestrators spawning sub-agents, as well as non-execution roles such as scoring, advising, and "dreaming." The next imagined step is tens of thousands of agents collaborating over the long term on serious research, discovery, and hardware design. As the capability frontier moves outward, a set of software engineering problems has already surfaced.
Problem one: infrastructure needs a rethink Kubernetes excels at stateless replicas or stateful Pods with stable ordinals; agents are more like isolated, stateful, single-instance workloads: they may sit idle for long periods, spending much of their time waiting on tools, inference, other agents, or humans. Some need fast cold starts, some need to waste little compute, and some need extreme scaling. The author points to AI infrastructure companies building new file systems and sandboxes, as well as new runtimes like Google's Agent Substrate, and says there is still a lot of room here.
Problem two: identity and access On the authentication side, we can borrow from what microservices have accumulated: workload identity and short-lived certificates replacing static keys are starting to be applied to agents. Authorization is more open-ended: most agents act "on behalf of a person" using that person's credentials, so first we must distinguish whether an action was taken by the human or by the agent; harder still is consent under on-behalf-of: when a system runs for weeks, how can a human meaningfully approve permissions? "Auto-approve tool calls" in a platform is not enough; deeper permission models are needed. Agents having their own identity, and how agents trust one another, are even less mature.
Problem three: security and isolation In recent months (especially recent weeks), core software vulnerabilities have been emerging faster than patches. If thousands of persistent agents run on top of that, writing untrusted code and reading untrusted content, the danger of unpatched vulnerabilities is amplified. The author calls for more creative hardening of kernels, browsers, runtimes, and commonly used libraries. Multi-agent systems also face lateral spread: a compromised agent passes injected instructions to its peers, and once those instructions enter memory they are mistakenly trusted by later agents, so the blast radius is system-level. Actions should therefore take place inside strongly isolated sandboxes (see her blog post on sandbox architecture for details).
Problem four: monitoring and emergency stop We need cross-agent OTel tracing, and agents must not be able to alter their own or others' traces; we need a kill switch that monitoring can trigger, stopping the entire system at once and cutting off credentials. The hard part is often determining what counts as "going off the rails": well-intentioned persistence (for example, repeatedly hitting a domain that is not on the allowlist) looks a lot like malice.
The attitude toward engineers The ending is a call to action rather than pessimism: the people who think their skills are about to be devalued may be exactly the people who determine whether these systems can be trusted and whether they can cure disease rather than cause harm. The problem space is largely blank, and it is worth digging into deeply and forming judgments.