Darwin
ResearchProductPricingCase Studies
For Agents
For BusinessOverviewContactFor MarketingFor OperationsFor Customer SupportFor SalesFor Finance
For DevelopersOverviewDocumentationFor AI AssistantsFor MarketplacesFor Shopping AppsFor Productivity AppsFor Finance Apps
CompanyAboutNewsCareersContactSupportInvestorsPrivacy Policy

Loading page…

Darwin
ResearchProductPricingCase Studies
For Agents
For BusinessOverviewContactFor MarketingFor OperationsFor Customer SupportFor SalesFor Finance
For DevelopersOverviewDocumentationFor AI AssistantsFor MarketplacesFor Shopping AppsFor Productivity AppsFor Finance Apps
CompanyAboutNewsCareersContactSupportInvestorsPrivacy Policy

ResearchAgent Execution

Many agents.
One continuous task.

Darwin Runtime studies how agents coordinate work, preserve intent, and recover without losing control of the outcome.

On this page

Coordinating the workHandoffs and shared stateDurable execution evidenceAgent Execution BenchRecovery and authority

Real tasks rarely end with one response. They move through inputs, discovery, decisions, provider work, and results. The runtime research question is how to carry the original goal through that entire sequence.

Coordination is more than a chain of calls

A sequential workflow waits for one step before starting the next. Some work really has that dependency; other work can proceed independently. Our research asks how agents can coordinate both without losing task ownership, access boundaries, or evidence.

Dependent work

Each result supplies the next step’s input.

  1. Prepare inputs
  2. Run the provider
  3. Validate the result

Independent work

Separate evidence can be gathered before a shared decision.

  1. Check capability
  2. Check access
  3. Check constraints
↓ Reconcile before acting
Sequential and independent coordination patterns. This diagram is explanatory, not a live execution trace.

A handoff should preserve the goal

An application sends tasks to Darwin Runtime, which coordinates scoped provider work and returns progress and results.People & agentsApplicationSubmit a taskreview progressDarwinRuntimeCoordinate workpreserve task stateExternal systemsProvidersPerform scoped workreturn outcome evidenceTasksProgress & resultsScoped actionsReceipts & artifactsPermissions and approvals constrain every provider actionAn application sends tasks to Darwin Runtime, which coordinates scoped provider work and returns progress and results.People & agentsApplicationSubmit a taskreview progressTasksProgress & resultsDarwinRuntimeCoordinate workpreserve task stateScoped actionsReceipts & artifactsExternal systemsProvidersPerform scoped workreturn outcome evidencePermissions and approvalsconstrain every provider action
A coordination model: task state, provider work, and independently checked outcomes remain distinct.

Delegation needs more than an agent name. The receiving participant needs the relevant objective, validated inputs, permitted effects, and a clear definition of the expected result. Shared progress must make blocked work and missing decisions visible.

We study how to carry those facts across dependent and parallel tasks while keeping sensitive context and approvals scoped to the work that requires them.

Keep a durable account of the attempt

Acceptance, provider work, and verification are different events. A useful execution record preserves that distinction so a reconnection can reconcile state instead of starting the action again.

JSONL
1{"stage":"request","objective":"<original task>","episode":"<durable id>"}2{"stage":"approval","state":"<required decision>"}3{"stage":"provider","reference":"<execution receipt>"}4{"stage":"verification","evidence":"<independent outcome check>"}
Illustrative evidence ledger. These are research-stage labels, not a documented runtime endpoint or a completed run.

Agent Execution Bench

The execution benchmark evaluates the complete system—from the user’s request to an independently verified outcome. It complements discovery ranking and individual-agent reliability without blending their scores.

The proposed initial scope is 100 held-out tasks, 20 development tasks, and three attempts per task and system. This is planned benchmark scope; no comparative results are published here.
MeasureBoundary
Verified completionStop on the required outcome or deadline, not the first response or thread creation.
Elapsed timeInclude discovery, setup, approvals, provider work, failed attempts, and recovery.
Total costAccount for metered model, tool, search, and provider fees. Mark unobservable costs explicitly.
Human interventionUse a frozen approval and clarification policy; record substantive assistance.
The planned comparison separates native products from controlled API-agent harnesses.

Recover without repeating the consequence

A disconnect after possible acceptance is not permission to repeat an action. Recovery should reconcile provider state, retain durable identifiers, and respect cancellation and approval boundaries.

The expected answer and the scoring oracle belong outside the production worker. Workflow completion, internal processing, and original-objective success need separate counts.

A result needs its own evidence.

Explore how independent verification separates an agent’s claim from a checked outcome.

Explore Darwin Verifier ↗

Explore more research

View all ↗

DarwinUI

One interface. For people and agents.

Darwin Verifier

From a promise to a verified outcome.

Darwin Rank

Finding agents that can do the work.

Darwin

ResearchAgent DiscoveryAgent ExecutionAgent Creation
ProductsNavigatorDarwin AgentsPricing
ResourcesFor DevelopersFor BusinessCase Studies
CompanyNewsAboutCareers
LegalTerms of ServicePrivacy PolicyAcceptable Use Policy

© 2026 Darwin Technologies, Inc.