Managed agents
Define the agent. Do not operate it.
A managed agent is one whose execution someone else runs. You define the objective, the inputs it can read and the tools it can reach. Coresource runs it on a durable, auditable agent runtime that recovers when a step fails and records what happened, so there is no orchestration layer for you to deploy or keep alive.
The problem
Long runs fail on arithmetic, not intelligence
At 95% per-step reliability, a 20-step run succeeds barely a third of the time.
Nothing about that is a model-quality problem. It is multiplication. Framework loops silently lose state, leaving you with opaque failures you cannot explain in an incident review, and no way to resume from the point where it broke.
That is the argument for putting recovery in the runtime rather than writing it into every agent. One failed step should cost one slice of work, not the run.
The approach
Four decisions that change what agents can do
Recover surgically, not from zero.
DurabilityWhen a step fails, Coresource re-derives only the invalidated slice, and the rest of the run holds its state. No restart, no lost context, no silent corruption.
Prove exactly what happened, and why.
AuditabilityEvery value records what generated it and what invalidated it, and a decision that cites no evidence is rejected rather than stored. Replay any run deterministically and trace any decision to its source.
Hold context across hours of work.
CoherenceAgents persist through hundreds of steps with a single authoritative world-model. Intent, state and reasoning stay coherent from the first step to the last.
Frontier-grade results without frontier budgets.
EconomicsSmall and open models perform at the level of the largest proprietary systems, at a fraction of the cost. These are the economics that make agents viable at scale.
Managed for you
State, retries, replay and credentials
Somewhere to keep state, a way to retry, a way to replay a run a customer is asking about, and credential handling for every tool the agent can reach.
Coresource manages execution, credentials, storage and streaming, so what is left in your application is the definition and the prompt.
The definition is the unit of work rather than the integration. The same agent answers from your product, a task board, or a backend job, because what you deployed was a description of the objective and not a script tied to one surface.
Three ways the same definition runs
One-shot
A single model response with a limited tool surface: hosted web search is available, but no runtime, files or MCP servers.
Agent
An iterative loop with tools, skills, files or MCP servers. It keeps calling what it has been given until the objective is met.
Saga
Plans first, then executes durable multi-step work. Built for long-horizon runs where the plan itself has to survive a failure.
Agent workflows
Decomposed, not just handed over
The question that matters is not how many steps a system can chain together. It is what happens at step 17.
An agent workflow is a long-horizon objective decomposed into milestones, steps and execution waves, run with durable state so a failure costs one slice of work instead of the whole run. The decomposition is a first-class artifact the runtime maintains and revises, not a prompt written once.
Plan
The objective is decomposed into milestones, steps and execution waves before the agent acts, so the model never faces the whole problem at once.
Execute
The work is done durably, so a long run survives interruptions, failures and retries instead of collapsing.
Re-plan
When reality diverges from the plan, the run steers itself. It revises the plan mid-flight rather than waiting for a human to notice.
Verify
It checks its own work against the objective and keeps going until the objective is actually met.
The model faces the next step with exactly the context that step needs: the relevant slice of the plan, the relevant evidence, the relevant state. A focused slice of a coherent plan is a task a small model handles well. An unbounded scroll of prompt history is not.
Evidence
What long-horizon actually looks like
One run, pointed at a single hard objective and left alone.
It processed roughly 1.5 billion tokens across about 50 hours, managing 8 milestones, 36 steps and 8 execution waves. It made 47 step attempts and 201 revision-ledger entries, re-planning every time it learned something new. It shipped around 50,000 lines across 113 commits and 120 files.
One honest caveat, the same one published with the run: about 1.37 billion of those tokens were cache reads. Roughly 4.3 million were newly generated.
Common questions
What is an agent runtime?
An agent runtime is the execution layer an agent runs on: it owns the agent's state, its recovery when a step fails, and the record of what happened. A framework arranges calls to a model; a runtime is responsible for the run still being correct an hour later.
What makes an agent runtime durable?
Durability means a failed step does not cost the run. Coresource re-derives only the slice a failure invalidated and the rest of the run holds its state, no restart from zero, no lost context, no silently corrupted state.
What are managed agents, and what is a managed agent runtime?
Managed agents are agents whose execution someone else operates: you define the objective, the inputs it can read and the tools it can reach. The managed agent runtime is what runs them. Coresource handles execution, credentials, storage and streaming, recovers the run when a step fails, and records what happened, so there is no orchestration layer for you to deploy or keep alive.
What is the difference between an agent and a saga?
Coresource has three agent types. A one-shot is a single model response with a limited tool surface: hosted web search is available, but no runtime, files or MCP servers. An agent is an iterative tool loop. A saga plans first and then executes durable multi-step work, which is the type built for long-horizon runs.
What is an agent workflow?
An agent workflow is a long-horizon objective broken into milestones, steps and execution waves, executed with durable state so the run survives failures. It is the unit of work above a single agent call.
What happens when a step in an agent workflow fails?
Coresource re-derives only the invalidated slice. The steps whose inputs are unaffected keep their state, so a failure costs one slice of work rather than the whole run.
Why does per-step reliability matter so much?
Because it compounds. At 95% per-step reliability a twenty-step run succeeds barely a third of the time. Long-horizon work fails on arithmetic, not on model quality, which is why recovery belongs in the runtime rather than in each agent.