Start with the job: implement the same bounded agent across major frameworks

A useful framework guide holds the job constant. Define one bounded agent with the same input, tool, state, stop rule and acceptance checks, then show how each framework represents that contract.

Framework-native demos are not comparable when one uses a toy chat and another uses a stateful production workflow. Avoid feature tours that never expose equivalent code paths or operating assumptions.

Keep this page's decision boundary canonical

Every implementation in this series must satisfy one matched fixture. This cluster owns that fixture and the evidence format; LangGraph, Microsoft Agent Framework and OpenAI Agents SDK pages own current package-specific work. The split avoids comparing unrelated demos and makes version gating explicit. Readers can judge how each runtime expresses the same state, tool, interruption and trace requirements rather than inferring quality from code style alone.

The matched fixture should be small enough to reproduce but rich enough to expose framework differences. Include one structured input, one read tool, one controlled write or proposed action, a persisted field and an interruption before consequence. Define the final artifact and prohibited behavior in framework-neutral language. This prevents an implementation from passing by returning fluent text while skipping the tool or losing the state the task requires.

Normalize evidence after each run. Store the same logical events—model request, tool proposal, authorization decision, tool result, state transition and completion—even when frameworks name their spans differently. Compare missing and extra events as well as the final result. If one runtime requires a hosted trace service, record that separately rather than weakening evidence for all candidates. The goal is comparable observability, not identical screenshots or line counts.

Make the operating boundary visible

The shared fixture separates framework-neutral domain logic from orchestration adapters. Each implementation must produce the same observable result and trace enough state transitions to diagnose mismatches.

FIG. 01 / Process map

One fixture, three adapters

Process map applying one bounded agent fixture across multiple framework adapters
Process map: hold the domain task and acceptance checks constant while framework adapters change.

Build a reproducible path

For Agent Framework Guides: Same Task, Different Runtime, use a small fixture that another developer can repeat without privileged production data. Change one boundary at a time and preserve the exact configuration needed to explain how the page's decision was reached.

  1. Specify the common task, fixture data and expected artifact.
  2. Implement domain tools outside framework-specific wrappers.
  3. Add equivalent state, limits, intervention and trace hooks.
  4. Run identical success, tool-failure and interrupted-resume cases.

Keep secrets outside the agent framework guides artifact. Record variable names, scopes and owners, then verify the relevant system of record whenever this tool or workflow can change external state.

Record evidence that survives a rerun

Preserve dependency locks, source, run commands and sanitized traces for every implementation. Record when a feature depends on a hosted service or preview package rather than presenting it as a library-level capability.

  • Framework and dependency versions
  • Equivalent tool and state contract
  • Trace, interruption and failure outputs
  • Hosted dependencies, costs and deployment assumptions

Date the Agent Framework Guides: Same Task, Different Runtime record and keep factual observations separate from inference. If a claim depends on a hosted service, preview feature or moving SDK, name that dependency beside the claim.

Use a decision rule and a stopping rule

Use the guides to eliminate frameworks that cannot express a hard requirement cleanly. Syntax preference is a tie-breaker only after recovery, observability and deployment boundaries pass.

Have another developer reproduce the fixture from the record, then change one domain tool and inspect how much framework-specific work follows. This exposes coupling better than line counts.

FIG. 02 / Decision aid

Compare equivalent evidence

Paired comparison ledger for framework state, failure, trace and deployment evidence
Decision aid: comparisons are valid only when the task and evidence contract are symmetric.

Protect against predictable failure and continue deliberately

For Agent Framework Guides: Same Task, Different Runtime, the architecture review flags three recurring failure modes: the page becomes a vendor listicle; frameworks are compared on different tasks; deployment and observability costs are ignored. Treat them as release checks, not footnotes. This page remains draft when its exact implementation or intent evidence is still research-gated.

Use the AI agent framework field guide next: it starts selection from a fixed production job and hard requirements.

Use the LangGraph lab note next: it implements explicit state, checkpoints and interruption.

Use the Microsoft Agent Framework walkthrough next: it records preview status, sessions, workflows and hosting assumptions.

Use the agent platform guide next: it examines managed state, identity, deployment and data boundaries.