Is an AI agent framework the same as an AI agent?

No. A framework is the toolkit you build an agent with — a runtime plus integrations for tools, wallets, memory, and guardrails. It does nothing until you configure an agent. The agent is the specific, running thing that holds a wallet and acts. On SatoHub, frameworks are resources you build with, not agents.

What's the difference between a framework and an SDK?

An SDK is a focused library for one capability — say, executing swaps or signing transactions. A framework is broader: it runs the reasoning loop and wires SDKs in as tools, alongside wallet handling, memory, and guardrails. You often use several SDKs inside one framework.

Which agent framework should I use for an onchain agent?

It depends on the job. Coinbase AgentKit centers on onchain actions and a strong wallet model; ElizaOS on composing configurable, multi-platform agents; Olas on coordinating agent-run services. Choose on language fit, wallet model, skill ecosystem, and how actively the project is maintained.

What should I check before trusting a framework with real funds?

Look at the wallet model (scoped signers and spend limits, not raw keys), the guardrails it enforces, and whether the repo is open and active. Treat "production-ready" as a claim until the evidence — recent commits, real usage, checkable code — backs it. The Sato Score grades that kind of transparency, not safety or returns.

Do I need a framework at all?

Not strictly — you can assemble the reasoning loop, wallet, tools, and guardrails yourself. But a framework that fits your job saves weeks of plumbing and ships tested integrations. The trade-off is adopting its assumptions, so the choice is worth the same scrutiny as picking a database.

← Back to wiki

What Is an AI Agent Framework?

Last updated 2026-06-24

An AI agent framework is a software toolkit that bundles the pieces an autonomous agent needs — a reasoning loop, tool/skill connectors, wallet and key handling, memory, and guardrails — into one runtime, so builders ship behavior instead of plumbing.

Key takeaways

▸A framework bundles the reasoning loop, tool/skill connectors, wallet handling, memory, and guardrails into one runtime so you configure behavior instead of building plumbing.
▸A framework is **not** an agent — it's the toolkit you build an agent *with*. Browse frameworks as [resources](/directory), not as agents.
▸Onchain frameworks differ most in how they handle the wallet: scoped signers and spend limits matter more than model choice. See [how agents use wallets](/wiki/how-agents-use-wallets).
▸Choose on language, wallet model, tool/[skill](/wiki/what-are-agent-skills) ecosystem, and how the project is maintained — not on the loudest demo.
▸"Open" and "active" are checkable; "production-ready" is a claim until the receipts show it. The [Sato Score](/sato-score) grades that transparency, not safety or returns.

An AI agent framework is a software toolkit that gives you a working agent runtime out of the box: the reasoning loop, the connectors to tools and skills, wallet and key handling, memory, and the guardrails that keep autonomous execution inside a defined risk envelope. Instead of wiring those parts together by hand, you configure them — pick a model, attach skills, set spend limits — and the framework runs the observe-reason-act loop for you.

For onchain builders the framework is where the stack gets assembled. It decides how your agent signs transactions, which chains and protocols it can reach, and how tools are exposed to the model. Choose well and most of the hard plumbing disappears. Choose wrong and you fight the framework's assumptions for the life of the project. One thing it is *not*: an agent. A framework is the workshop; the agent is what you build in it.

Why It Matters

The framework is the single biggest architectural decision an onchain agent builder makes. It locks in how the agent signs transactions, which chains and tools it can reach, how skills are added, and how much guardrail enforcement you get for free versus have to build. A framework with a good wallet model and an active skill ecosystem saves weeks; one with weak key handling or an abandoned codebase becomes a liability the moment real funds are involved. Picking it is closer to choosing a database than choosing a library — you will live with the choice.

How It Works

▸**The reasoning loop.** The framework runs the agent on a cycle — observe (read chain, market, or social data), reason (the model decides), act (call a tool or sign a transaction), report — and repeats it without a human approving each step.
▸**Tool and skill registration.** You attach capabilities — protocol SDKs, RPC reads, APIs, or [Model Context Protocol](/wiki/what-are-mcps) servers — and the framework exposes them to the model in a format it can call.
▸**Wallet and signing.** The framework connects a wallet or key-management layer so the agent can transact, usually through scoped signers, spend limits, and permission policies rather than a raw private key.
▸**Memory and state.** Short-term context plus longer-term storage let the agent remember prior steps, balances, and decisions across the loop.
▸**Guardrails and policy.** Spend caps, allow-lists, human-approval steps for irreversible actions, and sandboxes bound what autonomous execution can do.
▸**Configuration over code.** Most frameworks let you define personality, model, skills, and policies in config so the same runtime produces very different agents.

Key Components

•Reasoning loop / runtime (observe → reason → act → report)
•Model connector (one or more LLM providers)
•Tool and [skill](/wiki/what-are-agent-skills) registry
•Wallet and key management with scoped permissions
•Memory and state store
•Guardrails: spend limits, allow-lists, approval steps
•Plugins / extension system
•Config layer for personality and policy

What a framework actually bundles

Strip the branding and an agent framework is an opinionated assembly of parts you could, in theory, build yourself:

▸A runtime that drives the reasoning loop so you don't hand-roll the observe-reason-act cycle.
▸Model connectors so you can swap the underlying LLM without rewriting the agent.
▸A tool/skill layer — the way capabilities get registered and exposed to the model, increasingly over standards like MCP.
▸Wallet integration — for onchain frameworks, the part that signs transactions, ideally with scoped permissions and spend limits baked in.
▸Memory — context the agent carries between steps.
▸Guardrails — the policy layer that keeps autonomy bounded.

The value isn't any single piece; it's that they're integrated and tested together. You configure behavior instead of debugging plumbing. The trade is flexibility: a framework's assumptions about wallets, tools, and control flow become your assumptions too.

Framework vs. agent vs. SDK (hold the taxonomy)

These get blurred constantly, so be precise:

▸A framework is the toolkit you build *with* — a workshop. It ships a runtime and integrations but does nothing until you configure an agent.
▸An agent is the autonomous thing itself — a specific model, wallet, skill set, and policy, running and acting on a chain.
▸An SDK is narrower: a library for one capability (say, swaps or wallet calls) that a framework wires in as a tool.

So "AgentKit" is a framework, not an agent; an agent built on AgentKit is the thing with the wallet. On SatoHub, frameworks live in the directory as resources you build with, while the curated autonomous agents are tracked separately. If a page calls a framework an "agent," the taxonomy is wrong — and usually the analysis is too.

The major onchain frameworks

Three open-source projects anchor the onchain space, each with a different center of gravity:

▸[Coinbase AgentKit](/resources/coinbase-agentkit). A toolkit from Coinbase Developer Platform for giving agents onchain actions — wallet creation, transfers, swaps, and contract calls — exposed as tools to frameworks like LangChain. Its strength is the wallet model: managed, policy-controlled signers rather than raw keys (AgentKit on GitHub).
▸[ElizaOS](/resources/elizaos). An open-source TypeScript framework for building multi-agent systems, with a plugin architecture and connectors for chains, social platforms, and models. It leans toward configurable, character-driven agents (ElizaOS on GitHub).
▸[Olas](/resources/olas). A protocol and stack (formerly Autonolas) for *autonomous services* — multiple agents coordinating off-chain with on-chain registration and rewards. It's less a single-agent library and more a framework for agent-run services (Olas).

They are not interchangeable. AgentKit is about onchain actions; ElizaOS is about composing agents and integrations; Olas is about coordinating agent services. Match the framework to the shape of the job, not to mindshare.

How to choose one

Score a framework on what will actually constrain you:

Language and model fit. TypeScript or Python? Locked to one model provider or swappable? You'll live in this codebase.
Wallet model. This is the one that bites. Does it support scoped signers, spend limits, and account abstraction such as ERC-4337, or does it expect a raw private key? See how agents use wallets.
Tool and skill ecosystem. How many skills and integrations exist already, and does it speak MCP? More existing connectors means less you build.
Chains and protocols. Does it reach the chains and venues your agent needs?
Guardrails. What policy enforcement is built in versus left to you?
Maintenance signal. Is the repo open and active — recent commits, real issues, a community — or a stale snapshot? An abandoned framework is technical debt the day you adopt it.

When you're ready to assemble the whole thing, the how-to-build-an-onchain-agent guide walks the path from framework to mainnet.

Examples

▸A builder uses Coinbase AgentKit to give a LangChain agent a managed wallet with spend limits, so it can execute swaps without ever touching a raw private key.
▸A team builds a character-driven social agent on ElizaOS, attaching plugins for a chain connector and an X account from one config file.
▸A group of agents runs as an Olas autonomous service, coordinating off-chain and registering on-chain to earn rewards for the work.
▸A developer swaps the underlying model in their framework config from one provider to another without rewriting the agent's skills or wallet setup.

Risks & Limitations

⚠Lock-in: a framework's assumptions about wallets, tools, and control flow become yours, and migrating later is costly.
⚠Weak key handling: a framework that expects a raw private key pushes real custody risk onto your agent. Check the wallet model first.
⚠Abandonment: an unmaintained framework leaves security fixes and integrations to you — verify the repo is open and active before committing.
⚠"Production-ready" is a claim. Demos hide gaps; check the receipts (open code, recent activity, real usage) before trusting a framework with funds.

Frequently Asked Questions

Is an AI agent framework the same as an AI agent?: No. A framework is the toolkit you build an agent with — a runtime plus integrations for tools, wallets, memory, and guardrails. It does nothing until you configure an agent. The agent is the specific, running thing that holds a wallet and acts. On SatoHub, frameworks are resources you build with, not agents.
What's the difference between a framework and an SDK?: An SDK is a focused library for one capability — say, executing swaps or signing transactions. A framework is broader: it runs the reasoning loop and wires SDKs in as tools, alongside wallet handling, memory, and guardrails. You often use several SDKs inside one framework.
Which agent framework should I use for an onchain agent?: It depends on the job. Coinbase AgentKit centers on onchain actions and a strong wallet model; ElizaOS on composing configurable, multi-platform agents; Olas on coordinating agent-run services. Choose on language fit, wallet model, skill ecosystem, and how actively the project is maintained.
What should I check before trusting a framework with real funds?: Look at the wallet model (scoped signers and spend limits, not raw keys), the guardrails it enforces, and whether the repo is open and active. Treat "production-ready" as a claim until the evidence — recent commits, real usage, checkable code — backs it. The Sato Score grades that kind of transparency, not safety or returns.
Do I need a framework at all?: Not strictly — you can assemble the reasoning loop, wallet, tools, and guardrails yourself. But a framework that fits your job saves weeks of plumbing and ships tested integrations. The trade-off is adopting its assumptions, so the choice is worth the same scrutiny as picking a database.