Claude Managed Agents on AWS move the question from prompt to operations

Claude Code 2.1.159 looks, according to the public changelog, mostly like internal infrastructure work. So today's more useful Claude signal is not another new button in the developer tool. It sits in Anthropic's platform notes: Claude Managed Agents features such as webhooks, multiagent orchestration, and self-hosted sandboxes are now available on Claude Platform on AWS.

That sounds like cloud architecture. For Hammer readers, the point is simpler: agent work is becoming something you operate, inspect, and constrain, not something you just launch in a chat window and hope for.

Source: Claude Platform release notes

What Anthropic actually moved to AWS

In the May 29 release notes, Anthropic says webhooks, multiagent orchestration, and self-hosted sandboxes for Claude Managed Agents are now available on Claude Platform on AWS. A webhook is a technical callback to another system when something happens, for example when an agent run is complete. A self-hosted sandbox is a controlled execution environment in your own infrastructure where the agent can work without getting broad access to everything.

Anthropic's overview describes Claude Managed Agents as a pre-built, configurable agent harness for long-running and asynchronous work. It can read files, run commands, use MCP servers, preserve state across sessions, and run either in an Anthropic-managed environment or in your own sandbox. Managed Agents calls still require the managed-agents-2026-04-01 beta header, so this is a current signal to plan around, not a reason to throw agents into production overnight.

Source: Claude Managed Agents overview

Agent operations need a receipt, sandbox, and stop button

This is the part that often gets missed in AI conversations. Many teams are still talking about better prompts. Anthropic is moving in a different direction: the agent gets an execution environment, a task, tools, events, memory, and sometimes several subagents. At that point it is not enough to ask whether the answer looks good. You need to know where the agent ran, which sources it touched, which tools it used, and when a human should stop or approve the next step.

For a small Nordic team, this can stay very practical. Do not start with the most sensitive workflow. Pick a recurring task with a visible output: a weekly digest from internal documents, a review of open support tickets, or a first draft of documentation updates. Then connect the agent to limited data, keep secrets in environment variables or a secret manager, use scoped API keys, and let the webhook only report status or create a review card.

That is Tool Forge in practice: not a bigger prompt, but a routine where the agent gets the right tools, works in a bounded environment, and leaves a receipt that people can actually review.

A small team can start like this

Make the human decisions first:

• Pick one task that can fail without harming customers, money, or operations.
• Write down what a finished result looks like.
• Decide whether the agent should run in a managed cloud sandbox or your own sandbox.
• List which files, systems, and MCP servers the agent may use.
• Decide what the webhook may send downstream: status, run link, owner, and next review step.
• Write a simple stop rule: when should the agent pause and ask a human?

Only after that is it worth asking Claude to help design the pilot.

Try this prompt this week

Read our runbook, integration notes, and the source folders related to [workflow].
Propose a small Claude Managed Agents pilot for this workflow.
List the sandbox choice, allowed tools/MCP servers, secrets that must stay in env or a secret manager, webhook event, and human approval point.
Do not implement. First give me a one-page run receipt and stop-rule template.

If that template feels unclear, good. The next step is not more automation. The next step is making the workflow clear enough for a human to approve.