FERZ is not an Agent Framework
This comparison addresses the largest source of category confusion in current AI procurement: agent frameworks are the substrate through which AI actions reach the world, and the framework's execution capability is easily mistaken for authorization. The distinction is that the framework executes whatever the language model proposes (modulo developer-added intervention points), while FERZ evaluates proposed actions against encoded policy and governed state before execution. The architectural-class test is established in and the canonicalization requirement that distinguishes authorization from orchestration is developed in Versioned Meaning, Auditable Records, Stable Ontologies (Meyman, 2026; DOI 10.5281/zenodo.18328587)The Authorization Artifact Test (Meyman, 2026; DOI 10.5281/zenodo.20013582) and The agent framework provides composition; FERZ provides authorization..
Where the categories diverge
The two architectures diverge along four architectural axes.
At the AI action proposal boundary. The authorization verdict precedes execution of the proposed action, with built-in action canonicalization and AI-action semantics.
At the tool-loading, prompt-formatting, and tool-call-dispatching layer. The framework executes tool calls produced by the language model unless application code intervenes.
Encoded policy evaluated against a canonicalized action specification, governed state, and policy version. The question asked is whether the action is authorized.
The language model's output. The framework executes whatever tool call the model proposes; the model's output is the de facto decision.
A verdict in the canonical verdict space {ALLOW, DENY, ABSTAIN} with an authorization artifact reconstructable from policy, action specification, and governed state.
Execution traces, intermediate-step logs, and tool-call records. Useful for debugging and observability; not structured as policy-versioned authorization artifacts.
Fail-closed by architectural design. Execution is blocked when governance conditions are not met.
Fail-open by default. The framework executes tool calls unless application code explicitly intercepts; safety is the developer's responsibility to add.
Why the distinction is structural
An agent framework and an authorization architecture address different problems. The framework's problem is composition: how to wire a language model to tools, manage prompts and memory across turns, route between agents in multi-agent workflows, and dispatch tool calls when the model proposes them. The framework's deliverable is execution. The authorization architecture's problem is governance: how to evaluate a proposed action against encoded policy and governed state, produce a verdict before execution, and emit an artifact that survives third-party verification. The two problems can be solved by different systems composed together, but solving the composition problem does not solve the governance problem.
The authority source is categorically different. An agent framework dispatches whatever tool call the language model produces, optionally subject to developer-inserted callbacks, schemas, or content filters. The de facto decider is the language model. Whether the action proceeds reflects what the model said to do. FERZ evaluates the proposed action against encoded policy: which actions are permitted, under which conditions, in which governed state, against which policy version. The decider is policy, not model output. An agent framework with safety callbacks does not become an authorization architecture, because the callbacks are extension mechanisms, not architectural commitments to policy-based evaluation.
The evidence artifacts reflect this difference. An agent framework produces execution traces and tool-call logs: useful for observability, debugging, and post-hoc reconstruction of what the agent did. The artifact describes execution. FERZ produces an authorization verdict with a reconstructable record: policy version, canonicalized action specification, governed state, evaluator version, and the resulting verdict. The artifact describes a decision. Execution traces and authorization verdicts answer different questions; one is descriptive evidence of what happened, the other is decisional evidence of what was permitted.
The structural claim follows. Agent frameworks and FERZ compose by design: the framework orchestrates AI actions; FERZ authorizes them at the action proposal boundary. A FERZ-governed deployment uses LangChain, AutoGen, CrewAI, or any other agent framework for the orchestration it provides, and inserts FERZ at the tool-invocation boundary where actions cross from intent to execution. Framework features that intercept execution (callbacks, guardrails modules, safety filters) are extension points where FERZ can be called from; they are not substitutes for it. The framework provides composition; FERZ provides authorization; the architectural class remains orchestration regardless of how many safety features are added.
What buyers often confuse
The most common conflations involve orchestration-class systems positioned as governance under framework-feature framing. The architectural argument applies regardless of presentation.
Architectural diagnostic
Any vendor or product claiming AI governance can be evaluated against four architectural questions, anchored to The Authorization Artifact Test (Meyman, 2026; DOI 10.5281/zenodo.20013582):
Does the system produce an artifact for the proposed AI action that exists before the action executes?
Is the authorization artifact reproducible from policy, canonicalized action specification, and governed state, sufficient for independent third-party verification?
Does the system include an ABSTAIN verdict with explicit fail-closed semantics pending authorized human override?
Is fail-closed the architectural default, or an opt-in configuration?
References
Related doctrine and concepts
Frequently asked questions
Callback systems in agent frameworks let developers insert code at execution points. They are extension mechanisms, not authorization architectures. The framework still executes whatever the LLM proposes unless application code explicitly intervenes. There is no built-in canonicalization, no governed state model, no policy-versioned authorization artifact. The callback is a place to call FERZ from, not a substitute for it.
Tool registration limits which actions are possible to propose; it does not evaluate proposed actions against governing policy in context. A registered tool can still be invoked under inappropriate conditions: the wrong action against the wrong target, at the wrong time, in the wrong state. Registration is a coarse static allow-list at the tool level. FERZ authorization is policy evaluation at the action level, against the specific proposed parameters, in the specific governed state, against the specific policy version. The two are different layers of control; tool registration narrows the set of possible actions, FERZ authorizes each specific proposal.
They sit alongside. An agent framework provides orchestration: tool loading, prompt management, multi-agent coordination, execution flow. FERZ provides authorization: policy-based verdicts on proposed actions before execution. A FERZ-governed deployment uses the framework for what it is good at and inserts FERZ at the action proposal boundary.
These modules typically filter content, validate output format, or apply allow/deny lists against static configuration. They are supervisory mechanisms. They do not produce policy-versioned authorization verdicts reconstructable from action specification and governed state. A framework that calls a module "governance" does not thereby implement AI-action authorization.
At the tool invocation boundary. When the orchestration framework determines that an agent will execute a tool call, FERZ evaluates the proposed action against governing policy and emits a verdict. The framework receives the verdict and proceeds, blocks, or routes to authorized human override depending on the outcome.
MCP is an interface standard that defines how tools register their capabilities and how agents discover and invoke them. Like an agent framework, MCP is orchestration: it standardizes the wire format and lifecycle of tool calls. It does not authorize the calls themselves. FERZ fits at the MCP server side, evaluating proposed tool invocations against policy before the tool executes. The transport layer routes the call; FERZ decides whether the call is authorized. The two compose as orchestration and authorization, the same way an agent framework and FERZ compose.
Yes. FERZ is independent of the orchestration framework. The architectural commitment is to evaluate proposed AI actions against encoded policy at the action proposal boundary, regardless of how the proposal was generated. Custom orchestration code calls FERZ at the same boundary a framework would: when the orchestrator is about to dispatch a tool call or external action, the call passes through FERZ first. The FERZ integration point is the action boundary, not the framework boundary.
An LLM judge produces a model output evaluating another model's output. The authority source is model judgment, not encoded policy; the artifact is a classification, not a policy-versioned authorization verdict reconstructable from action specification and governed state. LLM-as-judge can be a useful signal but does not satisfy the architectural requirements for AI-action authorization.
FERZ, Inc. (2026). FERZ is not an Agent Framework. https://ferz.ai/governance/comparisons/ferz-is-not-an-agent-framework
BibTeX
@misc{ferz2026notaf,
author = {{FERZ, Inc.}},
title = {FERZ is not an Agent Framework},
year = {2026},
url = {https://ferz.ai/governance/comparisons/ferz-is-not-an-agent-framework},
note = {FERZ Architectural Comparison}
}