How the enterprise AI agent framework matrix was built

Decision question and unit of comparison

The decision question is: which code-first agent framework should an engineering team test when a workflow must coordinate model calls and tools while making state, approval, observability, recovery and deployment explicit? The unit of comparison is the documented framework runtime at a named release, plus an officially documented companion service only when the matrix labels that mechanism as integrated.

The page is not a benchmark, security certification, market-share study or production endorsement. No vendor supplied a score, paid for placement or reviewed the wording before publication.

Inclusion and exclusion boundary

An option had to be maintained at the research cutoff, use a permissive open-source license, support code-first orchestration, and document a path for all five control axes. Exactly five alternatives were retained so the same operational question could be asked of every row.

• Included: LangGraph, Microsoft Agent Framework, CrewAI, OpenAI Agents SDK and Google ADK.
• Predecessor treatment: AutoGen is represented through Microsoft Agent Framework, which Microsoft documents as its direct successor alongside Semantic Kernel.
• Adjacent candidates: Claude Agent SDK and Mastra may fit provider- or language-specific programs, but were outside this five-option control boundary.
• No-framework baseline: a deterministic application workflow remains a valid option when branching, long waits, approvals or resumable execution do not justify another runtime.

The five operating axes

State

Where conversation, workflow variables and execution position live; whether the backing store survives a process restart.

Human approval

How execution pauses, exposes a pending request, accepts an authorized decision and resumes without hiding approval in prompt text.

Observability

What the runtime records for model calls, tool calls, handoffs, errors and timing, and whether telemetry is native or supplied by an integrated service.

Recovery

Whether a failed or paused workflow can restore execution position and how replay interacts with side effects such as payments, messages or record changes.

Deployment

Whether the runtime can be application-owned, self-hosted or managed, plus the cloud and language constraints that change the operating model.

Status vocabulary

Native means the mechanism is documented as part of the framework. Integrated means an officially documented companion product or telemetry path supplies it. Configured means the framework exposes the mechanism, but production durability depends on storage or runtime work. External runtime means long-running recovery is delegated to another workflow engine. These labels describe mechanism location; they do not grade quality or maturity.

Evidence and claim-handling rules

1. Use official release records to stamp the compared version and avoid describing a moving main branch as a release.
2. Use first-party documentation or repository documentation for capability claims. Marketing overview language may establish scope, but not superiority or business outcomes.
3. Attach at least one source identifier to every state, approval, observability, recovery and deployment cell.
4. Record a limitation with every source and a disqualifier with every framework.
5. Separate observed documentation from the evaluator's inference. The public claim ledger records both the source IDs and the boundary.
6. Do not infer cross-language parity from one SDK, or managed-service capability from an open-source package.
7. Do not turn GitHub stars, vendor adjectives, anecdotal adoption or unsupported outcome estimates into a maturity score.

The public source registry, claim ledger, JSON matrix and CSV export make those rules inspectable.

How the interactive shortlist works

The selector applies language and deployment control as hard filters. It uses the declared operating priority and model ecosystem only to order remaining candidates. A candidate is never silently removed for a soft preference, and every result retains its disqualifiers. The calculation runs in the browser, stores no user input and can be reproduced from the public module and dataset.

Known limitations

• Documentation establishes what a vendor describes, not latency, throughput, cost or defect rates in a reader's environment.
• Release cadence can make a version stamp stale. Readers should recheck the source registry before procurement or production rollout.
• Feature parity across Python, TypeScript, .NET, Go, Java and Kotlin is not assumed.
• Human-input primitives do not establish identity, authorization, separation of duties, response deadlines or audit retention.
• Checkpoint restoration does not make an external side effect idempotent. Teams must test replay and reconciliation with their own tools.
• Licenses are reported from official repositories, not supplied as legal advice.

Editorial ownership, freshness and corrections

Pharos Production Engineering Editorial selected the comparison boundary, read the cited official materials and assembled the public data. AI-assisted drafting was used for structure and language; source selection, claim boundaries, data consistency and release checks were reviewed before publication. Independent technical review was not performed.

The evidence cutoff and method version appear on the comparison, datasets and changelog. A correction request should identify the framework, affected field, official source and observed mismatch. A verified correction receives a dated changelog entry rather than a silent rewrite.