A lot of software engineers are asking whether their craft still matters. On October 26, 2026, Katelyn Lesse, head of platform at Anthropic and previously at Stripe, posted an essay on X that answers with a specific list of unsolved problems. Her claim is that AI "just isn't going to be able to create the incredible outcomes it's capable of creating unless software engineers solve problems to make it possible."
The essay is not a product launch. It is an expert's map of what breaks when you move from one chatbot to thousands of persistent agents working together. This post turns that map into a checklist you can use, and flags where we agree, where we add detail from other coverage, and where the essay is opinion.
TL;DR: the four problems
| Problem | What breaks | What to do now |
|---|---|---|
| Infrastructure | Agents are stateful, single-instance and mostly idle, not stateless replicas | Choose a runtime built for idle-heavy, bursty workloads and fast sandbox startup |
| Identity and access | You cannot tell the agent from the human, and consent does not scale over weeks | Give agents their own short-lived identity and narrow, expiring permissions |
| Security and isolation | One compromised agent can poison others through messages and memory | One sandbox per agent, scoped credentials, treat inter-agent input as untrusted |
| Monitoring and halting | Persistence looks like malice and agents can touch their own logs | Tamper-proof tracing and a kill switch that stops everything and revokes credentials |
Agents that act on your behalf need rules. Agentbeam stops the dangerous actions →
Why multiagent systems create new problems
The essay traces a short history. Agents began as human-in-the-loop chats. Models then got better at running longer on harder problems, so agentic systems moved to the cloud. Models also improved at working together, which led to basic multiagent setups: an orchestrator that spawns subagents, or agents given jobs other than executing, such as grading, advising or "dreaming".
Now, she writes, some teams are building systems with thousands of persistently running agents aimed at hard targets like research, discovery and hardware design. That scale is what turns small gaps into engineering problems. If you want the design patterns first, our guides to multi-agent orchestration patterns and error propagation in multi-agent systems cover how these systems are structured and where they fail. Anthropic's own take on persistent agents, including dreaming, is in our post on Claude Managed Agents and multiagent orchestration.
Problem 1: infrastructure built for a different workload
The essay's central point is about what agents are. Kubernetes, she writes, was designed for stateless replicated apps or stable numbered sets of stateful pods. Agents are "essentially isolated, stateful, single-instance workloads". They can sit idle for arbitrary stretches and spend much of their time waiting on tools, model inference, other agents or humans.
Different workloads want different things: some need fast startup, some must avoid wasting compute while idle, and some need very large scale. The essay names AI infrastructure companies building new filesystems and sandboxing offerings, and Google's Agent Substrate as a new runtime.
We have covered that Google work separately, including what is claimed and what is verified, in Google Agent Compute Engine and Agent Substrate, and the Kubernetes-side approach in Google's AX agentic orchestrator. DeepSeek's scale numbers for sandboxes are in the DSec agent sandbox post.
What to do as a builder
- Measure your idle ratio. If your agents spend most of their time waiting, per-second billing and snapshot-and-resume matter more than raw CPU.
- Separate state from compute. Keep memory and files outside the sandbox so you can stop and resume agents without losing work.
- Plan for bursts. An orchestrator that spawns fifty subagents at once needs capacity and rate limits planned in advance.
Problem 2: identity and access
The essay splits this into authentication (who did this?) and authorization (what may it do?).
Authentication has a head start. Microservices already gave the industry workload identity with short-lived certificates instead of static keys, and the essay says teams are starting to apply those ideas to agents.
Authorization is "much more wide open." Many agents act on behalf of a human using that person's identity and credentials. There is already a problem: logs show the human, not the agent. And there is a deeper one, consent. If a multiagent system works for weeks, how does the person meaningfully approve what it does? Features like auto-approval of tool calls help, but she argues deeper permissioning is needed at high scale. Agents with their own identity are even less solved, as is the question of how one agent should trust another that asks it for something.
Two keys at one door illustrating separate agent and human identity for on-behalf-of access
What to do as a builder
- Give each agent its own identity rather than borrowing the human's token, so logs say which actor did what.
- Use short-lived, narrowly scoped credentials issued per task, not long-lived keys stored in environment files.
- Make permissions expire. A grant for a week-long run should not outlive the run.
- Treat requests from other agents as untrusted input, verified against what that agent is allowed to ask for.
These are the same least-privilege habits that apply to people, applied at machine speed. See our dictionary entry on least privilege for the short version.
Problem 3: security and isolation
This is the section with the most urgency. The essay says that in recent months, and especially the past couple of weeks, vulnerabilities have surfaced faster than the industry can patch them, much of it in critical core software that many systems rely on. Now picture thousands of persistent agents running on top of that software, writing untrusted code and reading untrusted content. Unpatched bugs get more dangerous in that world.
Her ask of engineers is to get creative about hardening kernels, browsers, runtimes and common libraries. If the vocabulary is new, start with our explainer on zero-days and how AI changes the clock.
The multiagent twist
Multiagent systems add a risk single agents do not have. A compromised agent can pass injected instructions to the agents it works with, and those instructions can land in memory that future agents trust by accident. The question becomes the blast radius: how much of the system is at risk once the first agent is compromised?
Our reporting on agents that attacked each other in a multiagent turf war shows why this is not hypothetical, and Vercel's confirmed KVM zero-day shows that even the isolation layer can have flaws. The essay's answer is strongly isolated, sandboxed execution for every action. We compare isolation models in Google Cloud's agent sandboxes.
What to do as a builder
- One sandbox per agent, with no shared writable memory by default.
- Scope network access to an allowlist, and log every denied attempt.
- Treat memory as an input channel. Anything an agent writes that another agent will read later is a prompt injection path, so mark its origin and review what gets promoted to shared memory.
- Assume the sandbox can fail. Keep credentials short-lived so an escape yields little.
If you run agents against real systems, AgentBeam, from the explainx.ai team, is built to stop agents before they take dangerous actions.
Problem 4: monitoring and halting
The last section is about knowing when a system is going wrong and being able to stop it. The essay asks for three things.
- OpenTelemetry tracing across agents, with a guarantee that an agent can never modify its own trace or another agent's.
- Kill switches that monitoring can trigger, which truly stop the whole system at once and cut off its credentials.
- A way to detect wrong direction. This is the hard part. The essay's example is that well-intentioned persistence can look like maliciousness, such as repeated attempts to reach a domain that is not on the agent's allowlist.
That example deserves attention. An agent trying again and again to reach a blocked domain could be a stuck loop, a bug, or an attack, and the log line is identical. The practical answer is to define in advance what counts as an escalation, for example three denied network attempts or any write outside the task directory, and to pause the agent and ask a human at that point instead of trying to judge intent.
What to do as a builder
| Control | Minimum viable version |
|---|---|
| Tracing | Emit traces to a store the agent has no write access to |
| Budget limits | Hard caps on tokens, time and spend per agent and per run |
| Escalation rules | Pause on repeated denied actions, out-of-scope writes and unexpected new tools |
| Kill switch | One action that halts every agent and revokes every credential, tested regularly |
| Review | A human reads a sample of traces each week, not only alerts |
What people are asking
Is this about Anthropic's own products?
No. It is a personal essay by an Anthropic leader about the industry. Anthropic's product details live in its docs and announcements. We treat the essay as informed opinion and mark where we add outside facts.
Do I need all four fixes for a small project?
No. A single agent with a human in the loop needs far less. The problems grow with autonomy, duration and the number of agents. A reasonable minimum for any agent that runs code: an isolated sandbox, scoped short-lived credentials, a spend cap, and a way to stop it.
Will models solve this on their own?
The essay argues the opposite: models will keep improving, but the surrounding engineering decides whether people can trust them with consequential work. Better models make good infrastructure more valuable, not less.
What should an engineer worried about their career do?
The essay's advice is to go deep in one of these domains, learn new things and form opinions, because much of the space is open. If you want a structured path, our workshops cover building and securing agents, and our subagents guide for Claude Code is a hands-on place to start.
The short version
If thousands of agents are going to work for weeks, the runtime, the permissions, the sandboxes and the off switch have to be designed for them. None of the four problems is solved by a better prompt. All four are classic engineering work, which is the essay's point and why it reads as encouragement to engineers rather than a warning.
Related reading
- Multi-agent orchestration patterns guide
- Multi-agent error propagation patterns
- Claude Managed Agents, dreaming and multiagent orchestration
- Google Agent Substrate: claimed vs verified
- Google Cloud agent sandboxes: five things on isolation
- Vercel KVM zero-day and agent sandboxes
- What is a zero-day?
- Claude Code subagents and multi-agent workflows
This post summarizes an essay posted on X on October 26, 2026 and adds context from earlier explainx.ai coverage. Details are accurate as of the publication date.