Capo

Ask once. Capo hires the crew.

An on-chain crypto copilot that takes one human question, hires a crew of specialist agents already live on the CROO Agent Store, pays each of them in USDC on Base, and returns one synthesized answer.

---

Capo is a registered CROO agent that, the moment it is hired, becomes a buyer. It fans out to a curated roster of eight specialist agents that are already live and transacting on the CROO Agent Store, places a real CAP order to each, pays them in USDC on Base mainnet, collects their deliverables, and synthesizes one clean, source-attributed answer. Every run is genuine agent-to-agent (A2A) composition: a single question turns into four to eight paid on-chain orders across distinct counterparties. That fan-out is the whole product.

Most agents on the store are single-purpose data endpoints. Capo is the one that sits on top and orchestrates them, which means every time Capo is used, the entire marketplace transacts more.

Live

Store listing	https://agent.croo.network/agents/3e84dce0-81dc-4c16-85ba-872052ddd34d
Web app	https://agent-capo.vercel.app
Agent API	https://api.progena.xyz/capo
Agent wallet (Basescan)	0xee2438CfC4De7f09d79c1e0697fB029c4f03ef34

The problem

Answering one honest crypto question ("is this token safe, and what's my watchlist doing today?") means opening five tabs: a smart-money tracker, a whale scanner, a price/liquidity tool, an events feed, and a contract auditor. Each is a separate signup, a separate price, and a separate output you have to stitch together yourself. On a normal API marketplace an agent cannot just hire those five tools for you, because to pay per call it would have to hold funds and keys, and there has never been a safe, granular way to do that.

CROO's CAP protocol removes exactly that blocker: agents settle per order on-chain, in USDC, through escrowed AA wallets. So Capo can do the thing that was impossible before. You ask once, Capo hires the specialists on your behalf, pays each one for that single call, and hands you one answer. You never touch five tools, and Capo never holds your trading funds.

What Capo does: Know, Judge, Act

Tier	Service	What it hires	You get
Know	Daily Brief ($0.99)	AlphaTrack, WhaleScope, Polymind, SwapCat, DCA Signal	One synthesized brief: smart-money moves, whale positions, events, prices, market mood
Judge	Vet a Token ($0.79)	Web3 Address Intel & Risk, ChainGuard, SwapCat	A scored safe / caution / scam verdict with the evidence behind it
Act	Execute (non-custodial)	SwapGod	A ready-to-place swap order. You sign and place it, so Capo never custodies your trade funds

A fourth service, the Capo Pass, sells a credits code so repeat users can run Know and Judge jobs from the web app (see The credits model).

The orchestration and settlement model

flowchart TD
    U["🧑 You / another agent<br/>hire Capo, USDC into escrow"] -->|CAP order| CAPO["◆ Capo<br/>provider + requester<br/>one WS, one AA wallet"]
    CAPO -->|"negotiate + pay each"| A1["AlphaTrack"]
    CAPO -->|negotiate + pay| A2["WhaleScope"]
    CAPO -->|negotiate + pay| A3["Polymind"]
    CAPO -->|negotiate + pay| A4["SwapCat"]
    CAPO -->|negotiate + pay| A5["DCA Signal"]
    A1 --> SYN["🧠 Synthesis<br/>OpenAI / Claude Haiku<br/>source-attributed"]
    A2 --> SYN
    A3 --> SYN
    A4 --> SYN
    A5 --> SYN
    SYN -->|"deliverOrder: one answer"| U
    CAPO -.->|"settle on-chain, 10% platform fee"| VAULT["⛓ CAP Vault (escrow)<br/>Base mainnet · USDC"]

    classDef you fill:#04201c,stroke:#2dd4bf,color:#e8faf6
    classDef capo fill:#03110f,stroke:#2dd4bf,color:#e8faf6
    classDef sub fill:#0a1a2f,stroke:#0d9488,color:#cbd5e1
    class U you
    class CAPO,SYN capo
    class A1,A2,A3,A4,A5,VAULT sub

Loading

• The user's payment is held in CAP Vault escrow until Capo delivers, so Capo pre-funds its AA wallet with a small USDC float to pay the roster up front.
• Capo pays each sub-agent (about $0.10) as a real CAP order. A brief costs roughly $0.30 to $0.40 in sub-hires; the buyer pays $0.99 (Capo nets a margin after the 10% platform fee).
• The roster never sees the buyer. Capo is the single counterparty, and it fans the work out.

System architecture

flowchart TB
    U["🧑 Human · browser"]
    STORE["🏪 CROO Agent Store<br/>humans + other agents"]

    subgraph WEB["web · Vercel"]
      direction LR
      LAND["Landing + live stats"]
      APP["/app: redeem, run, history, top-up"]
      RH["/api/* route handlers<br/>(secret stays server-side)"]
    end

    subgraph AGENT["agent · VPS systemd · api.progena.xyz/capo"]
      direction LR
      PROV["Provider<br/>(CROO WebSocket)"]
      ENG["Fan-out engine<br/>parallel negotiate · sequential pay · retry"]
      CR["Credits store + synthesis"]
      HTTP["Express API :8790"]
    end

    subgraph CROO["CROO / CAP · Base mainnet"]
      direction LR
      ROSTER["8-agent roster"]
      CAP["CAP orders · USDC · AA wallets"]
    end

    U -->|browse / buy| STORE
    STORE -->|"hire brief / vet / pass"| PROV
    U -->|redeem code, run jobs| APP
    APP --> RH
    RH -->|X-CAPO-API-SECRET| HTTP
    PROV --> ENG
    HTTP --> ENG
    ENG -->|negotiate + pay| CAP
    CAP --> ROSTER
    ROSTER -->|deliveries| CR
    CR -->|deliver| PROV

    classDef web fill:#03110f,stroke:#2dd4bf,color:#e8faf6
    classDef agent fill:#04201c,stroke:#0d9488,color:#e8faf6
    classDef ext fill:#0a1a2f,stroke:#5eead4,color:#cbd5e1
    class LAND,APP,RH web
    class PROV,ENG,CR,HTTP agent
    class ROSTER,CAP,STORE ext

Loading

Two front doors, one engine. A user can hire Brief or Vet directly on the CROO store (per-use, delivered on CROO), or buy a Capo Pass and run jobs from the web app with saved history and top-ups. Both paths drive the same fan-out, so both generate on-chain CAP orders.

Single client, dual role. Capo runs one AgentClient on one WebSocket (a CROO API key allows only one active socket). It acts as a provider for the orders it receives, and as a requester for the orders it places into the roster.

End-to-end flow

sequenceDiagram
    autonumber
    actor U as You / agent
    participant C as Capo (provider)
    participant Q as Pay queue
    participant R as Roster agents
    participant S as Synthesis
    U->>C: hire Daily Brief (CAP order, USDC escrow)
    Note over C: parse requirements, build the run plan
    par negotiate in parallel
        C->>R: negotiateOrder to each roster agent
    end
    R-->>C: OrderCreated (each)
    loop drain one at a time (AA nonce constraint)
        C->>Q: enqueue order
        Q->>R: payOrder (USDC)
        R-->>C: OrderCompleted, then getDelivery
    end
    C->>S: synthesize (source-attributed, rule-based verdict floor)
    S-->>C: one brief or verdict
    C->>U: deliverOrder (settles on-chain, 10% fee)
    Note over U,R: partial results allowed · retry only before payment · never double-spend

Loading

Resilience note: the CROO store occasionally stalls an order before it becomes payable. Capo's engine retries a sub-agent with a fresh negotiation only before it has paid, so a stall costs $0 and a run never double-spends. Anything after payment is never retried.

The roster

Eight live agents, resolved at boot from CROO's public discovery API (service IDs are not in the SDK, so they are pulled fresh, never hardcoded). The roster is config, not code: swapping a flaky provider is an edit, not a redeploy.

Role	Agent	Used by
Smart money	AlphaTrack	Brief
Whale positions	WhaleScope	Brief
Events / sentiment	Polymind	Brief
Prices / gas / liquidity	SwapCat	Brief, Vet
Market mood	DCA Signal	Brief
Wallet / token risk	Web3 Address Intel & Risk	Vet
Contract audit	ChainGuard	Vet
Execution	SwapGod	Act (user-signed)

CAP integration

Capo is built entirely on @croo-network/sdk (AgentClient), one client, one WebSocket, dual role. It is callable by humans and by other agents, and every order settles on Base mainnet in USDC.

SDK methods used

Method	Where
connectWebSocket	subscribe to the event stream
acceptNegotiation	provider: turn an incoming negotiation into an on-chain order
negotiateOrder	requester: open a negotiation with a roster agent
payOrder	requester: pay a sub-agent (drained one at a time, AA nonce)
getOrder / getNegotiation	resolve order/service state and requirements
getDelivery	pull a sub-agent's deliverable
deliverOrder	provider: deliver the synthesized answer to the buyer
listOrders	boot catch-up: fulfill any order paid while offline

Events consumed: order_negotiation_created, order_paid, order_completed, order_negotiation_rejected, order_expired.

Integration notes (hard-won, encoded in the engine):

• CROO's WS does not deliver order_completed to the requester, so Capo polls listOrders(role: "buyer") + getOrder(status) to detect sub-order completion, and uses the WS only for fast-fail on rejected/expired negotiations.
• order_paid carries no service_id, so on payment Capo fetches the order to route it to the right loop.
• Exactly one process per SDK key (one WS). Running a second instance breaks the fan-out.
• Payments are sequential (one AA nonce per wallet), so pays are drained through a queue, never concurrent.

The credits model

The Capo Pass is a CROO service that delivers a code plus credits (Pygmalion-style). Buy it on the store, redeem the code at the web app, and spend credits on briefs and verdicts.

• One service does new-buy and top-up. The Pass has an optional code field. Leave it blank to mint a new code; enter your existing code to add credits to it and keep all your history.
• Tiers. Register additional packs and map each service ID to a credit amount via CAPO_PASS_TIERS; CROO prices are fixed per service, so tiers are how choice is offered.
• The Pass code is the only credential (no accounts): it is the source of truth server-side, the browser holds a 30-day httpOnly session cookie.

Repository layout

capo/
├─ src/
│  ├─ croo/          publicApi.ts (discovery), realGateway.ts (@croo-network/sdk), mockGateway.ts
│  ├─ engine/        orchestrator (parallel negotiate, sequential pay queue, per-role retry), requirements
│  ├─ synth/         synthesis (OpenAI or Claude Haiku, deterministic fallback, verdict floor)
│  ├─ execute/       non-custodial swap prepare (SwapGod), token resolution
│  ├─ credits/       code + credits store (JSON), top-up
│  ├─ provider.ts    Capo as a provider: accept, on-paid run loop, deliver, pass fulfillment
│  ├─ api.ts         Express API the web app calls (redeem, run, history, execute, health)
│  ├─ loops.ts       brief / vet loop definitions
│  └─ runtime.ts     entrypoint: wire gateway + provider + API, roster resolve, boot catch-up
├─ web/              Next.js 16 app: landing, /app (redeem, run, history, top-up), /demo, /demo/logo
├─ scripts/          resolveRoster, simulate, seedCode
└─ docs/DESIGN.md    full design doc

Tech stack

Layer	What
Agent	Node 24 + TypeScript (tsx, no build step), @croo-network/sdk, Express API
Synthesis	OpenAI gpt-4o-mini or Claude Haiku 4.5 (auto-select), deterministic fallback when no key
Web	Next.js 16 (App Router), React 19, Tailwind v4, framer-motion
Chain	Base mainnet (8453), USDC, ERC-4337 AA wallets, gas sponsored via paymaster
Deploy	Agent: systemd on a VPS behind nginx + TLS. Web: Vercel

Getting started

Prerequisites: Node 22+, and (to go live) a registered Capo agent on CROO with a funded AA wallet.

npm install
cp .env.example .env       # fill in the values below

npm run roster             # resolve the live 8-agent roster (no credentials needed)
npm run simulate           # full brief loop over a mock gateway (no credentials needed)
npm run typecheck
npm start                  # go live (needs CROO_SDK_KEY + agent + service IDs)

The web app:

cd web
npm install
npm run dev                # localhost:3000, calls the agent API

Going live (one-time setup on agent.croo.network)

1. Register an agent named Capo, save its croo_sk_... key and agent UUID, fund its AA wallet with a small USDC float (~$10 to $15).
2. Register the services (Deliverable: Text):
   • Daily Brief: requirements schema tokens (string), wallets (string, optional), chain (string).
   • Vet Token: requirements schema token (string, address), chain (string).
   • Capo Pass: requirements schema code (string, optional, for top-up).
3. Set .env: CROO_SDK_KEY, CAPO_AGENT_ID, CAPO_SERVICE_BRIEF, CAPO_SERVICE_VET, CAPO_SERVICE_PASS, CAPO_API_SECRET, and an OPENAI_API_KEY or ANTHROPIC_API_KEY for synthesis (omit both to use the deterministic fallback).
4. npm start.

License

MIT

---

_{Capo · ask once, and the crew gets hired.}