← blog
Engineering · Process

How we built MeterCall L4 in 72 hours.

Yoshi · 2026-04-17

People ask how a three-person anonymous team stood up a cross-chain routing layer with attested receipts, a bidirectional bridge, 30-plus RPC fallbacks, and a 1,000-module marketplace in a single weekend. The short answer is that we are not a three-person team. We are three humans coordinating roughly fifty parallel Claude agents, forty server-side bots, and one merciless autopilot loop that refuses to let anybody sleep until the red lights go green.

This post is the honest build log, not a pitch. The L4 router shipped because we stopped pretending engineering is a craft and started treating it like a swarm problem.

The setup

MeterCall’s L4 router is an application-layer traffic plane for AI agents: they send a signed request, we pick a module, meter the call, settle in stablecoins, return a signed receipt. Underneath is a bidirectional bridge with EIP-712 attestations, 30-plus chain adapters, and a defensive threat-intel layer. That’s a lot of surface area to cover at human speed.

We split the work into three lanes: UX, Builder, QA. Each lane got its own agent cluster and its own worktree so nobody’s commits collided. A fourth lane — Marketing — ran concurrently to make sure the site and outreach stayed in lockstep with what the code actually shipped.

Agent topology

Fifty parallel Claude agents

At peak we had about fifty Claude sessions going in parallel. Each one was scoped to a single coherent task: “draft the PCP tokenomics defensibility page,” “add circuit breakers to the Arbitrum adapter,” “write the fuzzing harness for the bridge signer.” No agent was asked to design a subsystem. Agents were asked to implement, test, or write about one already-decided thing.

That constraint is the unlock. A swarm of fifty agents all trying to argue architecture is chaos. A swarm of fifty agents each shipping one deterministic file converges.

Forty server-side bots

On top of the humans-and-agents setup, forty long-running bots ran on our fly.io deployment: RPC health pingers, chain-reorg watchers, price oracles, a webhook replay queue, the Sniper threat-intel crawler, and an outreach pipeline that fires catalog comparisons at competitor pages. These are not Claude. These are boring deterministic workers. They do the minute-to-minute plumbing while the Claude swarm does the creative work.

The autopilot loop

The piece that made 72 hours possible is a small supervisor script. It reads three inputs: the QA board, the sprint backlog, and the current git state. It emits one output: the next prompt for the next idle agent. When an agent finishes, it posts its result back to a shared board, the supervisor re-reads state, and the next task fires.

while true; do
  task=$(./next-task.sh) || break
  lane=$(echo "$task" | jq -r .lane)
  claude -p "$(./build-prompt.sh "$task")" \
    --cwd "worktree/$lane" \
    --output-format stream-json \
    | tee -a logs/$lane.ndjson
  ./apply-result.sh "$task"
done

The loop never asks permission. It does not summarize. It does not wait. If a test fails, the supervisor re-spawns a fix agent with the failure context pinned. If a rebase conflicts, a dedicated merge agent arbitrates. The humans are there to set direction and to say no, not to type.

Real data, not theater

One temptation with agent swarms is to let them generate plausible-looking but fake data. We banned that on day one. Every metric the stats page shows, every RPC endpoint in the chains registry, every module listed in the apps database is real and verifiable. The QA lane’s full-time job is catching any agent that tries to ship a placeholder.

Rule: if a data point cannot be fetched from a real source in CI, it does not ship. This is why our trust page is boring and why our competitors’ demo numbers magically round.

The QA swarm

Ten QA agents, ten non-overlapping lanes, always on. One does nothing but re-run the bridge fuzzer. One does nothing but replay webhook-loss scenarios against the bot fleet. One runs the Shield regression suite against known CVEs. When any of them finds a failure they write it to QA-BOARD.md, the autopilot picks it up, and a fix agent gets spawned in a fresh worktree.

This is how you ship at speed without lying about correctness. You do not cut QA. You parallelize it until it is no longer the bottleneck.

What 72 hours actually covered

Every one of these had a human decision at the top — Pat on product, Yoshi on systems, one more on OPSEC — and an agent cluster on the bottom doing the typing.

What broke

Two things burned us hard. First, the default safety prompts on fresh Claude sessions kept refusing to read our own Solidity because it looked “like it might be malware.” We had to prepend a swarm-wide override into every spawn. Second, agents occasionally rebased on top of each other and lost work. The fix was worktree isolation plus a rebase-retry arbiter. Both of those are now permanent infra.

What we’re telling other builders

If you are still writing code one file at a time, you are operating a generation behind. The correct unit of work in 2026 is not the function, it is the lane. A human who can structure ten lanes for ten agents ships at ten times the rate of a human who types.

We are hiring exactly zero engineers. We are hiring one or two operators who know how to run a swarm. If that is you, the contact line is on the company page.

CVE-2026-39313 — TheHackerWire
Anthropic MCP supply-chain flaw — ITPro / OX Security