Start with the job: choose an AI agent framework for a defined production job

An AI agent framework is useful when it makes a required control loop easier to express, inspect and operate. Start with the production job and a framework-neutral acceptance test; vendor feature lists come later.

Many tasks need a deterministic workflow with one or two model calls, not a general agent runtime. Framework complexity must earn its place through durable state, tool control, intervention or observability the application actually needs.

Keep this page's decision boundary canonical

Use one canonical selection question for the entire framework cluster: which runtime fits a defined production job under known controls? This pillar owns the vocabulary and hard gates. Platform, pattern and implementation pages own narrower operating decisions. Keeping vendor tutorials below that decision prevents a popular SDK from becoming the architecture by default and gives every later comparison the same task, evidence contract and stopping rule.

Define the system boundary before scoring framework features. Include the model provider, retrieval, tools, persistent stores, queues, human review and downstream services that the framework will coordinate. A feature can look built-in while actually depending on a separate hosted product or deployment tier. Mark those dependencies explicitly, because their identity, data retention and availability become part of the agent system even when the application imports only an open-source package.

Framework adoption also creates an upgrade surface. Inspect how state schemas migrate, how interrupted runs behave across versions and whether traces remain readable after configuration changes. A small matched fixture should include a checkpoint created before an upgrade and a controlled attempt to resume it afterward. This is more informative than comparing release counts: it tests whether the runtime can preserve work and whether the team has a recovery path when compatibility is not guaranteed.

Make the operating boundary visible

Frameworks differ in how they represent state, schedule steps, call tools, pause for people, persist progress and emit traces. Those architectural choices shape failure recovery and deployment more than the syntax of an agent constructor.

FIG. 01 / Conceptual model

The framework control surface

Architecture map of agent state, tools, control flow, intervention and traces
Conceptual model: a framework earns its role by making required state and controls explicit.

Build a reproducible path

For AI Agent Frameworks: A Tested Selection Guide, 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. Define one bounded task, input contract and observable outcome.
  2. List hard requirements for state, tools, approvals and deployment.
  3. Implement the same small fixture in shortlisted frameworks.
  4. Compare traces, recovery, portability and operating burden under matched conditions.

Keep secrets outside the ai agent frameworks 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

Use official documentation for capability claims and a shared fixture for behavioral claims. Record package versions and hosting assumptions so a comparison does not mix managed services, libraries and preview features as equivalent products.

  • State and control-flow representation
  • Tool, approval and interruption model
  • Tracing, evaluation and failure recovery
  • Deployment, data handling, licensing and upgrade owner

Date the AI Agent Frameworks: A Tested Selection Guide 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

Choose the smallest framework that passes every hard gate and makes failure legible. A lower-level runtime is appropriate when control matters more than convenience; a higher-level harness fits when its defaults match the job.

Recreate the fixture from a clean environment, interrupt it mid-run and inspect the persisted state and trace. Then replace one provider or tool to measure coupling rather than accepting a portability claim.

FIG. 02 / Decision aid

Choose after hard gates

Decision matrix for AI agent frameworks across state, control and operating burden
Decision aid: eliminate candidates on hard requirements before weighting convenience features.

Protect against predictable failure and continue deliberately

For AI Agent Frameworks: A Tested Selection Guide, 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 agent platform guide next: it examines managed state, identity, deployment and data boundaries.

Use the agent pattern map next: it chooses control flow before framework-specific abstractions.

Use the framework implementation series next: it holds one fixture constant across different runtimes.