Every agent framework — CrewAI, LangGraph, LlamaIndex, a visual low-code builder, or anything else — leads with orchestration: a way to define agents, wire up tools, and control execution flow. Governance features, where a given framework has them, are secondary to that design goal. Framework selection should evaluate the two categories separately and confirm the governance side against your own requirements, because a framework's orchestration features tell you almost nothing about how hard it will be to govern in production.
This post lays out the criteria that matter once you get past "can it do the workflow I need" and into "can I run this safely at scale."
Why orchestration and governance are different axes
A framework's marketing and documentation are written by the people who built the orchestration layer, and understandably emphasize what that layer does well: how easy it is to define an agent, how flexible the tool-calling pattern is, how well it handles multi-step reasoning or multi-agent handoffs. None of that tells you whether the framework makes it easy or hard to answer questions like: which specific caller triggered this agent run, what credential did each tool call actually use, and would a hard spend cap have stopped this run before it went over budget.
These are governance questions, and they are answered by what sits around the framework — the identity system, the authorization layer, the budget enforcement, the audit pipeline — not by the framework's own feature set. A framework that scores well on orchestration and poorly on governance-integration is not automatically the wrong choice; it just means you are signing up to build more of the governance layer yourself, and that cost should be part of the decision, not discovered after the workflow is already in production.
The five criteria to evaluate
1. Can you intercept a tool call before it executes?
This is the single most important technical question. If a framework's tool-calling mechanism lets you insert an authorization check between "the model decided to call this tool" and "the tool's code runs" — a hook, a middleware layer, an explicit call-wrapping pattern — you can bolt on an external policy engine without forking the framework. If tool execution is tightly coupled to the model's decision loop with no interception point, you are limited to scoping what the tool itself is allowed to do at definition time, which is a weaker and less flexible control. Ask this before anything else: can a request be denied at the point of action, based on a policy evaluated at that moment, or only prevented by never giving the tool broad access in the first place.
2. Does the framework give agents a distinct identity, or does everything run as "the process"?
Some frameworks and patterns give each agent instance something identifiable — a name, a role, a session ID — that can be carried through to downstream systems as an attributable principal. Others execute every agent as an undifferentiated part of the host application, indistinguishable from any other code path to anything it calls. The latter forces you to build identity attribution entirely at the infrastructure layer: wrapping every tool call to inject a caller identity that framework never introduces on its own. This is more work, and it is worth knowing in advance rather than discovering it once several agents are already in production sharing one undifferentiated identity. Machine identity, workload identity, and agent identity covers the distinctions that matter here.
3. How is credential scope handled — per framework object, or per your own wrapper?
Tools in most frameworks hold whatever credential you configure them with, at whatever scope you gave that credential. The question worth asking of a specific framework is how naturally it supports narrow, per-tool, per-task credentials versus how strongly its examples and idioms push toward one broadly-scoped client shared across many tools for convenience. A framework whose idiomatic pattern is "construct one API client, pass it to every tool that needs that API" will accumulate over-provisioned access unless your team actively resists that pattern on every tool you add.
4. Does the framework have a native spend or iteration limit, and is it enforceable independent of the framework?
Nearly every framework offers some notion of a step or iteration limit to prevent an agent loop from running forever. That is a loop-termination control, not a cost control — it does not know what each step costs, and it does not connect to an organizational budget. Evaluate whether the framework's execution can be observed and halted from outside — a supervising process that tracks cumulative cost and can terminate a run independent of the framework's own internal limit — because that external enforcement point is what actually protects your budget when a framework's internal limit is misconfigured or insufficient for a specific workflow.
5. What does the framework log by default, and is it enough to reconstruct an incident?
Ask specifically: does the framework log tool calls with their actual arguments, not just that a tool was called? Does it log a distinct record per agent instance, or an aggregated trace that is hard to attribute to a specific run? Is that log durable and tamper-evident, or is it an in-memory history object that disappears when the process exits? Most frameworks were built for developer debugging, not compliance-grade audit, and their default logging reflects that. Plan to add an external, durable audit layer regardless of what the framework logs natively — treat the framework's own logging as a debugging convenience, not your system of record.
A comparison framework, not a scorecard
Resist the temptation to reduce this to a single score. The five criteria above interact with your specific deployment: a framework with a weak interception point matters much less if every tool you plan to give your agents is read-only and low-risk. A framework with no native identity concept matters much less if you are already routing every external call through a gateway that assigns identity independent of the framework. Evaluate each criterion against your actual planned tool set and blast radius, not in the abstract.
| Criterion | Weak signal | Strong signal |
|---|---|---|
| Tool-call interception | Tool execution tightly coupled to the model loop, no hook point | Explicit middleware/hook pattern before tool execution |
| Agent identity | Every agent runs as an undifferentiated part of the host process | Distinct, attributable identity per agent instance |
| Credential scoping | Idiomatic pattern shares one broad client across tools | Idiomatic pattern favors narrow, per-tool credentials |
| Spend control | Only an internal step-count limit | Externally observable, independently enforceable cost tracking |
| Audit logging | In-memory history, no durable record by default | Structured, durable, per-run logging including tool arguments |
What good looks like
Before committing to a framework for a production agent deployment, you should be able to answer, in writing:
- Where in the framework's execution flow can an external authorization check be inserted, and has your team validated that it actually runs before the tool's side effect?
- How will you attribute every tool call to a specific caller and agent instance, given what identity information the framework does or does not carry natively?
- What is your plan for scoping credentials per tool rather than sharing one broadly-scoped client, given the framework's idiomatic patterns?
- What external system enforces your actual spend budget, independent of any internal step or iteration limit the framework provides?
- Where does the durable, tamper-evident audit record live, and is it independent of the framework's own process lifetime?
A framework that makes these five answers easy to give is a better production choice than one with marginally richer orchestration features and a closed execution model that fights you on all five. Capability fit gets you a working prototype. Governance-integration fit is what determines whether that prototype is safe to put in front of real users and real data. For the broader maturity model this selection process feeds into, see the AI governance maturity model and building an AI agent inventory for how a chosen framework's agents get tracked once they are running.
Common questions
Should a team standardize on a single framework across the organization, or let teams choose?
Standardizing on one framework makes the governance-integration work reusable — the identity attribution, credential scoping, and audit wrapper built for one framework transfer directly to the next project using it, instead of being rebuilt for each new choice. Letting teams choose freely optimizes for local fit at the cost of that reuse. A reasonable middle ground is a short approved list, evaluated against the criteria above, rather than either a single mandated framework or unrestricted choice.
Do frameworks with more GitHub stars or a larger community tend to have better governance-readiness?
Popularity correlates with better documentation, more third-party integrations, and a larger pool of engineers already familiar with the tool, none of which is the same thing as governance-readiness. A widely adopted framework can still couple tool execution tightly to the model loop with no interception point, and a newer, less popular one can expose exactly the hooks you need. Evaluate the five criteria directly rather than treating adoption as a proxy for them.
How often should a framework choice be re-evaluated once agents are already running on it?
Re-evaluate whenever the blast radius of what your agents can do changes materially — moving from read-only tools to ones with write or financial access, or expanding from a single team's use to an organization-wide deployment — rather than on a fixed calendar. A framework whose governance gaps were tolerable for a low-stakes prototype can become the wrong foundation once the same agents are handling production data or irreversible actions, independent of whether the framework itself has changed at all. Threat-modeling runaway agent spend is one concrete trigger worth checking against at each stage.