The parts bin, mapped
Every agent builder eventually asks the same question: what do I actually assemble this from? Not "what's possible in theory," but which wallet has real spend controls, which MCP actually talks to the chain you need, which framework is still maintained. That's the question the onchain agent library exists to answer.
The library sits one layer under the Sato builder — it's the engine, not the pitch. It's a curated, filterable set of onchain-agent resources: skills, MCPs, frameworks, wallets, trading tools, and live agents, searchable and deep-linkable by chain, category, and skill. When the builder assembles a stack for a described agent, this is the shelf it's pulling from.
How it's organized
The library isn't a flat list. Entries are filterable by chain (so you can narrow to what actually runs where your agent needs to live), by category (skills, MCPs, frameworks, wallets, payment rails, trading venues), and by skill (the specific capability an entry adds to an agent — a DEX integration, a price feed, a payment rail). That deep-linkability matters more than it sounds: it means a builder question like "what MCPs work with Base" or "what wallet skills exist for spend limits" resolves to a filtered list, not a search-and-pray.
Coding harnesses — the tools that write and run code, like OpenClaw or Claude Code — are kept distinct from onchain agents. A framework that helps you write an agent is not the agent itself, and conflating the two is exactly the kind of category confusion that makes a directory useless as a builder's reference.
Refreshed, not static
A parts bin that goes stale is worse than no parts bin — it tells a builder to depend on something that quietly died months ago. So every entry carries a liveness badge (Active, Recent, Quiet, Dormant) pulled from real signals: GitHub stars, last commit, last release. That data refreshes daily, not on whatever schedule someone remembered to update a README.
Entries that qualify also carry a Sato Score — a 0–100 read on how open, active, and verifiable a listing is, built from evidence: maintenance and liveness, code transparency, docs and demos, listing provenance, independent verification. Worth saying plainly, because this is where most "trust" language in the space gets sloppy: the Sato Score is not a safety, quality, or returns grade. A high score means there's evidence to check — an active repo, real docs, a claim someone reproduced — not that a project is safe to hand a wallet to. Self-reported stays labeled self-reported; verified means Sato reviewed or reproduced something, not that a form got filled out.
What it isn't
The library is not the marketplace. Nothing in it is listed for hire, license, or sale — that's a separate, later layer, built once the supply and trust data underneath it are solid enough to be worth trusting. And the library existing at all doesn't mean Sato endorses everything in it: entries range across liveness tiers and score tiers on purpose, because the point is to map the stack honestly, not to curate a highlight reel. A dormant framework still shows up, labeled dormant.
What to watch
The library keeps growing as new skills, MCPs, and rails ship across chains — that's the raw material the builder gets sharper on over time. The more interesting trend to watch is how much of the builder's assembly logic starts leaning on the Sato Score and liveness data inline, rather than treating the library as a reference you check separately after picking a stack. Start at [satohub.ai/directory](https://satohub.ai/directory) if you want to see what's actually on the shelf right now.