How to Use Claude Managed Agents: Setup and Work Context

Claude managed agents are agents where the surrounding infrastructure, session lifecycle and tool routing are handled by a platform rather than custom code you write yourself. You configure what the agent can do, supply the context it needs and define the verification steps; the platform manages how sessions start, how tools are called and how results are returned. Tools like fenbs retain the shared task brief and the work history that should follow the agent from session to session.

The practical advantage is that you spend less time building scaffolding and more time defining the task. The tradeoff is that you are working within the platform's constraints: the tools it exposes, the session model it uses and the limits it enforces. Understanding those constraints before you start prevents surprises midway through a long task.

How managed agents differ from direct API calls

A direct Claude API call is stateless: you send a message, you receive a response, and the next call knows nothing about the previous one unless you send the history again. A managed agent session maintains state across steps, calls tools on your behalf according to rules you define, and handles the back-and-forth between Claude and those tools automatically.

This makes managed agents useful for tasks with multiple steps, tool calls and decision points. It also means the session has a lifecycle: it starts, it runs through the task, it either completes or stops for review, and it ends. Understanding that lifecycle helps you set up monitoring and recovery correctly.

For a lower-level view of the agent SDK, see the Claude Agent SDK guide, which covers the building blocks you use when constructing agents from scratch.

Setting up a managed agent

Before starting a managed agent session, define three things: what the agent is allowed to do, what it knows at the start, and what a completed run looks like.

For what the agent is allowed to do, list the tools it may call and the scope it may act within. For each tool, decide whether calls should proceed automatically or wait for your confirmation. The narrower the scope, the safer the run and the easier the debugging.

For what it knows at the start, prepare a context document: the project goal, the active task, the constraints and any Decisions and rules that apply. Supply this at the start of each session. A managed agent that starts without context will make assumptions that may contradict decisions you made in a previous run.

For what completion looks like, write acceptance criteria before the session begins. You need a specific test, a checkable output or a state change that you can verify independently of Claude's own report.

Verifying tool access before a long run

Tool access errors that appear halfway through a long agent run are expensive to recover from. Verify that each tool the agent needs is available and responding before you start a task that depends on it. A short diagnostic run that lists available tools and calls each one with a test payload is faster than tracing a failure mid-task.

Also check that the tool access you configured matches what the task actually requires. A common mistake is granting read access to a resource the task needs to write, or vice versa. Catch that at setup, not when the agent is three steps into a six-step task.

Managing the session lifecycle

A managed agent session has a beginning, a middle and an end. At the beginning, supply the context and the task. In the middle, monitor progress at checkpoints rather than watching every tool call: if the agent is working on step two of a six-step plan, check again after step two completes rather than hovering throughout.

At session end, verify the result against your acceptance criteria. Do not treat the agent's summary as verification. Run the test, check the output, review the diff. A summary that says "completed successfully" is a starting point for your verification, not a substitute for it.

If a session ends unexpectedly, record the state before it stopped. Where did it reach? What did it complete? What was it working on? That note is the starting point for the recovery session.

Keeping work history across sessions

One of the practical difficulties with managed agents is that work history does not automatically follow the agent between sessions. A session that completed step three of a six-step task has no automatic way to tell the next session where it stopped. You need to record that handoff explicitly.

A work history entry should say what was completed, what was verified, what was not, and where the next session should start. It is not a full transcript of the session; it is the information a new session needs to continue without re-doing work that is already done.

The Claude Code memory guide covers how memory and project context persist in Claude Code sessions. For broader agent work, an external record is more reliable than an in-session state.

Reviewing the work history in fenbs

fenbs keeps a History of every change made by a person or an assistant. For managed agent work, that history shows what the agent changed, when, and in which session. If a result does not look right, the history is the starting point for understanding what happened.

Combine the task's progress notes with History to reconstruct the session. The progress notes tell you what the agent reported completing; History tells you what it actually changed. If those two accounts diverge, the divergence is the finding to investigate.

What to watch for during a long agent run

Long agent runs tend to drift. A task that starts with a clear plan can accumulate small deviations that compound into a result significantly different from what you described. Watching for drift does not mean watching every tool call; it means reviewing the output at each checkpoint and comparing it to the plan rather than to the previous step.

Two patterns indicate a run is heading off track. The first is when the agent starts performing actions that are adjacent to the task but were not part of the plan: refactoring a file it was supposed to leave alone, making a change "while it was there." Catch those at the next checkpoint and correct the scope.

The second is when the agent reports completing steps that do not match what your acceptance criteria require. A summary that says "configured the endpoint" when your criterion was "returns a 200 with the expected schema" is a gap worth investigating. Verify against the criterion, not the summary. Record any confirmed gaps as tasks so the next session addresses them.

Recovering from a failed or interrupted session

When a managed agent session fails or is interrupted, the first step is to record the state before doing anything else. What did the session complete? What was it working on when it stopped? What remains? That note prevents you from either repeating completed work or skipping uncompleted work in the recovery session.

Investigate the cause before restarting. If the session stopped because a tool was unavailable, fix the tool access before the next run. If it stopped because the task scope was too broad, narrow it. A recovery session that hits the same obstacle as the failed session is not a recovery; it is a replay.

Start the recovery session with the state note. Give the new session the task context, the progress record and an explicit statement of where to start. The session should begin from a confirmed checkpoint, not from the beginning of the task.

How to do this with fenbs

1. Create a free account and add the project. Write the project rules, the task constraints and any decisions made in previous sessions as Decisions and rules. These are the first thing a connected assistant reads.
2. Add a task for each managed agent run. Write the task plan with the steps, acceptance criteria and file scope before the session begins.
3. Connect Claude or your agent client over MCP from Integrations. At the start of each session, ask the agent to read the project context and confirm the task it is about to work on.
4. After each session, update the task: what was completed, what was verified, what remains, and the starting point for the next session. Set Waiting on you if the task needs a person's decision before continuing.
5. Review the History in fenbs after each run to confirm the changes match what was planned. Record any discrepancy as a task or a Lessons learned entry.

For related patterns on how to share agent definitions with teammates, see the guide on how to share Claude agents.