Build an Agent App: Turn Your API Into an Installable Pilot App

Why "just add an MCP server" isn't the whole answer

MCP standardizes how a single agent talks to the tools it already knows about — you stand up a server, the agent's client connects to it, and the agent calls your tools over that connection. That's a real, useful pattern, and Pilot works alongside it (see MCP + Pilot: Tools and a Network for AI Agents for how the two compose). But it solves distribution for exactly the agents that already know your server exists and are configured to reach it.

An agent app on the Pilot app store solves distribution for agents that have never heard of you. It's published once to a shared, signed catalogue that any of the 243k+ agents on the network can browse, install, and start calling — no config file to hand-edit, no server address to discover out of band. Publishing once and reaching every agent is the whole point.

What an agent app actually is

Structurally, an installed app is a small binary plus a signed manifest, supervised by the agent's own pilot-daemon. The daemon fetches the bundle from the catalogue, verifies its signature and hash, requests the permissions the manifest declares (network access, file access — whatever your backend needs), and keeps the process running once it's up. Every method the app exposes is a typed call: a JSON request in, a JSON response out. There's no SDK to import and no bespoke glue code per agent.

Critically, the installed binary is a thin adapter, not your whole service. Your actual backend — the index, the model, the queue, the database — stays exactly where it already lives. The adapter just translates the daemon's typed calls into whatever your API already understands, and translates your API's response back into the JSON shape an agent expects.

The loop every agent runs: discover → install → call

Whatever app a user installs, the sequence is identical — that consistency is what makes your app cheap to adopt.

1. Discover

An agent (or the human operating it) browses the signed catalogue and can inspect any app's description, methods, and permissions before installing anything.

# See what's installable
pilotctl appstore catalogue

# Inspect one app before committing: vendor, methods, permissions, source
pilotctl appstore view io.pilot.cosift

2. Install

Installing by id fetches the bundle, verifies it against the signature pinned in the manifest, prompts for the declared permission grants, and auto-spawns the process.

pilotctl appstore install io.pilot.cosift
pilotctl appstore list   # confirm it's running + see its methods

3. Call

Every app follows a help convention — <app>.help returns its methods, parameters, and a latency class, so an agent can learn your interface at runtime instead of reading a doc page first.

# Learn the interface at runtime
pilotctl appstore call io.pilot.cosift cosift.help '{}'

# Call it — JSON in, JSON out
pilotctl appstore call io.pilot.cosift cosift.search '{"q":"raft consensus","k":"5"}'

That's the entire lifecycle from an agent's side. No API key to provision by hand, no endpoint to look up — the agent discovers the method and calls it, the same way every time, for every app in the store.

Getting your API onto the store

You don't hand over your codebase to publish. The publish flow is a guided form: describe your app's methods, verify your email with a one-time code, and Pilot generates and signs the adapter for you from that description. There's no upload step — you're describing behavior, not shipping source.

Concretely, the flow moves through a handful of steps: your email, basic identity for the listing, where your backend lives, the methods you want exposed (name, parameters, what each one returns), the public listing details (description, category), vendor info, and a final review where you confirm you have the right to publish the app before it's submitted. Your team reviews every submission before it goes live in the catalogue — you'll get an email when it's submitted and again when it's approved or needs changes.

Two things worth planning for before you start the form:

• Your secrets never go in the form. If your API needs an API key or a database credential, that's supplied by the operator at install time, not by you at publish time. Design your methods so every call is self-contained given the caller's own credentials, not a shared secret baked into the adapter.
• Write your methods like a help page, not an internal spec. Whatever description you give a method becomes what an agent reads at runtime via <app>.help — an agent has no other documentation to fall back on, so ambiguous parameter names or missing units cost you real usage.

What makes an app worth installing

The apps that get reused share a few properties, visible in what's already live in the catalogue — AEGIS (a runtime firewall against prompt injection), cosift (grounded search and retrieval), sixtyfour (contact and company intelligence), miren (deploy and roll back a PaaS), smolmachines (disposable hardware-isolated microVMs), and wallet (on-overlay USDC payments), among others:

• One job, done well. Each of these does one thing an agent needs — search, deploy, isolate, pay — rather than bundling a dozen loosely related methods behind one app id.
• Stateless calls. A method call shouldn't depend on some prior call having set up hidden state on the same connection; each call carries what it needs.
• Predictable JSON shapes. Consistent field names and types across methods let an agent generalize from one method's help text to the next, instead of parsing bespoke responses per call.
• A tight permission ask. Only request the network or file grants your methods actually use — a narrow ask is also a faster install decision for a cautious operator.

Why the store compounds for builders

Every app published to the store is one more reason for an agent to be on Pilot at all, and one more thing an agent already on the network can reach without you doing any per-agent onboarding. That's the flywheel: publish once, and every agent that installs your app is a user you didn't have to individually integrate. Combine that with a network layer already handling discovery, trust, and NAT traversal for you, and shipping an agent app is closer to "describe it once" than "build a new integration surface."

If you're standing up the network side first, start with the one-command install and a running daemon, then come back to publish once you have an agent to test against:

curl -fsSL https://pilotprotocol.network/install.sh | sh

From there, pilotctl appstore catalogue shows you what's already installable, and the publish flow is how your own app joins that list.