How Agent Runtime Resolves Manifests into Execution Graphs

Clear Ideas Agent Runtime 0.1.0 can run an Agent Manifest sequentially or resolve eligible work into a dependency-aware execution plan.

The feature is often described as parallel execution, but parallelism is only the visible result. The runtime first has to determine which steps are independent, which outputs they produce, which later steps consume those outputs, and where ordered execution must be preserved.

The Manifest Remains the Source of Truth

Graph-based orchestration often requires a developer to define nodes and edges directly. Agent Runtime takes a different approach: the portable Agent Manifest remains the definition, and the runtime derives the safe schedule from its data dependencies.

The interactive example contains five steps:

gather-context
      |
      +--------------------+
      |                    |
      v                    v
    draft          extract-evidence
      |
      v
 review-risks
      |                    |
      +----------+---------+
                 |
                 v
              finalize

gather-context uses an MCP tool and writes contextNotes. Both draft and extract-evidence read contextNotes, so they can begin after context gathering completes. review-risks consumes briefDraft. finalize consumes the draft, evidence, and optional risk review.

The relevant part of the manifest is:

steps:
  - id: gather-context
    type: prompt
    tools: [context7__query-docs]
    outputVariable: contextNotes

  - id: draft
    type: prompt
    prompt: |
      Draft a brief using these notes:
      {{ contextNotes }}
    outputVariable: briefDraft

  - id: extract-evidence
    type: prompt
    prompt: |
      Extract three evidence points:
      {{ contextNotes }}
    outputVariable: evidenceNotes

  - id: review-risks
    type: prompt
    prompt: |
      Review this draft:
      {{ briefDraft }}
    outputVariable: riskReview

  - id: finalize
    type: prompt
    prompt: |
      Draft:
      {{ briefDraft }}
      Evidence:
      {{ evidenceNotes }}
      Risks:
      {{ riskReview }}
    outputVariable: finalBrief

The complete example also defines typed variables, model configuration, an MCP connection, conditions, limits, output requirements, and final-output selection. It is available in the interactive example documentation.

How Dependencies Are Resolved

Before execution, Agent Runtime examines the manifest in order. For eligible prompt steps, it checks:

• the outputVariable written by each earlier step;
• variable references in the system prompt and prompt;
• variable references in a when condition; and
• output-variable collisions within the current execution wave.

A step waits if it reads a value written by an earlier step in the current wave. Independent eligible steps can remain in the same wave, up to the run and host concurrency limits.

The run enables this scheduling mode separately from the Agent Manifest:

schemaVersion: "1.0"
agent:
  ref: interactive-brief.agent.yaml
execution:
  mode: parallel
  maxConcurrency: 4

This separation matters. The reusable agent definition does not change when a caller chooses sequential or dependency-aware scheduling.

What Runs Concurrently

In version 0.1.0, concurrent scheduling is deliberately limited to prompt steps that:

• have no tools;
• do not carry runtime extensions;
• do not consume an output produced by another step in the same wave; and
• fit within the configured concurrency ceiling.

Tool-enabled prompts, loops, approvals, webhooks, code steps, sub-runs, and other stateful operations remain ordered. Tool calls inside a prompt step also remain ordered.

These restrictions keep effects predictable. The runtime only introduces concurrency where it can preserve the existing checkpoint and state model.

Timing Behavior

In the example, draft and extract-evidence are the eligible independent branches.

With sequential execution, the wave takes approximately:

draft duration + evidence duration

With concurrent execution, it takes approximately:

max(draft duration, evidence duration) + scheduling overhead

The total run also includes context gathering, risk review, finalization, persistence, and provider overhead. Actual improvement therefore depends on graph shape, model latency, provider limits, and the proportion of the run that is independent.

The largest gains occur when several expensive model calls share the same inputs and their outputs are combined later. A mostly linear agent will see little benefit.

Ordered Commits and Recovery

Branches can finish in any order, but their results commit in manifest order. This gives the runtime a stable state transition and event history even when model requests complete at different times.

The checkpoint records committed state after each execution wave. On recovery, the runtime resumes from the committed step cursor rather than treating partially committed branch output as complete. Attempt fencing prevents an older worker from committing after another process has resumed the run.

This is deterministic orchestration around non-deterministic work. The runtime controls dependencies, scheduling boundaries, commit order, and recovery. It does not claim that model-generated text is deterministic.

When to Enable It

Dependency-aware scheduling is a good fit for agents that perform independent:

• research across several sources;
• extraction from the same context;
• classification or evaluation passes;
• alternative drafts or analyses; or
• preparation steps before synthesis.

Keep sequential execution for agents dominated by tools, side effects, stateful loops, or strict step-by-step reasoning dependencies.

Start with the manifest guide, run the interactive example, or inspect the implementation in the Agent Runtime repository.