Compared with agent frameworks
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.
What it does well
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.
Capability comparison
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 |
| Docker and Kubernetes runner placementSensitive work needs eligible execution locations selected by scope, affinity, capacity and state. | External Application infrastructure | Core Dispatcher-managed runners |
| Knowledge and secret resolutionA run needs governed context assembled before execution without embedding secrets in definitions. | External Application retrieval layer | Core Scopes, knowledge, secret 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.
Where it stops
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.
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.
Using both
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.
Common questions
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.