Managed agent examples: compare packages before you install

Managed agent examples are useful when each example tells you what it does, what it can access and what its evidence actually proves. A title such as "weekly researcher" is not enough to choose a package. Anthropic's baseline explains an agent, an environment, a session and the events exchanged while a task runs. Managed Agents adds the package record around those concepts, so you can compare an outcome and its resource contract before applying it.

The practical rule is simple: compare examples by the work they return and the access they require, not by a made-up overall score. Browse the catalog for current listings, then use the marketplace guide if you are unsure whether you need Anthropic's partner Marketplace or a downloadable native package.

What does a Managed Agent package contain?

A Managed Agent package contains a versioned set of native resource files, supporting instructions and a catalog record that describes the intended outcome, requirements and evidence. It is an agent offering, not a reusable prompt pasted into a chat.

Anthropic's own model starts with the agent and environment. The agent defines the model, system prompt, tools, MCP servers and skills. The environment defines where sessions run. A session is the running instance that performs a task, and events carry user turns, tool results and status updates. A package can express those pieces as files that ant apply reads, along with optional memory, deployment and vault resources.

The catalog contract also records network policy, MCP connections, CLI packages, permissions, expected outputs, cost notes, safety notes and a verification level. That list is the useful difference between an example page and a prompt gallery. It gives you questions to answer before you give a package access to a network, a memory store or a connected service.

The local fixture preview is development data, not a promise that every record has a public artifact or live evidence. The catalog contract says fixture mode is credential-free, and a missing artifact or hash blocks the deployable level. Treat the live listing as the current record and the fixture as a way to understand the fields. The visible categories and cards are discovery aids, not a quality ranking.

Which examples fit SEO, content, research or productivity work?

Match an example to the outcome you need, then compare its access and evidence with the inputs you can provide. The catalog data groups examples by work rather than presenting one winner for every reader.

These are examples of different package shapes, not claims that one category is more valuable. The checked-in seed records the expected output and runtime details for each one. A listing can change, so open the item page before relying on a name from a search result. The catalog's own first-hand value is that it shows the contract beside the outcome.

For SEO work, ask whether the package can browse the web, whether shell access is needed, and whether it keeps dated memory. For content work, ask which source material the output can use and whether the package ever posts or only drafts. For research, inspect source and date requirements. For productivity, check whether the package needs network access at all. Plan My Week, for example, is shown as an on-demand productivity listing with no web access, a run-once command and a memory attachment note. That is a different fit from a weekly change tracker that needs open web access and a scheduled deployment.

When an example has a connected service, read the permissions before you treat the output as automatic. A package that drafts a reply is not the same as one that sends a reply. A package that reads a memory store is not the same as one that has the store attached to an interactive session. The package README, listing metadata and testing evidence should agree on those boundaries.

How do I compare schedule, memory, tools and permissions?

Compare schedule and access before you compare model names. Those fields change what the package can do, when it can run and what you need to review.

The schedule warning deserves its own pause. The detail page presents a "Run it once" command for a scheduled package and a separate ant apply . command that turns on the schedule. The package contract says the reviewer must inspect or remove the deployment when the goal is one-off use. That is a small command difference with a large operational consequence.

Memory has a similar trap. A package may define memory_stores/history.yaml, but an interactive session needs an explicit resource attachment. A deployment-created session receives the attachments declared by the deployment. Ask where the memory is mounted and what the instructions say it stores. A declared memory file alone is not proof that the next run can read it.

Verification is the third trap. The repository's validation report records package shape and reference checks, then says those checks did not import, execute, apply or schedule the package. The catalog's ladder keeps those steps separate. If the evidence stops at a static check or a dry run, write down that limit before you call an example ready.

How can I try an example without turning on a recurring schedule?

To try an example safely, choose an on-demand listing or use its run-once path, inspect the dry-run plan, and leave any deployment resource out until you mean to create recurring sessions.

1. Open the listing. Read the outcome, expected output, inputs, example report and "What it won't do" notes. Check whether the listing is tested live or says that evidence is not available yet.
2. Read the package identity. Confirm the version, license, source or provenance, artifact URL and SHA-256. If the artifact is unavailable, keep reviewing the record and do not substitute a random archive.
3. Download and inspect locally. Read README.md, resource paths, environment settings, skills, memory policy and deployment files. Keep secrets and personal lockfiles out of the package.
4. Preview the plan. Run ant apply --dry-run . in the package folder. Read the plan text for This plan cannot be applied, not only the exit code. A dry run should not create resources.
5. Apply only the one-off resources. Use the listing's "Run it once" command for the agent, environment, skills and memory store it names. Leave deployments/ out when you are testing interactively.
6. Attach and smoke-test. In Claude Console, attach the memory store if the package needs it, send the documented inputs, and compare the result with the expected output. Record what you actually tested.

The catalog makes this review visible in one place. The Plan My Week detail page shows the example-output box, a run-once ant apply command, requirements, access limits, configuration and a testing section. The screenshot below is a real capture of that page. It also shows why a package's absence of web access can be a useful fit for planning, rather than a missing feature.

Open Managed Agents search, choose an example by the outcome you need, and inspect its evidence before you download it. If you are still deciding whether you want a partner product or a native package, read the official-marketplace distinction first. The catalog is your next step for package comparison; your own workspace remains the place where ant apply, sessions and any recurring schedule actually run.