AI Agent Frameworks: How to Choose for Production

At a glance

This diagram is a topic-specific decision aid: connect the article’s context to evidence before taking the next action.

This guide is for teams choosing an AI agent framework. It helps you evaluate operational fit beyond a quick demo. It does not provide a universal framework ranking or replace a proof of concept on your workload.

The framework scorecard

Use Control → Evidence → Tests → Operations. A framework is useful when it reduces implementation work without making failures opaque.

Start with the workflow, not the library

Write the task, tools, state, approval boundaries, latency target, deployment model, and failure responses first. AI agent architecture explains why the parent task and decision boundaries matter more than the number of abstractions in a framework.

Run a failure-focused proof of concept

Do not test only a successful conversation. Include a timeout, malformed tool argument, empty retrieval, duplicate event, partial state, user correction, and approval rejection. Record what the framework handles, what your code must implement, and what remains invisible.

Keep ownership explicit

Framework defaults are not your reliability policy. Set budgets, permissions, retention, redaction, and alerting in your application. Building production-ready AI agents provides a broader readiness checklist.

Release checklist

• Define the workflow and boundaries before selecting abstractions.
• Verify tool permissions and output validation.
• Trace parent tasks, model attempts, tools, and decisions.
• Test degraded paths and cancellation.
• Document framework behavior your team still owns.

Decision rule: Validate the example’s inputs, output, permissions, and failure behavior before connecting it to a consequential side effect.

Recommended next reads

Continue with AI agent architecture, building production-ready AI agents, and AI agent testing.

Test the framework against ownership boundaries

For every capability the framework provides, identify who owns the policy, data, credentials, retries, state, and evidence. Defaults are not governance. A framework may supply a convenient retry loop, but the workflow owner still needs to decide which errors are transient and which actions are idempotent. A framework may expose tool registration, but the application still needs tenant-aware authorization.

Inspect the escape hatches

Find out how to stop a run, replace a dependency, handle a partial response, attach a reviewer, and recover after process restart. These escape hatches are often more important than the happy-path API. Build a small fixture that exercises each one and keep the result with the framework decision record.

Evaluate maintenance cost

Count the code needed for tracing, fixtures, deployment, upgrades, provider changes, and incident response. An abstraction that saves twenty lines in a demo can create a large operational dependency if its internal state cannot be inspected. Prefer a framework whose concepts map cleanly to the team’s existing runbooks and release process.

Revisit the decision with evidence

After the first production cohort, compare actual failure classes, latency, cost, and developer effort with the proof-of-concept assumptions. Keep the framework when it reduces meaningful work without hiding consequential behavior. Replace or narrow it when the abstraction prevents the team from making a safe decision.

Compare the control surface

The first framework question is not how quickly it produces a demo. Ask what the application can control when the model is uncertain or a dependency fails. Can you set a maximum number of steps? Can you cancel a run? Can you distinguish a planned tool call from an executed one? Can a reviewer inspect the state before a side effect? If the answer is hidden behind framework internals, the abstraction may reduce code while increasing operational risk.

Inspect state and transitions

A production agent needs a durable parent task and explicit child operations. Inspect how the framework represents waiting, retrying, approval, cancellation, and partial completion. A framework that only returns a final message may be adequate for a chat prototype but insufficient for a workflow where an operator must explain why a customer record changed.

Verify tool boundaries

Check whether tools are typed, whether arguments are validated before execution, whether permissions can be computed from the current user and tenant, and whether credentials remain outside model-controlled context. Test what happens when a tool returns malformed data or an instruction embedded in a result. AI agent security provides the control questions to carry into the proof of concept.

Evaluate the operational envelope

Run a workload matrix instead of one happy-path prompt. Include short and long tasks, empty results, slow providers, rate limits, duplicate events, malformed tool arguments, approval rejection, and process restarts. Measure time to completion, number of model calls, tool failures, cost, and the amount of custom code required to recover.

Plan for portability deliberately

Portability is not only the ability to swap model providers. It includes prompts, message formats, tool schemas, evaluator hooks, tracing fields, and deployment assumptions. Keep the business outcome and policy in application-owned code. Let the framework orchestrate where it genuinely helps, but avoid hiding the contract inside a provider-specific callback that cannot be tested independently.

Record the framework decision

Write down why the team selected the framework, which capabilities were verified, which were assumed, and what remains custom. Include a small reproducible fixture and the failure cases that influenced the decision. Revisit the record when the framework, model, or workflow changes; a framework decision is part of the system’s operational history.

A staged adoption path

Begin with one workflow and read-only tools. Add traces and regression fixtures before introducing parallel agents or autonomous writes. Next, add one reversible side effect behind approval. Only then evaluate concurrency, long-running state, and broader permissions. At each stage, compare framework behavior with the simplest implementation the team could maintain directly. The right framework is the one that improves the next decision without making the failure path harder to see.

Define the application boundary first

An agent framework should sit inside an application contract, not become the contract by accident. Write down the user task, the data the workflow may access, the tools it may call, the side effects it may cause, the expected completion signal, and the conditions that require a person. Then identify which parts are model orchestration and which parts are business policy. This separation makes it possible to change a framework without rewriting authorization, billing, retention, or customer-facing behavior.

Keep policy outside model orchestration

Frameworks are good at sequencing calls, carrying state, and exposing extension points. They should not be the only place where the system decides whether a user may access a record or whether a refund is permitted. Derive identity and scope from the authenticated application context. Validate proposed tool arguments in code. Record the policy decision alongside the framework step. If a framework callback is the only authorization check, the team may lose the control during an upgrade or an alternate execution path.

Name the stable interfaces

Define interfaces for model invocation, retrieval, tool execution, approval, evaluation, and tracing. The interface should express the outcome the application needs, not the internal object shape of a particular library. For example, a tool runner can accept a normalized action and return an explicit success, rejection, timeout, or unknown outcome. That boundary remains useful when the framework changes its message format or adds a new orchestration primitive.

Evaluate state management

Many framework comparisons focus on prompts and tools while ignoring state. Ask how the framework represents a parent run, child operations, intermediate results, retries, approvals, cancellations, and resumptions. Determine whether state is durable, inspectable, versioned, and safe to replay. A conversational memory feature is not the same as a durable workflow state machine; confusing them can create duplicate actions or make a long-running case impossible to recover.

Test interruption and resumption

Stop a run after a model response, during a retrieval request, before a tool side effect, and after a tool returns but before the result is acknowledged. Restart the worker and inspect what happens. The desired behavior may differ by step: a read can be retried, a proposal can be regenerated, and a side effect may require reconciliation instead of another attempt. Record the framework’s behavior and the application code needed to enforce the safe path.

Test cancellation honestly

Cancellation is a business behavior, not just a process signal. If a user cancels while the agent is preparing a message, the draft may be discarded. If cancellation arrives after an external write, the system may need to finish reconciliation and report what happened. Check whether the framework propagates cancellation to child calls and whether your tools can stop or compensate. Make cancellation visible in traces so “cancelled” does not hide an unknown side effect.

Compare execution models

Sequential, parallel, event-driven, and planner-executor frameworks make different promises. Sequential execution is easier to inspect but may be slower. Parallel execution can reduce latency but introduces ordering, cancellation, and shared-state hazards. Event-driven execution supports long-running work but requires durable state and duplicate-event handling. Planner-executor designs can separate reasoning from action but need an explicit boundary between a proposed plan and an authorized operation.

Do not choose a model because its demo is more autonomous. Choose it because the execution semantics match the task and the team can operate the failure modes. Trace the parent task and every child operation regardless of the model; otherwise a faster path can become a less explainable path.

Inspect tool lifecycle support

A framework may make tool registration easy while leaving the important lifecycle work to you. Verify how tools declare input schemas, permissions, timeouts, retries, idempotency, output validation, and audit fields. Test a tool result that is empty, malformed, delayed, contradictory, or contains untrusted instructions. A good framework makes it easy to represent these states; a dangerous one turns every result into a string that the next model call must interpret.

Keep secrets out of the agent context

Credentials should be held by the tool executor and selected from application context. The model should receive the minimum result required to continue, not the credential, connection string, or unrestricted response. Check logs, traces, error messages, and framework callbacks for accidental propagation. Include secret-shaped values in test fixtures and verify redaction across normal and exceptional paths.

Measure developer and operator effort

Framework selection has two audiences. Developers want a clear implementation path, good types, useful tests, and predictable upgrades. Operators need traces, run state, recovery controls, alerts, and a way to understand a bad outcome. Measure both during the proof of concept. Count the code required for a basic workflow, then count the code required for a timeout, approval rejection, provider outage, replay, and partial completion. The second number is often the more important one.

Review the upgrade path

Read the framework’s release and migration practices before committing to it. Check whether prompts, message schemas, tracing hooks, and state formats are stable. Test an upgrade against a saved fixture and compare the resulting traces. If the framework stores opaque state that cannot be migrated or inspected, account for that lock-in as an operational risk rather than treating it as a hidden implementation detail.

Design evaluation around the framework

An agent framework changes behavior through scheduling, retries, context assembly, tool selection, and message formatting. Include those behaviors in evaluation. A candidate that produces the same final answer may still be worse if it makes twice as many calls, loses an approval boundary, or becomes impossible to debug. Version the framework, adapter, model, prompt, and evaluator together in the comparison record.

Use trace-based fixtures

Create fixtures that assert more than the final text. Check that the expected parent run exists, the right tool was selected, arguments were normalized, unauthorized actions were rejected, retries stayed within budget, and the final outcome was recorded. A trace fixture turns an operational promise into something a pull request can verify. It also gives the team a way to compare frameworks without relying on a subjective demo.

Plan deployment topology

Some frameworks assume a single process, while others expect durable workers, queues, or a separate state store. Map the runtime dependencies before adoption. Identify where state, prompts, tool payloads, traces, and credentials live. Test a worker restart, queue delay, region failure, and version skew between producers and consumers. A framework that works locally may need significant infrastructure to make its execution guarantees true in production.

Keep versions compatible

Long-running workflows can cross deployments. A run started with one framework version may resume under another. Define whether old state is migrated, drained, or rejected with a recoverable message. Store the version with the parent run and child steps. When an upgrade changes serialization or tool semantics, use a staged drain and retain the ability to route unfinished work to the prior worker.

Establish a maintenance cadence

After launch, review framework health alongside agent outcomes. Track upgrade backlog, dependency vulnerabilities, failed resumes, state migrations, tracing coverage, tool errors, and developer workarounds. A framework may remain technically available while the team gradually bypasses it because the safe path is too difficult. Treat repeated workarounds as evidence that the abstraction or its integration needs redesign.

Decide when to simplify

If a workflow has become a small deterministic sequence with one model call and one validated tool, a heavyweight framework may no longer be earning its cost. Conversely, if the workflow has grown approvals, retries, resumptions, and multiple owners, a minimal hand-rolled loop may be hiding important state. Reassess the boundary with evidence. Simplification and expansion are both valid outcomes when they improve control and explainability.

Create a framework review packet

The packet should be readable by engineering, operations, security, and product stakeholders without requiring a private demo or undocumented context.

Before approving a framework, attach a short packet to the decision: task definition, architecture boundary, scorecard, failure fixtures, representative traces, security review, deployment assumptions, dependency and upgrade plan, estimated operating cost, ownership map, and rollback or replacement path. Include the questions the proof of concept could not answer. This packet keeps the choice reviewable and prevents a successful demo from becoming an unexamined permanent dependency.

A worked framework evaluation

Suppose a team is building a support workflow that classifies a request, searches account data, drafts a response, and sometimes proposes a record update. Start with a direct implementation of the contract: the authenticated application supplies tenant and account scope, a model proposes a classification, retrieval returns typed evidence, and a tool runner validates a proposed update before any write. Then implement the same workflow in the candidate framework. The comparison is meaningful only when both paths use the same prompts, model, data, policy, and test cases.

Compare the visible run story

For a successful case, inspect whether both implementations show the parent request, classification, retrieval, draft, proposed update, approval state, execution, and final outcome. For a failed case, inspect whether the framework exposes the first failed dependency or only reports that the run stopped. For a resumed case, check whether the original run ID and versions remain connected. The framework should reduce the amount of plumbing required to preserve this story, not make it impossible to see.

Compare the control story

Send a request for another tenant’s record, an update with an invalid state transition, a duplicated callback, and a tool response containing an instruction. Confirm that application-owned authorization and validation reject the same cases in both paths. If the framework has a built-in guardrail, treat it as an additional layer until its behavior is tested and its version is recorded. Never replace a deterministic policy check with a claim that the framework “understands” the boundary.

Failure classes to put in the scorecard

Framework tests should be organized around mechanisms rather than a list of provider errors. Include invalid input, missing context, empty retrieval, malformed model output, tool timeout, provider rate limit, worker restart, stale state, approval expiry, duplicate event, cancellation, and partial side effect. For each case, define the expected state, user-visible response, trace evidence, retry decision, and owner. This turns framework evaluation into a decision about behavior rather than preference.

Security and privacy review

A framework can change where prompts, tool results, state, and traces are stored. Review its defaults and integrations before adopting it. Determine whether sensitive content is serialized into checkpoints, whether logs include full messages, whether remote observability is enabled, and whether state can be deleted by tenant. Test redaction on normal outputs, exceptions, retries, and serialized state. A framework with excellent orchestration but uncontrolled data retention may be the wrong choice for the workflow.

Review credentials and execution identity

The worker that runs a framework may have broad credentials, while the initiating user does not. Verify that tool execution derives tenant and user context rather than relying on a worker-wide authority. Check background jobs and resumed workflows, where the original request context can be easy to lose. Record the execution identity and policy decision in the trace. The framework should help carry context; the application remains responsible for deciding what the context permits.

Economics and latency

Measure more than model tokens. Include framework overhead, serialization, state writes, queue delay, tracing, evaluator calls, retries, and human review. Measure p50 and p95 completion time for the full user task, not only the model call. A framework that adds a small amount of latency to a long asynchronous workflow may be acceptable; the same overhead can be harmful in an interactive support flow. Tie the threshold to the workflow’s promise.

Model the cost of failure

The cheapest successful run is not necessarily the cheapest system. A framework that saves a call but produces more repair work may increase total cost. Estimate the cost of incorrect actions, review time, incident response, and migration effort. Record assumptions and revisit them after a production cohort. This makes the framework decision honest about operational economics rather than optimizing only the provider invoice.

Migration and rollback

If the team is replacing an existing orchestration layer, define how in-flight runs are handled. Drain them, migrate their state, or route them to the old worker until completion. Do not switch a shared state format without a compatibility plan. Keep the old path available long enough to compare outcomes and recover from a framework-specific regression. A migration is complete when the team can explain both new and old runs, not when the new dependency is installed.

Keep the decision reversible

Use a narrow workflow, a small cohort, and explicit promotion criteria. Store framework version with every run. When a failure appears, pause the affected route or return to the previous executor without deleting the evidence needed to investigate. If the framework cannot support a safe rollback because it owns opaque state or changes semantics invisibly, treat that limitation as a release blocker and narrow the adoption boundary.

What the framework should make easier

The best adoption outcome is not the largest number of framework features. It is a shorter path from a user task to a controlled, testable, observable workflow. The framework should make parent-child execution evidence consistent, tool registration explicit, state transitions inspectable, retries bounded, and evaluation hooks available. It should reduce accidental complexity while leaving deliberate product policy in code the team owns.

What it should not hide

Do not let the framework hide model versions, prompt changes, retrieved evidence, tool arguments, approval decisions, or failure dispositions. These are the facts an operator needs when a result is wrong. If the abstraction combines several events into one callback, add instrumentation at the boundary or choose a narrower integration. Convenience is not a sufficient reason to erase the causal sequence.

Make the choice legible to the team

A framework decision should be understandable to an engineer who did not attend the original demo. Include the workflow diagram, scorecard, fixtures, trace screenshots or structured examples, known limitations, and the reason the chosen trade-offs are acceptable. Explain which parts are framework behavior and which parts are application policy. This reduces the risk that a future maintainer assumes an undocumented default is a security or reliability guarantee.

The final adoption test

Ask a second engineer to implement one failure case and investigate one recorded run without verbal help. If they cannot find the state transition, owner, policy decision, or rollback instruction, the framework integration is not ready. Fix the missing evidence or simplify the abstraction before expanding to more tools and autonomous actions. A framework earns its place when it helps the team make the next safe decision faster and with less guesswork.

Review the human experience

An operator should not need to understand every framework abstraction to handle an exception. Give the run a readable status, a clear last action, the relevant evidence, and bounded choices. When a reviewer must approve or reject a step, show the normalized action and its scope instead of a raw message history. Good operational design reduces both response time and the chance that a tired operator approves something they cannot actually inspect.

Reassess after real use

The proof of concept answers only a subset of the adoption questions. After real traffic, compare framework assumptions with actual retries, stalled runs, approval queues, tool errors, and developer workarounds. Record what improved and what became harder. If the framework is helping the team preserve evidence and recover safely, expand deliberately. If not, narrow the integration or replace it while the state and ownership boundaries are still manageable.

The selection is successful when the team can explain why the framework is present, what it controls, what it does not control, and how to remove it without losing the user’s workflow or its evidence.

Keep that explanation current. Update it when a model provider changes, a tool gains a side effect, a state store moves, or the framework changes its serialization. Attach the update to the release review and rerun the failure fixtures. A framework is part of the operating system of the agent, so its documentation, traces, tests, and ownership need the same maintenance discipline as the workflow code itself. This final record should make the next choice easier, whether that choice is adoption, expansion, simplification, or replacement. Review it with the people who build, operate, secure, and support the workflow. Their different questions expose hidden assumptions before those assumptions become production behavior or an expensive migration problem. The review should end with a named owner, a measured follow-up, and a date for reassessing whether the framework still earns its complexity.

The ai agent frameworks operating model

Put ai agent frameworks into practice

A useful article should help a reader move from an idea to a safe production decision. Start by stating the user-visible outcome, then identify the inputs, the owner, the evidence, and the terminal states. Do not begin with a tool or framework. Begin with the decision the system must support and the cost of getting that decision wrong. For framework selection, keep this criterion in the scorecard and verify it with a small representative workflow.

Define the contract

Write the input and output contract before tuning the model. Name required fields, acceptable values, missing-data behavior, and the response a user receives when the system cannot proceed. A schema validates shape, but it does not prove meaning or authorization. Follow parsing with semantic checks, policy checks, and an explicit fallback. For framework selection, keep this criterion in the scorecard and verify it with a small representative workflow.

Separate proposal from authority

A model can classify, extract, summarize, rank, or propose an action. Deterministic code should own permissions, limits, accounting, retention, and irreversible side effects. This boundary makes the system easier to test and easier to explain after an incident. If a model suggestion is rejected, route it to a visible state instead of silently rewriting it. For framework selection, keep this criterion in the scorecard and verify it with a small representative workflow.

Build representative cases

Create a small case set before claiming that an implementation works. Include ordinary examples, empty inputs, ambiguous requests, stale data, conflicting evidence, malformed outputs, permission boundaries, and provider failures. Label the expected user outcome and the unacceptable failure. Keep the cases versioned so a later change can be compared against the same baseline. For framework selection, keep this criterion in the scorecard and verify it with a small representative workflow.

Validate the full path

Unit tests are valuable for parsers, transitions, policies, and retry rules, but they do not prove the workflow works end to end. Add scenario tests that exercise retrieval, model calls, tool calls, timeouts, duplicate events, approvals, and partial completion. Preserve the trace for each important scenario and check both the final result and the intermediate evidence. For framework selection, keep this criterion in the scorecard and verify it with a small representative workflow.

Make retries safe

Every external write needs a stable identity, a bounded retry policy, and a reconciliation path. A timeout is not proof that an action failed. Record unknown outcomes explicitly, query the provider when possible, and prevent duplicate work with idempotency keys. Never let a generic retry loop decide whether a financial, permission, or communication side effect is safe. For framework selection, keep this criterion in the scorecard and verify it with a small representative workflow.

Design human review

Human review should be specific and actionable. Show the proposed action, normalized arguments, evidence, policy version, expected consequence, and expiration. Bind approval to that exact proposal. If a material field changes, invalidate the approval. Record the reviewer, decision, reason, and result so rejection patterns become improvements rather than repeated surprises. For framework selection, keep this criterion in the scorecard and verify it with a small representative workflow.

Instrument useful evidence

A trace should connect the original request to each meaningful stage and the final outcome. Capture versions, latency, cost, status, error category, tool arguments after redaction, and the evidence used for the decision. Avoid collecting sensitive payloads merely because they are available. Store references or structured summaries when raw content is not necessary for diagnosis. For framework selection, keep this criterion in the scorecard and verify it with a small representative workflow.

Measure outcomes

Completion rate is not enough. Measure correctness, user acceptance, review rate, repair rate, latency, cost, retries, and the frequency of unsafe or unauthorized proposals. Segment the results by version, model, customer cohort, input class, and failure mechanism. A higher automation rate can be a regression when it creates more corrections or delays discovery of mistakes. For framework selection, keep this criterion in the scorecard and verify it with a small representative workflow.

Roll out in stages

Use observation, shadow mode, suggestions, prepared drafts, approved execution, and only then broader automation. Give each stage an owner, cohort, success threshold, and rollback condition. Preserve the manual path until the automated path has demonstrated normal and degraded behavior. Keep in-flight work recoverable when a release is paused. For framework selection, keep this criterion in the scorecard and verify it with a small representative workflow.

Operate failure states

Make waiting, degraded, unknown, failed, cancelled, and completed distinct states. Tell the user whether the system is waiting for data, approval, a provider, a retry window, or manual repair. Give every waiting state an expiration or escalation path. Silent queues and ambiguous success messages are operational defects, not cosmetic issues. For framework selection, keep this criterion in the scorecard and verify it with a small representative workflow.

Review changes

Prompts, models, schemas, retrieval indexes, tools, providers, and policies are all dependencies. Version them and record their versions with each run. When behavior changes, compare a representative cohort with the previous baseline. Review quality, safety, latency, cost, and correction work together; optimizing one dimension can damage another. For framework selection, keep this criterion in the scorecard and verify it with a small representative workflow.

Example decision record

For a meaningful release, write a short record with the goal, affected workflow, expected improvement, known risks, evidence set, rollout stage, owner, rollback command, and review date. Link it to representative traces and the test cases that protect the most important boundary. This record turns a vague confidence claim into something another engineer can inspect. For framework selection, keep this criterion in the scorecard and verify it with a small representative workflow.

Practical checklist

Before launch, confirm that the workflow has a named owner, a clear contract, policy enforcement, safe side effects, representative tests, useful traces, and a recovery path. After launch, sample successful and failed runs, inspect corrections, update the case set, and retire metrics that do not change a decision. The goal is not maximal automation; it is a dependable user outcome that the team can explain and improve. For framework selection, keep this criterion in the scorecard and verify it with a small representative workflow.

A practical ai agent frameworks implementation example

This example is illustrative at the integration boundary; adapt the client names to the repository’s actual dependency. The important behavior is the explicit contract, bounded failure state, and evidence that a reviewer can inspect.

type Decision = { kind: "tool" | "answer" | "handoff"; confidence: number; reason: string };

function canRun(decision: Decision, policy: Policy) {
  return decision.kind !== "tool" || policy.allowsTools === true;
}

Decision rule: Validate the example’s inputs, output, permissions, and failure behavior before connecting it to a consequential side effect.

Frequently asked questions

Compare frameworks by the control they expose

Framework selection is an operational decision, not a popularity contest. Compare a framework on the control surface your workflow actually needs: state transitions, tool authorization, retries, cancellation, streaming, tracing, evaluation hooks, deployment behavior, and escape hatches. A smooth demo can conceal defaults that become difficult to override when a tool fails or a workflow must pause.

Start with a capability inventory

List the workflow’s required capabilities before inspecting framework APIs. Include model routing, structured outputs, tool registration, human approval, durable state, background execution, error handling, observability, testing, and migration. Mark each capability as provided, configurable, or owned by your application. The last category is important: a framework may make a feature easy while leaving the security and reliability contract entirely to your team.

Evaluate defaults, not only features

Run the framework through malformed output, provider timeout, duplicate event, cancelled run, stale approval, tool permission denial, and process restart cases. Record whether the framework retries, persists, drops, or hides each state. Check whether traces retain parent-child relationships and whether a failed tool action can be reconciled. Defaults are part of the production behavior even when the marketing page does not mention them.

Price the abstraction

Measure developer time, runtime latency, provider calls, storage, debugging effort, upgrade work, and the cost of custom escape hatches. A framework can reduce initial code while increasing the number of hidden lifecycle states. Prefer the smallest abstraction that lets the team enforce its task contract and inspect its failures. Keep a direct implementation of one representative path as a comparison point.

Plan portability and exit

Keep prompts, schemas, policies, domain tools, and evaluation cases outside framework-specific wrappers where possible. Document the serialization format and state ownership. Test how to export an in-flight run, replace a model provider, disable a tool, and replay a read-only case. A framework decision is healthier when the team can explain how to reduce its scope or replace it without rewriting the business contract.

Framework rule: Choose the framework that exposes the controls and evidence your workflow needs, not the one with the shortest first demo.