How to manage AI agents that run without you

Prompting an agent and managing one look like the same job until a run finishes while nobody is watching and the output is wrong in a way nobody can trace.

This post covers what changes when an agent runs unattended, the four surfaces you control when you manage one, and how to wire the OpenRush Model Context Protocol (MCP) server into that setup so the agent reasons over data it can defend.

Managing an agent is not prompting an agent

Prompting is a single turn you supervise. You read the answer, you redirect when it is wrong, and the context window holds everything that matters because you are standing there to catch what it drops.

Managing is what you do once that stops being true. A managed agent runs for hours, calls tools you approved in advance, and stops against a condition you defined rather than a response you liked. You are not in the loop on every step, which means the parts you used to handle by reacting now have to be decided in advance.

Anthropic's engineering team laid out the cleanest available frame for this in Scaling Managed Agents, published in April 2026. They split an agent system into three pieces: the brain, the hands, and the session. The brain is the model plus its harness, meaning the orchestration code that decides when to call what. The hands are the sandbox and the tools that execute. The session is a durable append-only log of every event, living outside the model's context window, and each of the three can fail or be swapped without the others noticing.

The argument for decoupling is that harnesses go stale. A harness encodes workarounds for whatever the current model is bad at, and the next model is not bad at it. Anthropic's own example: the context anxiety workarounds built for Claude Sonnet 4.5, where the model wrapped up prematurely as it approached its context limit, became dead weight in Claude Opus 4.5.

We think that frame is right and incomplete. Decoupling the brain from the hands says nothing about what the hands reach for. An agent with a clean harness, an isolated sandbox, and a resumable session will still produce a confident wrong answer if the data coming back does not say where it came from, when it was observed, or how much of the answer it actually contains.

We learned that in the least efficient order. Our first unattended runs had careful scoping and a clean session log, and they still produced confident nonsense, because the data underneath was untyped JSON with no way to tell a fresh observation from a cached guess.

The four surfaces you actually manage

Everything you decide before a run starts falls into four categories, and a better model will not rescue you from getting them wrong.

Scope: the decisions you delegate

Scope is the set of decisions the agent makes alone and the set it escalates. Write down both. An agent told to "improve our search rankings" has no scope. An agent told to "find the five pages that lost the most organic traffic this month and draft a fix for each, publishing nothing" has one.

The part teams skip is the done condition. Unattended runs need an explicit finish line, because a model with an open-ended goal and a tool budget will keep going. Define that finish line as an artifact, so the agent has something to hand back rather than a topic to keep working on.

Tools: what the hands can reach

Treat the tool surface as something you design rather than something you accumulate. Every tool you expose is another branch the model evaluates at inference time, and a wrong pick costs a round trip plus the tokens to recover from it.

We built OpenRush with 11 tools across four domains instead of a wrapper per upstream endpoint. The reasoning is arithmetic: a model choosing among 11 job-shaped tools has fewer ways to go wrong than one facing 60 endpoint-shaped ones.

Name tools for the question they answer. discover_competitors is a job, GET /v3/domain_intersection/live is an endpoint, and a model forced to assemble the first out of the second burns tokens you wanted for reasoning.

Session: state that outlives the context window

The session and the context window are different objects, and conflating them is where most long-running agents break. The context window is what the model sees this turn. The session is the full record of what happened, stored outside the model and queried when needed.

Separating them turns compaction from a lossy decision made under pressure into a cheap one. The agent can drop detail from context knowing the log still holds it, and a crashed run restarts from the log instead of from the beginning. You also get the audit trail, which matters more than it sounds: when an unattended run produces a bad recommendation, the question is always which fact it acted on.

Verification: how you know a run was right

An unattended run has to produce something checkable. A summary of the run is not enough, because the model will write a convincing one regardless of what actually happened. You want an artifact you can test: a diff, a file, or a set of claims with sources attached.

The cheapest version of this is requiring citations. If every number in the output traces back to a tool call with a timestamp, verification is a spot check. If the output is prose, you are grading vibes.

Runs are cattle, not pets

Anthropic borrows the pets-versus-cattle distinction from infrastructure, and it transfers well. A pet agent is one you tuned by hand, whose prompt has accumulated patches for specific past failures, and which you debug by watching it work. A cattle agent is one of fifty identical runs, any of which you can kill and restart without losing anything.

The test is what happens when a run fails. If the answer is that you open the session and nurse it back to health, you have a pet. If the answer is that you restart it and it picks up from the log, you have something you can run a hundred of.

Getting there is mostly about removing hand-tuning. Prompt patches that fix one client's edge case, hardcoded ids, tool descriptions written for a model version you no longer run: that is harness staleness arriving through the side door.

The failure mode nobody sandboxes for

Sandboxes contain what an agent does. Nothing in that stack checks what an agent believes.

A recommendation is only as sound as the facts behind it, and marketing data is unusually bad at telling you how sound a fact is. A rank pulled from a search index this morning and a rank observed in a live search result thirty seconds ago are both "position 3." A raw API dump flattens that difference, so the model weighs an estimate and an observation the same and the recommendation inherits an error nobody flagged.

Truncation is the same problem in a different form. A tool returns 25 rows out of 412 and says nothing about the other 387, so the agent reads a sample and reports it as a conclusion. Under supervision a human notices; unattended, it becomes next quarter's plan.

Using OpenRush MCP with your agents

MCP is the open standard Anthropic published in November 2024 that lets any agent client call tools on any server through one interface. OpenRush uses it to serve live search results, competitor rankings, keyword demand, backlink data, and site audits in a single typed envelope.

Connect it once

OpenRush is listed in the Claude connector directory, so adding it to Claude takes one click and an OAuth sign-in. There is no config file and no token to paste.

For Claude Code, register the server from your project directory:

claude mcp add --transport http openrush https://api.openrush.com/mcp

For Cursor, add the entry to ~/.cursor/mcp.json and reload:

{
  "mcpServers": {
    "openrush": {
      "url": "https://api.openrush.com/mcp"
    }
  }
}

ChatGPT, Codex, and Perplexity take the same server URL as a custom remote connector. The MCP setup page has the steps for each client.

Start every agent at describe_capabilities

describe_capabilities is the discovery call, and it belongs in the system prompt of any agent you plan to leave alone. One call returns:

• Which domains are enabled and which tools are live
• What fact types each tool emits and which sources back them
• Which tools need a connection to your own data
• What each call costs in credits

An agent that starts there stops guessing about its own surface. It also stops calling tools that need a Search Console connection the account does not have, which is the most common wasted call we see.

Make the agent read provenance before it acts

Every tool returns the same envelope, versioned ofe/1.0, and every claim inside it carries its own provenance block:

{
  "type": "seo.keyword_ranking",
  "subject": { "domain": "competitor.com", "keyword": "mcp server hosting" },
  "value": { "position": 3, "url": "https://competitor.com/hosting" },
  "provenance": {
    "source_class": "live_serp",
    "method": "serp_fetch",
    "confidence": 0.94,
    "observed_at": "2026-07-24T14:02:11Z",
    "cache_hit": false
  }
}

Trust attaches to the fact rather than to the tool, because one response often mixes a live observation with an indexed estimate. Put the rule in the agent's instructions: state source_class and observed_at for any number that drives a recommendation, and escalate rather than act when a fact is older than the task allows.

The subject field pins each fact to stable entity ids, so an agent can join a claim from inspect_domain to one from inspect_serp without matching on strings.

Make it read coverage before it concludes

Every envelope carries a coverage block stating what the result does and does not include: rows returned against rows available, whether the response was truncated, and the scope of the observation.

An agent reading returned: 25, total_available: 412 knows it holds a sample and can call export_dataset for the rest. Instruct it to check coverage before writing a conclusion, and a truncated list stops reading as a complete one.

Budget credits like tokens

Tool calls cost credits, and an agent planning a week of work should reason about that budget the way it reasons about context. inspect_serp costs 2 credits and compare_keyword_coverage costs 12, and describe_capabilities reports per-tool cost so the agent plans against real numbers instead of a guess.

In our benchmarks, agents running on OpenRush answer 40% faster and spend 25% fewer tokens than the same agents pointed at the raw upstream API, because the model spends its budget deciding instead of parsing.

A managed run, end to end

A weekly visibility check, with all four surfaces set. Scope is read only, with no writes. The done condition is a ranked list of pages that lost visibility, each with a cited cause and a proposed fix. The tool chain:

1. inspect_search_visibility on your domain, compared against last week's stored result. The deltas block does the comparison.
2. discover_competitors to refresh the competitor set, because last quarter's list is a stale assumption.
3. compare_keyword_coverage against the two competitors that gained the most, to find demand you stopped covering.
4. inspect_serp on the ten keywords with the largest drop, to confirm against a live result rather than an index estimate.
5. audit_site on the pages behind those keywords, to separate a ranking problem from a broken page.

The agent writes each step's facts to the session as it goes, so the final report cites observed_at per claim and a human approves the fixes before anything ships. The run restarts at any step, and next week's run is the same code with nothing hand-tuned.

What is still hard

Three problems are open, for us as much as for anyone else building here.

The one that bothers us most is evaluating a run nobody watched. Citations make spot-checking possible, and they say nothing about the judgment an agent exercised between reading the facts and writing the recommendation. Teams end up sampling runs, which catches systematic errors and misses one-off ones, and we do not have a better answer than that yet.

Approval is too coarse. Reading data is the safe half of the job; the valuable half is publishing a page, adjusting a bid, or pausing a campaign, and MCP's human-in-the-loop hooks treat a session-level grant as the unit. That puts "read a rank" and "spend money" in the same permission.

Cost-aware planning barely exists. Exposing per-tool cost was the first step, and the agents that would use it, planning a multi-day task against a credit budget and paying for a live observation only where a cheap estimate would change the answer, are still mostly hypothetical.

Start with one run

Take one recurring marketing task you do by hand, write down its scope and its done condition, give it the smallest tool set that can finish the job, and run it unattended once. The first run tells you which of the four surfaces you left undefined.

Connect an agent to get the server running, read MCP, AI tooling, and the marketing data layer for why the envelope looks the way it does, or browse the use cases for what people run on it today.