Amplifier Stories

Proving Parallel Execution
with Timestamps

How we verified concurrent agent execution through sub-second timestamp correlation in session data

Active

The Claim

Recipe says parallel: 3
But how do we know it works?

# parallel-analysis-recipe.yaml
- id: "run-content-checks"
  foreach: "{{content_check_definitions}}"
  parallel: 3
  agent: "foundation:zen-architect"
  instruction: "Analyze {{item.name}}..."

Configuration declares intent. But configuration isn't proof. We need evidence of actual concurrent execution.

The Method

Correlate start timestamps
from child agent sessions

1 Locate recipe execution session and its child agents
2 Extract start/end timestamps from each spawned agent
3 Map timestamps to individual validation check types
4 Analyze for temporal overlap — concurrent starts prove parallelism

            Key insight: If agents start within milliseconds of each other, they were launched concurrently by the executor — not queued sequentially.
        

Evidence — Content Validation

3 checks, all started within 317ms

Check	Start Time	End Time	Duration
accuracy	19:53:08.810	19:54:34.104	~85s
completeness	19:53:08.967	19:54:42.803	~94s
instructions	19:53:09.127	19:54:41.310	~92s

Start Time Spread

317ms

All 3 checks launched within 0.3 seconds of each other

Timestamps observed in a test run session. Exact values may vary between executions.

Visual Timeline

Concurrent execution, not sequential

Content Validation (parallel: true, 3 agents)

accuracy

85s

completeness

94s

instructions

92s

Quality Validation (parallel: 3, bounded — 5 checks in 2 waves)

depth

102s

coherence

53s

crossrefs

54s

consistency

85s

tone

36s

Example session data — bar positions approximate relative timing.

Evidence — Bounded Parallelism

5 checks, parallel: 3 — two waves

Check	Start Time	End Time	Wave
depth	19:57:41.459	19:59:23.157	1
coherence	19:57:41.624	19:58:34.161	1
crossrefs	19:57:41.989	19:58:35.916	1
consistency	19:58:34.830	19:59:59.605	2
tone	19:58:36.570	19:59:12.742	2

Wave 1 Start Spread

530ms

depth, coherence, crossrefs — within 0.5s

Wave 2 Trigger

~0.7s

consistency & tone start as Wave 1 slots free

Timestamps from example session data. Wave 2 starts as the semaphore releases slots.

Impact

Time saved through parallelism

~65%

faster content validation

271s sequential sum vs 94s wall clock

~58%

faster quality validation

330s sequential sum vs 138s wall clock

            Methodology: Sequential baseline = sum of individual check durations. Parallel time = wall clock from first start to last end. Reduction percentages are valid given accurate timestamps. Actual speedup varies with check count, LLM latency, and concurrency limit.
        

Architecture

How the executor runs parallel steps

Recipe YAML

parallel: 3

→

Executor
asyncio.gather

→

Concurrency

Semaphore(N)

→

Output

N agents

Unbounded: parallel: true

# All items launch at once
await asyncio.gather(
    *[run_item(item) for item in items]
)

Every foreach item runs concurrently. Good for I/O-bound tasks with few items.

Bounded: parallel: N

# Semaphore limits concurrency
sem = asyncio.Semaphore(N)
async def limited(item):
    async with sem:
        return await run_item(item)
await asyncio.gather(*[limited(i) ...])

At most N items run concurrently. Prevents overwhelming providers with too many parallel LLM calls.

Real Examples

Parallel execution in production recipes

⚡

parallel-analysis-recipe.yaml

foreach: "{{checks}}"
parallel: true
agent: "foundation:zen-architect"

Unbounded parallelism for multi-file analysis. All checks run simultaneously.

📊

multi-file-analysis.yaml

foreach: "{{files}}"
parallel: true
agent: "self"

Each file analyzed concurrently. Results aggregated after all agents complete.

🛡

validate-bundle.yaml

foreach: "{{bundles}}"
parallel: false
agent: "smoke-test"

Explicitly sequential. Proves the flag is intentional — not just a default.

Source: microsoft/amplifier-bundle-recipes/examples/ and amplifier-foundation

The Pattern

Self-documenting parallel metrics

A proposed enhancement: embed proof directly in execution output so future runs are self-verifying.

// Proposed parallel_metrics in tracker.json
{
  "parallel_metrics": {
    "max_concurrent": 3,
    "wall_clock_time_seconds": 94,
    "total_check_time_seconds": 271,
    "parallelism_efficiency": 2.88,
    "time_saved_seconds": 177
  }
}

            Efficiency ratio explained: 271s ÷ 94s = 2.88× — meaning the system performed nearly 3× the work in the same wall-clock window. Perfect utilization for a concurrency limit of 3.
        

This metrics pattern is a proposed enhancement, not confirmed shipped. Values shown are derived from example session data.

Velocity

Built and shipped by a focused team

90%

of executor commits

Brian Krabach (19/21)

3

contributors

Krabach, momuno, Schillace

1

repo

amplifier-bundle-recipes

            Bounded parallelism added in commit 997b85e by Brian Krabach, January 7, 2026. Uses asyncio.Semaphore for safe concurrency limiting on foreach steps.
        

Sources & Methodology

How this story was verified

Primary Source Code

modules/tool-recipes/amplifier_module_tool_recipes/executor.py — recipe executor with asyncio.gather and asyncio.Semaphore
examples/parallel-analysis-recipe.yaml — parallel: true on foreach
examples/multi-file-analysis.yaml — parallel: true on foreach
amplifier-foundation validate-bundle.yaml — parallel: false (explicit opt-out)

Repository

microsoft/amplifier-bundle-recipes

Git Evidence

Bounded parallelism: commit 997b85e, Brian Krabach, Jan 7 2026
Executor authorship: 19/21 commits by Brian Krabach (~90%)
Other contributors: momuno (1 commit), Sam Schillace (1 commit)

Timestamp Data

Timestamps presented as example session data observed in a test run
Start time spread and duration calculations are mathematically correct given the timestamps
Impact percentages (65%, 58%) derived as: (sequential_sum − wall_clock) / sequential_sum
Exact values will vary between executions depending on LLM latency and load

What is NOT claimed

No specific version tag is associated with these changes
The parallel_metrics JSON block is a proposed pattern, not confirmed shipped
Timestamps cannot be independently verified from git evidence alone

Takeaway

Claims aren't proof.
Timestamps are.

✓ Verify, don't trust — configuration declares intent, timestamps prove execution
✓ Session archaeology — child agent start times tell the real story
✓ Build in observability — make parallel systems self-documenting
✓ Quantify impact — “parallel” means nothing without wall-clock measurements

Parallel execution is active in the recipe executor today. Try parallel: true on your foreach steps.

Proving Parallel Executionwith Timestamps

Recipe says parallel: 3But how do we know it works?

Correlate start timestampsfrom child agent sessions