Build a Research Agent with Claude Managed Agents (Part 2 of 4) — Anthropic
A hands-on walkthrough of Claude Managed Agents, building a research desk for SEC filing analysis with a chat UI on the session event stream, skills, subagents, custom tools, shared memory, rubric-graded outcomes and vault-based credential injection.
Session storage and the console quick start
The session design changed mainly in the direction of abstraction. Storage mechanics were split into separate components so new event types can be stored without tight coupling to session logic. The same interface virtualization principle now applies across service boundaries and down to the event layer.
The console quick start shows how little is needed to get a running agent. Describing a goal, such as an agent that tells jokes about a given topic, produces a generated name, description, system prompt and model choice, all of which can be changed before the agent is created through the v1 agents endpoint. An environment defines the sandbox template: its network access, which was unrestricted for this demo, and any preinstalled packages. Starting a session and sending a message returns streamed events from an agent running entirely in the cloud. The platform manages hosting, the harness, sandbox lifecycle, scaling and storage of the event log, leaving developers to build their product on top.
Building a chat interface on the event stream
Everything in a chat-style application flows through the session event stream. The frontend’s message submission becomes a user message event posted to the session, while the backend relays the server-sent event stream from the agent back to the browser for rendering. Stopping at this point yields a working chat app, but the real value of managed agents lies in long-running asynchronous work that can run for hours, days or months.
Skills, subagents and custom tools
The research desk is built with a workshop skill in Claude Code that guides participants through six acts. Setup requires an API key and the EDGAR identity (name and email) that the SEC requires on API calls. The agent is then upgraded with an SEC EDGAR skill that documents the Python package to use and the identity to send, a custom tool called dispatch_analysis for spinning up parallel sessions, and subagents with their own prompts, tools, permissions and models. A self-reference lets the main agent spawn copies of itself when the task structure is not known in advance. Subagents do not inherit the parent’s transcript. They receive only the prompt, tool descriptions and schemas. A shared memory store, readable and writable across sessions, completes the setup, and a ‘staff the desk’ button provisions all of these resources.
Outcomes and self-supervision
An outcome is a user-defined event containing a task description, a rubric and a maximum iteration count. When the agent believes its work is complete, a grader subagent checks the output against the rubric and either accepts it or sends the agent back to try again. Outcomes are defined at the session level. There is currently no support for sub-outcomes assigned to individual subagents.
Nvidia analysis walkthrough
The demo outcome asked the agent to analyze Nvidia’s most recent SEC quarterly filing using the EDGAR identity, check memory for earlier analysis to avoid redundant research, and produce two deliverables: a note in memory and a structured JSON scorecard saved to a file. The agent found no existing notes and delegated the bulk of the work to an extractor subagent and a risk evaluator subagent. The console shows each subagent as a thread, which gives full observability into the run. After the main agent consolidated the results, wrote the scorecard and updated memory, the grader verified that the outcome had been met. Scorecards can be extracted from sessions and downloaded, and in this demo results were stored in a local database. A full run takes roughly ten minutes.
Live skills and dreaming
Skills are live artifacts. Updating one, for example to add support for a new SEC form, applies to any new session that references it. Dreaming analyzes transcripts and memories across sessions to consolidate and refine memory stores, so future agents draw on shared knowledge and learn from each other’s edge cases. Dreaming is currently limited to memory stores, but it could be extended to skills, prompts and agent definitions for continuous learning.
Vaults and credential handling
In production, secrets should not be placed directly in the environment. A vault holds the credentials, and the agent sees only placeholder values. At egress, the platform swaps a placeholder for the real value only when the request targets a host the secret is scoped to. A secret scoped to sec.gov, for instance, would never be substituted into a request bound for another domain. Vaults can bundle OAuth and MCP credentials, and they are attached to a session by ID.
Managed agents and the Agent SDK
The Agent SDK packages Claude Code as a headless binary that can run wherever the developer chooses. Managed agents use a separately rebuilt harness that draws heavily on the lessons of Claude Code and the Agent SDK but is generalized beyond coding and fully hosted. The two teams stay in close contact about enhancements.
Guardrails, steering and forking
Preventing agent loops and runaway token consumption is largely left to the developer’s orchestration logic, and multi-provider setups are possible. Per-session budget controls for money and tokens are being explored but are not offered today. Steering works by sending new user messages, which queue up behind the agent’s current work. Rewinding and rolling forward is not yet available, though session forking is on the roadmap in response to customer requests.
Memory sharing and portability
Memory stores persist across sessions, and several can be attached to a single session, such as a user-level store alongside an organization-wide one. Everything is exposed through the API, so memories can be exported to other systems. Other memory providers are not supported out of the box and would be integrated through an MCP server or a custom tool.
Private data, hosting and sandboxes
Most managed agents run on Anthropic’s own infrastructure, with a Claude Platform on AWS option for teams that want to use AWS credits. Internal data can be exposed to agents through a custom CLI or an MCP server, authenticated via a vault. If that endpoint should not be internet-facing, MCP tunnels connect the private network to the platform. The alternative is self-hosted sandboxes peered with the corporate network, which can run on providers such as Browserbase, Modal, Daytona, AWS or Google Cloud.
Environment dependencies
Packages are specified when an environment is created and cached for reuse across sandbox instantiations. They must currently be installable from public registries such as npm, cargo or pip. Files and GitHub repositories can be uploaded into a session to bring in private code.
The demo then moves on to deployments, an API for scheduling recurring sessions so that longer-term analysis keeps updating itself, which is not covered in this part.