Why Every AI Framework Needs an Authority Layer

The Tool-Calling Revolution

2025 was the year AI agent frameworks went mainstream. LangChain, PydanticAI, CrewAI, AutoGen, OpenAI Agents SDK, and a dozen others made it straightforward to build AI agents that use tools: agents that call APIs, query databases, modify files, deploy infrastructure, and interact with production systems.

These frameworks solved a hard problem. Tool calling requires function schema generation, response parsing, error handling, retry logic, and context management. The frameworks handle all of this, letting developers focus on the agent's capabilities rather than the plumbing.

But every one of these frameworks shares a critical gap: they provide tool calling without authority. An agent can call any tool it has access to, at any time, for any reason, with no governance, no risk evaluation, and no audit trail. The framework gives the agent a loaded gun and trusts it not to shoot.

This is not a criticism of these frameworks. They are excellent at what they do. But what they do is orchestration, not governance. And AI agents in production need both.

What the Frameworks Provide

Let us be specific about what each major framework gives you.

**LangChain / LangGraph.** The most widely adopted agent framework. Provides tool definitions, agent execution loops, memory management, and workflow orchestration through LangGraph. You can define tools, chain them into workflows, and manage agent state. LangChain has no built-in concept of whether an agent should be allowed to use a tool. If the tool is in the agent's toolkit, the agent can use it.

**PydanticAI.** A type-safe agent framework that uses Pydantic models for structured tool definitions. Excellent developer experience, strong typing, and clean API design. Like LangChain, there is no governance layer. If a tool is registered, it is available.

**CrewAI.** A multi-agent framework where agents have roles, goals, and backstories. Agents collaborate to accomplish tasks. CrewAI has a concept of agent roles, but roles are advisory, not enforced. An agent's role description says "you are a code reviewer," but nothing prevents it from executing deployment tools.

**OpenAI Agents SDK.** OpenAI's official framework for building agents with tool use. Clean API, built-in function calling, and integration with OpenAI models. No governance layer. The agent can call any function it has access to.

**AutoGen.** Microsoft's multi-agent framework. Supports conversational agents, code execution, and tool use. Agents can be configured with "human in the loop" approval, but this is a prompt-level control, not a cryptographic enforcement mechanism.

Each framework is excellent for its purpose. None of them is designed to answer the question: should this agent be allowed to take this action, in this context, right now?

The Authority Gap

The authority gap is the space between "can" and "should." Every framework answers "can this agent do this?" by checking whether the tool is registered and the function signature matches. None of them answers "should this agent do this?" by evaluating policies, scoring risk, and enforcing the decision cryptographically.

This gap creates real problems in production.

**Problem 1: No graduated control.** In every framework, a tool is either available or not. There is no concept of "available for low-risk operations but requires approval for high-risk operations." If you give an agent access to a database tool, it can read one record or delete the entire database. The framework does not distinguish between these operations.

**Problem 2: No contextual evaluation.** The frameworks do not consider context when deciding whether a tool call should proceed. The same tool call might be appropriate at 2 PM during business hours and inappropriate at 3 AM during a maintenance window. The framework does not know and does not check.

**Problem 3: No cryptographic enforcement.** Even if you add approval logic at the application level, there is no enforcement mechanism that the agent cannot bypass. If the approval logic is in the same process as the agent, a malfunctioning agent can skip it. Enforcement must be external to the agent.

**Problem 4: No audit trail.** The frameworks log tool calls, but the logs are plain text with no tamper evidence. There is no hash chain, no signed records, no compliance-grade evidence. For organizations with audit requirements, framework-level logging is insufficient.

Why the Authority Layer Must Be External

Some developers propose adding governance logic inside the agent: wrapping tool calls with approval checks, adding risk scoring to the agent's prompt, or building escalation workflows in the application code.

This approach is fundamentally flawed for three reasons.

**The agent cannot govern itself.** If the governance logic runs inside the agent's process, the agent can bypass it. A malfunctioning model might skip the governance check. A prompt injection might instruct the agent to ignore restrictions. An adversarial input might exploit the governance logic itself. Self-governance is like asking the fox to guard the henhouse.

**Governance must be consistent.** If every agent team implements their own governance logic, you get inconsistent enforcement. Team A's risk scoring is different from Team B's. Team C forgot to add audit logging. Team D's escalation workflow has a bug. Consistent governance requires a shared, external platform.

**Compliance requires independence.** Auditors need to verify that governance controls are independent of the systems they govern. If the governance logic is embedded in the agent, the auditor cannot verify independence. An external governance layer, with its own infrastructure, its own audit trail, and its own operational team, satisfies the independence requirement.

The authority layer must be external to the agent, external to the framework, and enforceable through cryptographic mechanisms that the agent cannot bypass.

The Integration Pattern

Integrating Intended with any AI framework follows the same pattern. Before executing a tool call, the agent submits an intent to Intended describing what it wants to do. Intended classifies the intent, evaluates it against policies, scores the risk, and returns a decision. If the decision is "allow," Intended issues an authority token. The agent includes the token in its tool call, and the execution layer verifies the token before proceeding.

For LangChain, this is a custom tool wrapper. For PydanticAI, it is a middleware function. For CrewAI, it is a task callback. For OpenAI Agents SDK, it is a function wrapper. The integration is typically 5-15 lines of code.

The key design principle: the framework handles orchestration, Intended handles authority. The framework decides which tool to call and with what parameters. Intended decides whether that tool call should be allowed. These are separate concerns and they should be separate systems.

What This Looks Like in Practice

Consider an agent built with LangChain that has access to a deployment tool and a database tool. Without Intended, the agent can deploy code and modify databases without any governance. With Intended, every deployment and every database operation goes through the Authority Engine.

The agent's workflow does not change. It still decides which tools to use based on its objectives. But now, each tool call is evaluated against policies before execution. A deployment to staging proceeds automatically. A deployment to production during peak hours is escalated for approval. A database deletion is denied unless a VP approves it.

The agent is still autonomous. It still operates independently. But it operates within boundaries that are enforced, not suggested.

The Framework Vendors' Perspective

We have spoken with teams at several framework vendors about governance. Their consistent response: governance is not their problem to solve. They are building orchestration frameworks. Governance is a separate concern that should be handled by a separate system.

We agree. Framework vendors should focus on making tool calling, memory management, and workflow orchestration excellent. Governance vendors should focus on making policy evaluation, risk scoring, and audit trails excellent. The two systems integrate cleanly because they solve different problems.

This is the same separation of concerns that exists in the web application world. Django does not include a WAF. Express does not include an IAM system. Rails does not include a SIEM. Application frameworks handle application logic. Security systems handle security. AI frameworks should handle orchestration. Authority systems should handle governance.

Every AI framework needs an authority layer. That authority layer should be external, enforced, and auditable. That is what Intended provides.