The open engineering problems of multiagent systems

Names the specific engineering gaps in running thousands of persistent agents: stateful isolated workloads, agent identity and consent, cross-agent injection blast radius, and tamper-proof tracing with kill switches.

• The author argues agents fit Kubernetes poorly: they are isolated, stateful, single-instance workloads that can sit idle for long stretches waiting on tools, inference, other agents or humans, unlike the stateless replicas and numbered stateful pods Kubernetes was designed for.
• Agent authentication can reuse hardened microservice patterns such as workload identity with short-lived certificates instead of static keys, the post says, but authorization is far less solved, especially meaningful human consent when an agent acts on someone's behalf for weeks.
• In a multiagent system, a compromised agent can pass injected instructions to its peers and into memory that future agents may trust. The post's answer is strongly isolated sandboxes for agent actions, to limit how much of the system one compromise can reach.
• The post calls for cross-agent OTel tracing that no agent can alter, its own or another's, and kill switches that halt the whole system and cut its credentials at once. Detection is the hard part: good-faith persistence, like retrying a blocked domain, can look malicious.

• AI agent — An AI system that doesn't just answer once but works toward a goal in a loop — taking actions, reading the results, and deciding what to do next.
• inference — Running a trained model to get answers — the phase where AI is actually used, as opposed to trained.

• articleMultiagent SystemsAnthropic research
• articleHow We Built Our Multi-Agent Research SystemAnthropic
• articleScaling Managed Agents: Decoupling the brain from the handsAnthropic Engineering

Checking sign-in…

Loading comments…