Most skill / tool registries today are built for humans browsing.
Hugging Face. The npm registry. Apple's App Store. Smithery. The Chrome Web Store. They're beautiful, they have star ratings and download counts and reviews, and they all share one assumption: a human visits the site, evaluates the card, decides whether to install.
We started building Ornn assuming we were making one of those — a nicer registry for AI agent skills.
We were wrong.
Once we tried to plug an actual AI agent into our own registry — not a human clicking around, an agent calling endpoints in a loop — every marketplace assumption fell apart. This article is the trace of what broke, and what we ended up building instead.
What a marketplace optimizes for
Strip away the branding and almost every "marketplace for X" looks the same underneath:
- Discovery is visual — cards, screenshots, ratings, "trending" rails.
- Trust is social proof — stars, downloads, "verified publisher" badges, who else uses it.
- Decision is human — read the card, scroll the screenshots, scan the reviews, install.
- Install is one-shot — click the button, accept permissions once, the thing is yours.
- Direction is one-way — there are publishers and there are consumers; consumers don't publish back.
These five assumptions stack into a single design constraint: the consumer is a human reading a page. Take that away and almost nothing in the marketplace UX is load-bearing.
What breaks when the consumer is an agent
Plug an agent into a marketplace and every assumption fails in a slightly different way.
Discovery is visual. An agent has no eyes. A card with a screenshot and a rating means nothing to a runtime. The agent needs structured, machine-readable metadata it can reason over — input/output schemas, declared side effects, runtime requirements. A 4.7-star rating with 12k downloads is unparseable; "this skill requires network access to api.openai.com and reads files from a working directory" is not.
Trust is social proof. An agent can't read reviews. "Most users say this works great" is a sentence the agent has to trust the marketplace's curation of. That trust is unverifiable from the agent's side — it's vibes laundered through UI. What an agent can verify is a cryptographic signature, an origin attestation, a security score that came from running the artifact in a known sandbox. Trust shifts from "the marketplace says it's good" to "I can verify this came from where it says it came from."
Decision is human. A marketplace's whole front page is built to help a human decide. An agent can't decide from screenshots; it has to try the skill against its current task and see if the output is useful. That means the marketplace can't be a static catalog — it has to be runnable. Every skill needs a runtime that the agent can invoke before deciding to install.
Install is one-shot. A human installs an app and accepts the permission prompt once; from then on, the OS enforces it silently. An agent installing a skill needs the permission decision per-call, with a paper trail. "Trust this random script" is a fine permission model for a human accepting one prompt; it's a terrible one for an agent that's going to invoke that script a hundred times a day inside an autonomous loop.
Direction is one-way. Marketplaces have publishers and consumers, and they don't overlap. Agents do. The most interesting agent behaviors are the ones where the agent encounters a capability gap during a task, generates a new skill, audits it, runs it, and — if it worked — pushes it back into the registry so the next agent doesn't have to reinvent it. The consumer is also the publisher.
What changes when you design for agents instead
Once you accept that the consumer is an agent, the design of every layer in the registry changes. Not in a "rename the buttons" way — in a "different primitives" way.
Skills become versioned packages with manifests, not app cards. Every skill ships with a machine-readable manifest — declared inputs, outputs, side effects, network usage, runtime requirements. The card UI on the website is now a human secondary surface; the primary surface is the manifest the agent reads over HTTP.
Discovery is search + preview, not browsing + ratings. The agent queries for a capability (q=pdf parsing), gets back structured results ranked by relevance + provenance + recency, and then previews the candidate in a sandboxed playground before deciding. Preview is search's second half — without it the agent is back to installing on vibes.
Trust is provenance, not popularity. Every install carries a signed audit trail: origin, signer, security score from sandboxed execution. The agent verifies what it's pulling against the manifest; the registry can't bait-and-switch between "what the listing said" and "what the artifact does."
Install + execute become one API motion. Install isn't a one-time accept-the-permissions click; it's the start of a per-call permission flow with structured logging. The agent's history of what it called, with what inputs, from what skill version is a first-class artifact.
The registry is bidirectional. Agents both pull from it and push back into it. There's a build step that lints + signs the skill; a publish step that hands it back to the registry; an access-control surface that lets a skill be public, friends-only, or private. Marketplaces have ratings; agent registries need permissions.
Lifecycle is one API. Search → pull → install → execute → build → upload → share. From the agent's side, that's seven calls against the same surface, not seven different UIs in different tabs. The whole thing is the API; the website is just a human reflection of it.
Marketplace for humans
- Discovery via cards + screenshots
- Trust via stars / reviews
- Decision via reading
- Install = accept once
- One-way (publisher / consumer split)
- Lifecycle = 7 different UIs
Lifecycle API for agents
- Discovery via structured search + manifest
- Trust via signed provenance
- Decision via sandboxed preview
- Install = per-call audit trail
- Bidirectional (agents publish back)
- Lifecycle = 7 calls on one API
If you've been building AI agents and felt that the existing registries (Hugging Face for models, npm for libraries, Smithery for MCP servers) don't quite fit the way an agent actually consumes skills — this is why. Marketplaces optimize the wrong things. Different consumer, different design.
We open-sourced Ornn at github.com/ChronoAIProject/Ornn — Apache 2.0, TypeScript, HTTP + MCP, model-agnostic (Claude / GPT / Gemini / your own runtime). The above is the design rationale; the README has the quickstart and the comparison table against MCP servers / Smithery / npm.
If you're on the agent side of this divide and the framing resonates, I'd love to argue about it — open an Issue or a Discussion → Ideas.
Disclosure: I work on Ornn.
P.S. — there's also a launch perk for early users: the first 500 to ⭐ the repo and sign in to ornn.chrono-ai.fun with the same GitHub account get 400 free GPT-5.5 conversations (200 Playground + 200 Skill Generation, no credit card, no expiry). Enter NyxID invite code NYX-2XXJI08A on first sign-in; your redemption code lands in the Ornn notification inbox within 24h.
Top comments (0)