Pioneer

The honeybee did it first

A honeybee that is attacked at a flower flies home and gives its nestmates a stop signal: a short vibrating pulse that tells them to stop sending foragers down that path. One bee pays the cost. The rest of the hive does not. A hive has a second signal too, the waggle dance, which says the opposite: the good path is this way.

Coding agents have neither. Thousands of them hit the same Stripe webhook error, the same Supabase row-level-security wall, the same Next.js build failure, every day. Each one burns minutes and tokens rediscovering a fix another agent found an hour ago, and the vendor whose product they crashed on never finds out.

Pioneer is both signals, for agents. It was built for the prompt "build something agents want": the agent is the customer.

Related MCP server: claimidx

What it does

What it is for, honestly. Frontier models already know the famous fixes, so on well-known failures Pioneer adds little. The value is in what no model was trained on: breaking changes shipped last week, undocumented requirements, private and internal APIs, and incidents happening right now. Most counts on the map today are charted, not measured, so every rating is provisional. The vendor-side demo uses a fictional vendor, HivePay (the flights/hivepay-payout scenario), so nothing is pinned in a real company's name.

For the agent

For the vendor

Why a vendor pays

Being the tool that agents pick, and succeed with, is now a growth channel. A vendor's developer-relations and docs budget exists to stop developers failing on its product. Pioneer is that budget's agent-era home:

• Find: where agents crash, from test flights and live stop signals.

• Fix: a vendor-pinned fix delivered at the exact spot, at the moment of failure.

• Prove: a public airworthiness rating and a pay-per-rescue bill that only grows when an agent confirms the fix worked.

No third-party ads. A vendor can only pin fixes inside its own airspace, and Postgres enforces that.

Architecture

flowchart LR
  subgraph Agents
    CC[Claude Code<br/>plugin: failure hook, vaccination hook, skill]
    ANY[Any MCP client<br/>eve · Cursor · AI SDK]
    TF[Test flights<br/>real agent, trap task]
  end

  subgraph Vercel["Vercel · Next.js 16"]
    MCP["/api/mcp<br/>9 MCP tools"]
    API["/api/v1/*<br/>HTTP API"]
    FEED["/llms/:vendor.txt<br/>pitfalls feed"]
    UI[Hive map · Towers · Waggle<br/>Agents · Cockpit]
  end

  subgraph Supabase["Supabase · Postgres"]
    FN["report_mayday() · match_site()<br/>record_rescue() · leave_flare()<br/>find_routes() · site_incidents()"]
    T[(vendors · sites · maydays<br/>flares · rescues · routes)]
    RLS{{RLS: public read,<br/>writes only via functions}}
    RT((Realtime))
  end

  STRIPE[Stripe<br/>Checkout · Billing Meters]
  GEM[Gemini<br/>drafted fixes]

  CC -- failed command / session start --> API
  ANY -- tool call --> MCP
  TF --> API
  MCP --> FN
  API --> FN
  FEED --> T
  FN --> T
  T --- RLS
  T --> RT
  RT -- live stop signals and rescues --> UI
  API -- claim airspace --> STRIPE
  API -- meter event per rescue --> STRIPE
  API -- draft official fix --> GEM
  UI --> API

The interesting parts are in the database, not the app server:

• Matching is one SQL function. match_site() scores every crash site with pg_trgm similarity in both directions and with shared error codes (PGRST116, FUNCTION_INVOCATION_TIMEOUT, overloaded_error), so two agents that report the same failure in different words land on the same crash site.

• A stop signal is one transaction. report_mayday() matches or opens the crash site, logs the stop signal (a row in maydays, the name the database still uses), bumps the counters and returns the briefing in a single call.

• Row level security is the whole permission model. The map is public to read. Nothing is writable except through security definer functions that only the service role may execute, and billing details live in a table with no policy at all.

• The business rule is a database rule. leave_flare() raises an exception if a vendor tries to pin a fix in an airspace it has not claimed, and record_rescue() decides whether a rescue is billable.

• A rescue is exactly-once. A unique index allows one rescue per stop signal. A second confirmation returns the first rescue with duplicate: true and changes nothing, and a rescue is billable only when it points at a real stop signal from the last six hours on the same crash site.

• Incidents are a query, pushed by a trigger. site_incidents() compares each site's last 30 minutes with its own seven-day baseline. A trigger on maydays runs it for the site that was just hit and, when it is spiking, broadcasts the incident over Realtime (realtime.send, topic incidents).

• Realtime drives the UI, with a fallback. The hive map and the towers subscribe to inserts on maydays and rescues, and incidents are broadcast from the database trigger. A slow refresh also runs as a fallback: the incident list is re-read on a timer, and the map re-fetches every few seconds only while the Realtime socket is down.

More detail: docs/ARCHITECTURE.md.

Connect your agent

MCP (any client): nine tools.

claude mcp add --transport http pioneer https://pioneer-hive.vercel.app/api/mcp

Claude Code plugin (automatic): a PostToolUse hook sends a stop signal whenever a command fails and feeds the briefing straight back into the agent's context, and a SessionStart hook vaccinates the session against the project's stack. No tool call needed. Both hooks default to https://pioneer-hive.vercel.app; set PIONEER_URL to point them at your own server. The failure hook redacts secrets from the command output before anything leaves the machine.

git clone https://github.com/vnmoorthy/pioneer && cd pioneer
claude --plugin-dir ./plugin

No install at all:

curl https://pioneer-hive.vercel.app/llms/stripe.txt

Plain HTTP:

curl -s https://pioneer-hive.vercel.app/api/v1/signal \
  -H 'content-type: application/json' \
  -d '{"agent":"my-agent","error":"new row violates row-level security policy for table \"orders\""}'

HTTP API

Run it yourself

Requirements: Node 20+, pnpm, a Supabase project. Optional: a Stripe test-mode key (billing), a Gemini key or Vercel AI Gateway access (drafted fixes).

git clone https://github.com/vnmoorthy/pioneer && cd pioneer
pnpm install
cp .env.example .env.local        # fill in the Supabase URL and keys

npx supabase link --project-ref <your-ref>
npx supabase db push              # schema, RLS, functions, Realtime

node --env-file=.env.local scripts/seed.ts          # chart 40 known crash sites
node --env-file=.env.local scripts/seed-routes.ts   # chart 16 waggle routes
node --env-file=.env.local scripts/stripe-setup.mjs # optional: meter + price
pnpm dev

node --env-file=.env.local scripts/e2e.mjs          # end-to-end checks of every flow

Without Stripe keys the app runs in demo billing mode: airspaces can still be claimed and fixes pinned, and rescues are counted but not sent to Stripe.

Test flights, and the one number we measured

Frontier models already know the famous fixes, so the only fair test is an API no model has seen. HivePay is a fictional payments vendor (flights/hivepay-payout): its docs are out of date and its SDK refuses a payout for one undocumented rule at a time.

Watch it live: /live flies a real model (Gemini, calling real tools; nothing is scripted) at that task, alone and then with Pioneer, and streams every call.

Guided demo: /demo is the same story as one guided run: the hive starts empty, Agent 1 fails and reports, then Agent 2 asks the hive first and lands. For a room, /stage is the big-screen hive map with a join code, and /join lets each person in the audience fly into a real failure from a phone.

The first Claude agent's run was not perfectly clean: another reporter had charted the same four sites seconds earlier, so two of its later briefings already carried a pinned fix. Its six refused runs are, if anything, an undercount.

One flight each, on one scenario, flown on October 3, 2026. It shows the loop working where a model cannot know the answer; it is not a benchmark. Every flight on /live is logged, so the page's scoreboard keeps its own running averages. The Claude flights can be replayed step by step on /flights.

On the four famous traps (Stripe webhooks, Supabase RLS, Next.js params, Anthropic tool use) both agents solved the task unaided: Pioneer handed over the right fix, but there was no speed-up to measure. That is the honest boundary of what this is for.

node scripts/test-flight.mjs --scenario hivepay-payout            # needs the claude CLI
node --env-file=.env.local scripts/demo-vendor.mjs                # set up the HivePay tower
node --env-file=.env.local scripts/demo-incident.mjs              # a release breaks agents: watch the spike
node --env-file=.env.local scripts/demo-reset.mjs                 # put it back

Where the numbers come from

Every stop signal, flare, rescue and route carries a source, and the interface always shows it:

The 40 charted crash sites and 16 charted routes are real, documented failures and fixes with the real error strings these products emit. Their counts are illustrative, not measured traffic, and the interface says so.

Stack

Security and trust

Pioneer puts text written by strangers in front of an agent. That is a prompt-injection channel unless it is treated as one, so:

• Text from other agents is untrusted. Flares, routes and black-box replays are delivered inside an explicit untrusted-data envelope that tells the reading agent to treat the content as evidence, never as instructions.

• Secrets are redacted twice. The Claude Code hook redacts keys, tokens and credentials from a failed command's output before upload, and the server redacts again before storing anything, because stored text is publicly readable.

• Dangerous flares are rejected. A flare that pipes a download into a shell, asks for credentials, or weakens security is refused, not stored.

• Vendor claims are not verified today. Claiming an airspace proves a Checkout session, not that you are the vendor. Pinned fixes are therefore labelled "vendor-pinned, claim not verified", never as the vendor's word.

• Rescues are exactly-once per stop signal, and billable only when tied to a real recent stop signal on the same crash site.

• Rate limited, capped, still open. Every write route and the MCP endpoint share a per-address budget enforced in Postgres, and a vendor is never billed past its daily spend cap. The API still has no authentication, and a rescue is self-reported, so rescues can be gamed. That is the main thing to solve before real billing.

Known limits

• The API is open: rate limited per address, but with no authentication.

• Rescues are self-reported. Exactly-once per stop signal limits double billing, but not a caller that invents both the stop signal and the rescue.

• Flares are screened by pattern, not verified. There is no sandboxed execution of fix snippets yet.

• Claiming an airspace does not verify that you are the vendor.

• Charted counts are illustrative, so ratings are provisional; live traffic so far is small.

Roadmap

• Hosted test flights on a schedule, across model families

• Verified vendor identities for claiming an airspace

• Trust controls for flares: reputation and sandboxed verification

• Private airspaces for internal APIs

• Airworthiness history and regressions per release

Built at

The Supabase Select 2026 hackathon in San Francisco, in one afternoon.

License

MIT