Agent frameworks build the agent. Something still has to govern it.
LangGraph, LangChain and CrewAI are good at what they were designed for: composing models, tools, memory and control flow. The questions that follow a successful prototype — who authorized this, which credentials it used, where the record lives — sit outside the framework by design.
Where agent frameworks is the right tool.
Worth stating plainly first. A comparison that only lists gaps is marketing, and it will not survive contact with the engineers who chose the tool.
Composition is genuinely solved
Chaining a model to a set of tools, managing conversation state and expressing control flow used to be bespoke work in every project. Frameworks turned that into library calls, and the engineering time they save is real.
The iteration loop is fast
Changing a prompt, swapping a model or adding a tool is a code edit. For the exploratory phase — where the shape of the problem is still unknown — that speed is worth more than any control you would be putting in place prematurely.
The ecosystem is deep
Retrieval strategies, evaluation harnesses, tracing integrations and community tool wrappers exist because a lot of people are solving adjacent problems in the same idiom.
Head to head on the operating model.
The same capabilities the full comparison uses, narrowed to this category. What matters is which controls are native to the system and which your team must design, host and audit around it.
| Capability | Agent frameworksLangGraph, LangChain, CrewAI | NopsAI |
|---|---|---|
| GitOps-owned platform configurationOperational definitions need review, promotion, rollback and drift evidence across environments. | External Supplied by the application | Core Built into the platform model |
| Caller-scoped AAA before dispatchStarting a run and using each referenced runtime resource are separate authorization decisions. | External Application responsibility | Core Product and runtime checks |
| Scripts and goal-based steps in one DAGTeams need deterministic checks and LLM-assisted reasoning inside the same dependency graph. | Partial Agent reasoning is the primary model | Core One pipeline definition |
| Approved LLM and MCP profilesProvider, credential, scope, model, tool and timeout choices should be centrally governable. | Partial Framework configuration | Core System registry and scopes |
| Guardrails bound to a stepThe rule that constrains a decision has to be chosen per step by the pipeline author, authorized for the caller, and enforced against the action the model actually proposes. | Partial Prompt and retrieval, not bound policy | Core Per-step documents, authorized and enforced |
| Docker and Kubernetes runner placementSensitive work needs eligible execution locations selected by scope, affinity, capacity and state. | External Application infrastructure | Core Dispatcher-managed runners |
| Scoped secret and variable resolutionA run needs its values assembled before execution without embedding a secret in the definition that gets reviewed in Git. | External Application responsibility | Core Scopes and credential references |
| Human approval inside the run graphA run must pause for a named approver and resume from persisted state without holding a runner. | External Custom approval workflow | Core Approval step with durable resume |
| Durable run evidenceOperators need the trigger, policy decisions, context, logs, outputs and final state in one record. | External Observability must be assembled | Core Run-owned evidence model |
| Proposal-first AI changesGenerated pipeline, trigger and schedule changes should return to explicit review rather than mutate production silently. | External Application responsibility | Core Read and proposal-only assistant tools |
Category comparisons describe common design centers, not every implementation or product edition. See all three categories side by side.
The questions that arrive after the prototype works.
None of these are criticisms of the category. They are the problems it was not built to solve, which is a different thing.
Identity stops at the API key
A framework knows which credential it was handed. It has no concept of the human or service that initiated the work, so it cannot check whether that caller was allowed to touch this repository, this environment or this secret. Authorization becomes something the surrounding application has to invent.
Tool access is a code decision, not a policy decision
Which tools an agent may call is expressed in the program that constructs it. Changing that set is a deploy, reviewing it means reading source, and there is no central place to ask which agents can currently reach production.
There is nowhere to put a rule that binds
A system prompt and a retrieved document are both just text in a context window. Nothing in the model distinguishes the architecture note the agent may weigh up from the rollback policy it must obey, and nothing checks the command the agent actually generated against either. Making a constraint enforceable — evaluated against the proposed action and its arguments, failing the task on conflict — is application code, and it gets written again in every project.
Runtime placement is left to you
Frameworks run wherever the process runs. Deciding that a run touching customer data must execute on a specific isolated runner, selected by scope and capacity, is infrastructure work the framework does not model.
Approval is not a primitive
Pausing durably for a named human, releasing the compute while waiting, and resuming from persisted state is a workflow-engine concern. Frameworks generally offer a callback and leave the durability, the approver identity and the audit record to the application.
Evidence has to be assembled after the fact
Tracing tools show what the model did. An audit answer needs the trigger, the effective subject, the authorization decision, the resolved context, the tool calls, the approval and the final state correlated in one record that outlives the trace retention window.
Composition beats replacement.
Replacing a system your team already knows is rarely the honest recommendation. The useful question is where the boundary between them belongs.
Keep the framework where it earns its place
Framework-built capabilities can run behind an approved service endpoint or an MCP profile. The reasoning stays where your engineers are productive; the invocation goes through a boundary that checks the caller first.
Move the boundary questions out of application code
Identity, policy, credential resolution, runner selection and evidence stop being things each project reimplements and become platform configuration reviewed like any other change.
What teams ask in evaluation.
Does this replace LangChain or LangGraph?
No. They solve agent composition; NopsAI solves governed execution around it. A framework-based capability can be registered as an approved service or MCP profile and invoked from a governed run, which keeps the development ergonomics and adds the controls a security review asks for.
We already have tracing. Is that not evidence?
Tracing tells you what happened inside the model call. Evidence in the audit sense also has to name the trigger, the effective subject, the authorization decision that allowed it, the approval that released it and the final state — correlated in one durable record rather than reconstructed from spans.
Can we not just add authorization checks in our own code?
You can, and many teams do. The cost shows up on the second and third workflow, when the checks have to agree with each other, and again at the first audit, when someone has to prove they were applied consistently. That is the point at which the checks want to be a platform rather than a pattern.
Map what your current tools own — and where the governed run boundary is still missing.
Bring your architecture. We will walk the four boundaries with you: reviewed intent, runtime decision, isolated execution and provable outcome.