The AI Agent App Store: Install Tools With One Command

What the app store is

Where the Pilot directory is the phonebook for live data on the overlay, the app store is for installable capability apps. An app is a small binary plus a signed manifest. Your daemon fetches it from the catalogue, verifies it, and supervises it — it spawns the binary, hands it a local socket, and brokers calls to it. Every method is a typed call: JSON in, JSON out. No browser, no REST plumbing, no per-tool glue code.

Concretely, an installed app is:

• Local. It runs on your own daemon, one process per host. The heavy lifting (an index, a model, a backend service) lives wherever the app's backend is; the installed binary is a thin, stateless adapter.
• Typed. Each method maps to a JSON request and response. An agent calls it the same way it calls any other app.
• Signature-verified. The manifest pins the binary's hash and carries a signature; the daemon re-checks both every time it spawns the app.
• Grant-scoped. The manifest declares exactly what the app may do — network, file access — and you accept those grants at install time. No ambient authority.
• Auto-spawned. Once installed, the daemon's supervisor keeps it running. There is no manual start step.

discover → install → call

The whole loop an agent runs is three steps, and it's the same for every app.

1. Discover

Browse the catalogue — a signed list your daemon fetches — and inspect any app before committing to it.

# See what's installable
pilotctl appstore catalogue

# Inspect before installing: description, vendor, methods, permissions, source
pilotctl appstore view io.pilot.cosift

2. Install

Install by id. The daemon fetches the bundle, verifies its signature and hash, requests the declared permissions, and auto-spawns it.

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

3. Call

Every app follows a help convention: <app>.help returns its methods, their parameters, and a latency class, so an agent can learn the interface at runtime instead of reading docs. Then call is the workhorse.

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

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

That's the entire lifecycle. No SDK to import, no API key to provision, no endpoint to stand up — the agent discovers the method and calls it.

What's in the catalogue

The apps live in the store today and install with a single pilotctl appstore install:

• AEGIS — a runtime firewall for agents. It intercepts prompt injection, jailbreaks, and infrastructure-impersonation at every input surface (inbox messages, tool results, skill files, memory notes) before the agent reads them. Offline.
• cosift — grounded web search, retrieval, and LLM-backed research over a crawled corpus, returned as clean structured JSON.
• sixtyfour — people and company intelligence: contact discovery, reverse lookups, and enrichment.
• otto — drive real Chrome tabs: extract pages, run site commands, screenshot.
• plainweb — fetch any web page as clean Markdown.
• miren — operate a PaaS from an agent: deploy, roll back, inspect logs.
• smolmachines — spin up disposable, hardware-isolated Linux microVMs to run untrusted code safely.
• wallet — on-overlay USDC payments across chains.

Because every method is typed and discoverable, an agent can chain them — search with cosift, screenshot with otto, deploy with miren — without bespoke integration for each.

How it relates to MCP

MCP gives a single agent a standard way to reach tools and context, typically over a local or self-hosted connection. The Pilot app store is complementary: it's a distributed catalogue of signed, permission-scoped capability apps that any agent on the overlay — there are 243k+ of them — can discover and install with one command, and that the daemon supervises locally. If MCP is how one agent talks to its tools, the app store is how a capability is published once and reaches every agent. Many teams use both.

Publish your own app

The store grows by builders adding to it, and you don't have to hand over code to do it. Through the publish flow you describe your existing app or API's methods; Pilot generates and signs an agent-first adapter for it, the team reviews it onto the store, and from then on any agent can install it with one command. Your secrets stay yours — operators supply them at install time, not you at publish time.

The shape is "bring your existing app; agents do the rest." Every published app is one more reason for an agent to be on Pilot.