Katelyn Lesse, whose profile identifies her as Anthropic’s head of platform, describes an engineering agenda for persistent multiagent systems. She imagines large groups working on research, discovery, and hardware design. Making those systems useful and controllable requires infrastructure work beyond improving the models.

Four problems to solve

  • Infrastructure for irregular, stateful work. Agents can spend long periods waiting for tools, model responses, other agents, or people. Their environments need durable state, quick startup, and efficient use of resources while idle. Lesse points to new filesystems, sandboxes, and Google’s Agent Substrate as work in this area.
  • Identity and permissions. Authentication establishes which agent acted; authorization establishes what it may do. Short-lived workload credentials offer an existing foundation. Harder questions include delegated human consent over weeks of work and whether one agent should trust another’s request.
  • Security across code, messages, and memory. A compromised agent can pass malicious instructions to collaborators. Shared memory can preserve those instructions for future agents. Strong execution isolation must accompany hardening of kernels, browsers, runtimes, and libraries.
  • Monitoring and a real stop mechanism. Lesse calls for traces across agents that the agents themselves cannot alter. A kill switch must halt the whole system and revoke credentials, not merely stop one visible process.

A persistent agent can look like a dangerous one

The hardest monitoring problem is deciding when legitimate persistence has crossed a boundary. Lesse gives the example of repeated attempts to contact a domain outside an allowlist. A system trying hard to finish its task can produce behavior that resembles an attack.

That makes permissions and enforcement concrete engineering requirements. An explanation in a conversation cannot substitute for a boundary enforced by the surrounding software.

Put the control plane outside the sandbox

Her linked architecture and sandboxing guide develops the isolation point. Keep the agent’s controlling loop, durable state, and credentials outside the environment running untrusted code. Route outbound requests through a restrictive proxy that supplies credentials only for approved destinations.

This separates the software carrying out actions from the systems that authorize, record, and stop those actions. It also reduces the chance that compromised code can disable its own supervision.

Caveat: these are design recommendations and open engineering problems, not measured evidence that large agent teams deliver the research outcomes described.

Lesse’s answer to engineers worried about their future is specific: runtime design, identity, access control, isolation, and observability remain work that capable models cannot replace by themselves. Reliability depends on how those pieces fit together.