Claude Managed Agents: What 3 Founders Learned Shipping Them

So production agents turn a model call into a small distributed system.

Why do you need a "production" environment? Why can't you just use Claude Code?

Because your agent needs somewhere safe to run code. It needs tools, credentials, memory, permissions, retries, logs, cost controls, and a way to decide whether the work it produced is actually good. Then somebody needs to keep all of that working when the model changes.

That surrounding infrastructure is the agent harness, a concept we've covered in our full explainer on AI harnesses and our beginner guide to building AI agents.

Anthropic's pitch with Claude Managed Agents is basically: we'll run most of that harness for you.

And after listening to three companies already using it in production, the more useful lesson is where that trade becomes worth making.

The dividing line is simple: build the parts that define your product. Rent the infrastructure that only needs to work.

Check out the full Managed Agents interview below.

That framing came up again and again in Anthropic's conversation with teams from Wispr, Actively, and Pendo. Wispr says it built the first version of its meeting assistant in a day. Actively shipped a new cross-account sales agent in roughly two weeks. Pendo moved a product from homegrown agent infrastructure onto Managed Agents within weeks.

Their experiences also expose the hard parts that remain: verifying open-ended work, preventing bad memory from accumulating, evaluating systems whose state constantly changes, and keeping agent economics sane as one agent turns into hundreds.

What Claude Managed Agents actually is

Anthropic gives developers two broad paths.

The Messages API gives you direct model access and lets you control the loop yourself. Managed Agents gives you a pre-built agent harness running on managed infrastructure, aimed especially at long-running and asynchronous work.

Anthropic breaks a Managed Agent into four pieces:

• Agent: the model, system prompt, tools, MCP servers, and skills.
• Environment: the sandbox where the work runs.
• Session: one persistent instance of the agent doing a task.
• Events: messages, tool calls, results, status changes, and other activity flowing through that session.

You create an agent once, create an environment, then start sessions against those reusable definitions. Inside a session, Claude can use Bash, read and write files, search or fetch the web, run code, and call external services through MCP. The platform also handles things such as prompt caching, context compaction, sandbox execution, and event history.

If you're coming from our Agents 101 walkthrough, this is basically the production version of the same mental model. You still design the brain, hands, rules, and job. Anthropic takes over much of the machinery that keeps them running.

Lesson #1: Define success before you obsess over the agent loop

Wispr's most useful example was almost painfully ordinary.

Its meeting assistant creates briefs telling users who they're meeting, why that person matters, what they agreed to discuss, and what they may have forgotten since the last conversation.

That sounds like an easy agent task until it confidently researches the wrong Tom.

Wispr's Sahaj argued that an incorrect brief can actively make the product worse. If the system is proactively helping you and it cannot verify the answer, showing nothing may be a better result than confidently surfacing bad information. Watch the discussion at 2:46

Managed Agents has a feature built specifically around this problem called Outcomes.

Instead of telling the agent only what to do, you define what a successful end result should look like and provide a rubric. Anthropic then provisions a separate grader with its own context window. The grader evaluates the work, tells the working agent which criteria failed, and the agent can revise the artifact until it satisfies the rubric or hits its iteration limit.

That independent context is important.

Wispr deliberately wanted the worker and verifier to make decoupled judgments. The second agent can independently compare the LinkedIn profile, meeting invite, email, and other evidence instead of inheriting whatever assumptions led the first agent to its answer. Watch the explanation at 5:34

Their rubric also measures more than factual correctness. A five-page pre-read can contain accurate information and still fail because nobody will read it.

So they evaluate things like:

• Did the agent identify the correct person?
• Did it surface the most relevant context?
• Is the information attributable to the right sources?
• Is it short enough to scan before a meeting?
• Is the information arranged in the order a user actually needs it?

That is a better way to think about agent reliability than "make the prompt better."

Start with the observable result you can grade. Then let the agent figure out the path.

Anthropic's API supports up to 20 Outcome iterations, with three by default. You can also interrupt an Outcome, steer the session while it runs, or chain a new Outcome after the previous one finishes.

Lesson #2: Memory gets useful when you decide what deserves to be remembered

Actively's product gives salespeople an interesting memory problem.

Its core system has an agent associated with each customer account. Those agents build context throughout an account's lifecycle. Then Actively built Watchtower, a cross-account agent capable of answering questions like:

"What are the five accounts I should work on today?"

That answer may require reasoning across 100 accounts for one salesperson, or 500 accounts for a manager overseeing five reps. Watch the Watchtower explanation at 20:19

The interesting part is that Actively uses two kinds of memory infrastructure.

Some memory is product-critical. The long-lived account memory needs custom indexing, can get corrupted over time, and has to remain stable for the life of the account. Actively owns that architecture itself.

Other memory is useful but generic: what a company's Salesforce fields mean, how its forecasting process works, or an individual user's preferences. Mihir said managed memory is a good fit there because those problems need to work well without becoming Actively's core engineering project.

Anthropic's current memory system follows a similar structure.

A memory store is a persistent collection of documents that survives across sessions. You can make stores per user, project, team, or shared knowledge base. When attached to a session, the store appears inside the agent's sandbox and Claude can read or update it using normal file tools. Stores can be mounted as read_only or read_write.

That access choice matters more than it looks.

Anthropic specifically warns that a read-write memory exposed to untrusted prompts, web content, or third-party tool outputs can become a persistence mechanism for prompt injection. A malicious instruction could get written into memory, then quietly influence future sessions. Anthropic recommends read-only access for reference material that does not need agent edits.

A sensible production pattern is therefore:

Stable company knowledge: read-only shared memory.

User preferences: narrowly scoped read-write memory.

Project history: separate project memory.

Temporary working state: keep it inside the session.

This also gives you different deletion, audit, and retention boundaries instead of dumping the organization's entire history into one giant AI junk drawer.

"Dreaming" turns accumulated experience into cleaner memory

Memory has another problem: useful history becomes clutter.

Anthropic's experimental answer is called dreaming.

A dream takes an existing memory store plus transcripts from up to 100 previous sessions. Claude then verifies, deduplicates, reorganizes, and synthesizes them into a new memory store. The original is left untouched.

Actively described a closely related mental model in the roundtable: account agents learn continuously, then useful concepts can be rolled upward into cross-account or organization-wide knowledge.

That suggests a powerful production loop:

Agents work → sessions generate experience → useful information enters memory → periodic synthesis cleans the memory → future agents start from the improved store.

Anthropic says dreaming currently remains in research preview, so this is one of the pieces to treat as emerging infrastructure rather than a boring production primitive yet.

Lesson #3: Sandboxing becomes mandatory once agents touch real systems

Pendo's use case shows why agent infrastructure becomes annoying very quickly.

Its product analytics agent can inspect a customer's actual codebase, compare that code with what users are doing inside the product, and suggest changes.

That creates a whole pile of security questions.

The source code might contain secrets. The agent may need package access. It could have tools capable of modifying repositories. Eventually, some workflows can generate pull requests back into the customer's codebase. Watch Pendo explain the sandboxing problem at 10:48

Todd's argument was straightforward: Pendo could keep building every sandboxing edge case itself, but safe agent execution was infrastructure the product needed rather than the thing customers were paying Pendo for.

Managed Agents gives every session its own sandbox. For cloud environments, you can install packages and control outbound networking. Anthropic recommends using limited networking with explicit allowed hosts in production and following least privilege.

Tool permissions give you another layer.

The built-in agent toolset defaults to always_allow, while MCP tools default to always_ask. You can override that at either the toolset or individual-tool level. For example, an agent could freely read files and search approved sites but require a human confirmation before running Bash or mutating something through an MCP integration.

That matches the safety rule we've recommended in our beginner agent coverage: give the agent room to read, analyze, and draft, then put approval gates around actions with consequences.

How to build your first useful Managed Agent

Anthropic's quickstart is technically four steps: create an agent, create an environment, start a session, then send events and stream the response.

For a real product, I would think about the setup in a slightly different order.

1. Pick a task where the infrastructure is boring

Good first candidates have a clear deliverable and benefit from running for several minutes, using multiple tools, or working asynchronously.

Examples include a meeting brief, research report, repository review, account analysis, compliance scan, or recurring internal digest.

Wispr, Actively, and Pendo all picked tasks where the valuable differentiator lived above the harness: better meeting context, better sales prioritization, or better product analytics.

2. Define the agent

Your reusable agent config contains the model, system instructions, tools, MCP servers, and skills. Agents are versioned and can be reused across many sessions.

Skills are useful for repeatable company-specific procedures. A custom skill is a SKILL.md plus optional supporting files, while repository-based skills can live under .claude/skills/. Anthropic warns that repo skills are part of the agent's trust boundary because anyone who can modify that repository could modify the instructions an agent loads.

Attach the minimum skills the task needs. Anthropic says mounting more skills increases sandbox startup time anyway.

3. Create the environment and permissions

Choose cloud or self-hosted execution, then narrow network access and tools.

For a production cloud deployment, Anthropic recommends limited networking plus an explicit allowlist. Then decide which tools can run automatically and which require human approval.

4. Attach credentials through vaults

Agents that need Slack, GitHub, or another external system will eventually need authentication.

Managed Agents provides vaults for associating credentials with an end user and making those credentials available when a session starts. Credentials can be rotated while sessions are running, and OAuth credentials can be refreshed automatically.

This is a major production detail because "the agent can call Slack" and "the agent can safely call Slack on behalf of Alice, with revocable credentials" are very different milestones.

5. Give important tasks an Outcome

Write the rubric like a product spec for success.

The more objectively verifiable the criteria, the better. Then add UX requirements for things that still require judgment.

If the agent is creating a financial model, Anthropic's own example evaluates whether the artifact satisfies a DCF rubric. If the agent is creating a meeting brief, you might grade identity, source attribution, relevance, readability, and length.

6. Add memory only after you know what should persist

Keep the first version simple.

Once repeated sessions start rediscovering the same information, you have evidence for what belongs in memory.

Split stable reference memory from writable learned memory. Review what agents write. Use separate stores when different data has different owners or lifecycles. Anthropic supports up to eight memory stores per session.

7. Add a hard budget before you scale

Managed Agents lets you set a hard session budget in dollars at creation time.

The platform continuously calculates list cost from model tokens, web search usage, and runtime. When the cap is reached, the session pauses rather than terminating, preserving its state. One request already in flight can push the final total slightly past the cap.

This gives you a very simple protection against the classic autonomous-agent failure mode: Why has this research assistant been researching for eleven hours?

For recurring tasks, Scheduled Deployments can launch sessions on cron schedules and apply a separate budget to each run.

When one agent becomes a team

Actively gave perhaps the clearest example of why multi-agent systems can make sense.

Watchtower may first filter hundreds of accounts, then write code to query them, then fan deeper work out to independent agents analyzing individual accounts before rolling everything back up.

Managed Agents supports that architecture directly.

A coordinator can delegate to specialized agents running in separate context windows. Anthropic recommends multi-agent setups for parallelization, specialization, and escalation to a more capable model when only part of a task needs it. Each agent can have a different model, toolset, system prompt, MCP connections, and skills.

That model mix becomes important for cost.

Actively said its coordinating agent may need frontier-level intelligence, but running that same expensive model across a fan-out of 500 accounts makes little economic sense. Their product already uses cheaper models for some downstream work. Watch the cost discussion at 31:49

That looks like a likely production pattern for agent systems generally: strong model at the decision bottleneck, cheaper workers for bounded tasks.

Evals come after you've discovered something worth evaluating

One of my favorite parts of the whole conversation was Sahaj's description of early product development:

"Phase zero is vibes-based."

The team first needs to build something people actually want. Once the product becomes sticky, systematic evals become essential because every change can introduce regressions. His sharper version was: "If the thing is not sticky, no amount of evaluation is going to make the thing sticky." Watch at 17:07

Actively ran into the next problem: internal dogfooding produced evals that did not adequately represent real customers.

Their fix was to inspect actual customer queries, talk to the user about what they were trying to accomplish, and build evaluation cases around those real tasks.

This fits what Claude Code's creators told us in our previous deep dive on verification and agent loops: verification becomes increasingly important as agents get enough autonomy to complete longer tasks.

Yet stateful agents create a nasty unresolved problem.

Actively said it still has not found a satisfying way to perform traditional offline evals on a system whose answer depends on live memory. Wispr sees the same issue when MCP-connected services like Slack keep changing underneath the evaluation. A test can fail because the outside world changed rather than because your agent got worse.

That problem remains wide open.

So when should you build your own harness?

The three founders converged on a surprisingly clean rule.

Wispr's Sahaj said the decision comes down to whether the harness itself is part of the product's core competency.

For meeting briefs, the competitive advantage comes from identifying and presenting the right information. Owning sandbox provisioning or compaction offers little differentiation.

For a hypothetical fully voice-controlled Jarvis-style chief of staff, he expects the harness could become central enough to justify building much more of it internally. Watch the build-vs-buy discussion at 12:26

Todd added another criterion: the cost of an experiment is the time it takes to learn.

That explains the early-stage appeal better than almost anything in the product docs.

Pendo already had engineers building its own solution. Managed Agents gave the company working infrastructure in days and let the team spend its next few weeks learning what customers actually needed instead. Wispr got a first version working in a day, then scaled the user base by what Sahaj described as 100 to 1,000X over the following weeks.

Managed infrastructure is therefore most valuable when it buys you learning speed.

The trade-offs are real

Anthropic currently labels Managed Agents as beta. Dreaming and MCP tunnels remain in more limited research preview.

The stateful architecture also comes with a meaningful data consideration. Managed Agents persists conversation history, sandbox state, and outputs server-side, so Anthropic says it is currently ineligible for Zero Data Retention and HIPAA BAA coverage. Sessions and uploaded files can be deleted separately through the API.

Then there is cost.

Wispr estimated that some workloads it runs 24 hours before meetings could potentially become 50%-75% cheaper if batch execution were easier. Actively wants more granular cost and latency controls, including the ability to pre-warm sandboxes.

Those complaints lead directly back to the build-versus-buy test.

A managed harness wins while infrastructure is saving more engineering time than it costs you in flexibility.

Once latency, economics, memory architecture, or execution control becomes the feature, the equation can flip.

The production playbook

If I were starting a Managed Agents project tomorrow, I'd use this sequence:

1. Pick one valuable, long-running task with a measurable deliverable.
2. Build the first agent with the minimum tools and skills it needs.
3. Run it inside a restricted environment with least-privilege permissions.
4. Add an Outcome rubric for anything you would be embarrassed to get wrong.
5. Turn repeated knowledge into memory only after patterns emerge.
6. Keep reference memory read-only whenever possible.
7. Put credentials in vaults rather than hard-coding them into the workflow.
8. Set a session budget before giving the agent room to run autonomously.
9. Build evals from real customer requests once users demonstrate the workflow is valuable.
10. Add subagents only where parallelization or specialization clearly earns the extra cost.

That gets to the central lesson from all three teams.

The agent harness is becoming infrastructure.

A few years ago, getting an AI model to write code, browse websites, use tools, remember context, and work for several minutes felt like the product.

Now those capabilities are becoming the layer underneath the product.

The valuable questions are moving upward: What outcome should this agent pursue? What information deserves to persist? What should it be allowed to change? How do we know its work is good? When should it stay quiet? And what part of this system is actually unique enough that we should own it?

Managed Agents has a strong answer for teams whose current response to the last question is: not the infrastructure.

The harder question comes later.

If production agents really do fan out into hundreds of workers, accumulate years of memory, interact with live company systems, and run continuously, does the managed harness remain the cheaper abstraction, or does scale eventually turn control itself into the product?

The companies in Anthropic's roundtable are still on the managed side of that line.

They're also already watching it closely.