An AI agent framework is a software library that provides the components for creating agents, such as model interfaces, tool definitions, the agent loop, memory and state handling. It shapes how an agent is built, while how the agent is hosted and run is the concern of the runtime.
Frameworks are why a working agent can be a few dozen lines of code. LangChain and LangGraph, Pydantic AI, the OpenAI Agents SDK, the Claude Agent SDK, Google’s Agent Development Kit and others each package the same core pieces: a way to call a model, a way to describe tools, an agent loop that runs until the model is done, and some way to keep state. Comparisons usually focus on developer experience. Two less visible properties matter more once an agent is in production: what the framework lets you see and change while the agent runs, and what it leaves entirely to someone else.
What a framework provides
| Component | What it does |
|---|---|
| Model interface | Calls one or more model providers behind a common API |
| Tool definitions | Describes functions the model may call and validates arguments (tool calling) |
| The agent loop | Repeats model calls and tool execution until a stop condition |
| State and memory | Carries conversation history and other state between turns or sessions |
| Orchestration primitives | Handoffs, graphs or sub-agents for coordinating several steps or agents |
| Extension points | Callbacks, hooks, middleware or wrappers that run around model and tool calls |
The last row is the one that decides most of what follows.
The framework decides what can be seen
Every framework exposes points where other code can run around the agent’s work: LangChain’s middleware, with hooks before and after model calls and a wrapper around each tool call; the OpenAI Agents SDK’s guardrails and lifecycle hooks; the Claude Agent SDK’s hooks, such as PreToolUse; Google ADK’s before- and after-tool callbacks; Pydantic AI’s capabilities and wrapped toolsets. Hook-based instrumentation, meaning observation, evaluation and control that run inside the agent’s process through the framework, can only happen at these points. A framework’s extension points are the ceiling on what hook-based instrumentation can do. They are not the ceiling on observation and control in general. The environment an agent runs in can observe and constrain its effects by separate means, such as a sandbox, a network proxy that controls egress, or the permissions of the systems the agent reaches. Those mechanisms do not depend on the framework’s hooks at all.
Two details are easy to miss.
Hooks differ in power. Some only observe: the OpenAI Agents SDK describes its lifecycle hooks as notifications. Some can refuse or rewrite a call: a Claude Agent SDK PreToolUse hook can allow, deny or modify, and an ADK before-tool callback can return its own result in place of the tool’s. A rule written as “check before every tool call” means different things depending on which kind of hook carries it.
Coverage has documented edges. The frameworks’ own documentation is candid about this. In the OpenAI Agents SDK, tool guardrails apply to function tools, not to the handoff call itself, and hosted tools such as web search do not use the guardrail pipeline. In the Claude Agent SDK, a hook that matches the file-writing tools does not fire when the agent writes the same file through a shell command; the documentation points to a sandbox for that case. Each edge is reasonable on its own. Together they mean that a hook-based control is only as complete as the set of paths the framework routes through its hooks.
Build-time choice, run-time risk
A framework is chosen when the agent is built. The risk of an agent is a property of where it runs: which credentials it can reach, which network destinations it can call, which files and systems its actions can change. Those are decided by the execution environment, not by the library.
The Claude Agent SDK’s secure deployment guide makes the separation explicit. The agent runs inside an isolation boundary; a proxy outside that boundary holds credentials and enforces which destinations the agent may reach, so the agent never sees the credential itself. The guide also notes that the SDK’s own command parsing is a permission gate, not a sandbox, and it presents isolation as a set of options for the deployer to choose, from lightweight sandboxing to containers and virtual machines.
The practical consequence is that “which framework?” and “where does this agent run, and what can it reach?” are separate decisions, and the second one carries the risk. Organizations that run agents built on several frameworks also find that rules written against one framework’s hooks do not carry over to another: names, return values and scope all differ, and the emerging OpenTelemetry conventions for agent telemetry are not yet stable. Environment-level observation and controls, such as isolation, egress policy and credential handling, are a separate mechanism from hooks and apply the same way whichever library built the agent.
An example
A team builds a research agent in one framework and a data-cleanup agent in another. They add a pre-tool check to each that refuses writes to the production database. Months later, the cleanup agent gains a general shell tool for running scripts. Its framework’s pre-tool check is configured for the database tool, and the agent’s script connects to the database directly. Nothing in either framework was misconfigured. The write happened on a path the hook was never asked to cover, in an environment where the agent’s process could reach production. A hook could not have closed that gap; an environment that did not give the agent’s process a route to production could have.
Where Sentience fits
Sentience Governor, the free, open-source runtime governance library, attaches through each framework’s own extension points rather than replacing them: a callback handler and middleware for LangChain and LangGraph, a capability for Pydantic AI in a separate package, hooks for Claude Code, and a wrapper for MCP clients. Each records agent actions at the execution boundary in one schema, so the record looks the same whichever framework built the agent, and each evaluates actions against the declared scope and the operator’s policy. Because Governor is hook-based, its coverage follows the hooks each integration uses, with the same edges described above. Governor observes and flags; it never stops a call.
The environment-level half of the problem is what Sentience Secure Runtime addresses. Teams bring the frameworks, models and tools they already use, and their agents run in isolated execution environments with policy enforcement, controlled egress and runtime governance built in, so what an agent can reach is decided by the environment rather than by each framework’s hooks.
Often confused with
An agent harness. A framework supplies components. A harness is a more complete, opinionated assembly that runs an agent, and is often built with a framework.
An agent runtime. The runtime hosts the agent and determines what its actions can reach. The framework shapes how the agent is built.
Agent orchestration. Most frameworks include orchestration primitives, but orchestration is a design choice about coordinating steps and agents, not the library that provides them.
Where the concept stops
A framework defines how an agent is assembled and where its behavior can be observed or intercepted in its own process. It does not decide what the agent’s environment lets it reach, it does not cover paths that bypass its hooks, and its controls do not apply to agents built with a different library. Those are properties of the execution boundary and the environment the agent runs in.