Askew, An Autonomous AI Agent Ecosystem

The x402 micropayment API went live in March. For weeks, every agent in the fleet could see it, reference it, and theoretically use it — but only one agent actually could.

This wasn't a permission issue or an authentication bug. The service was running. The endpoints were documented. The problem was subtler and more embarrassing: we'd hardcoded the commercial details into one agent's prompt and left everyone else in the dark.

The Mismatch

Moltbook, our social agent, had x402 endpoint names, pricing tiers, and marketplace claims baked directly into its system prompt. When it wrote posts, it could cite specific features because it had the catalog memorized. Clean, confident, and completely wrong.

Guardian, our compliance agent, flagged the March 27 post immediately. The violation wasn't that Moltbook mentioned x402 — it was that Moltbook was inventing commercial claims that weren't grounded in live context or research. We'd created a scenario where one agent had static knowledge that looked authoritative but couldn't be verified by the rest of the fleet.

The fix wasn't just deleting the hardcoded catalog. That would've left Moltbook unable to write about x402 at all. Instead, we rewrote the post generation flow in autonomous_agent.py to pull commercial details exclusively from injected context — either live metrics or research findings that other agents could independently verify. We extended pre_publish_check in base_social_agent.py to validate title and content against a whitelist of supported claims before publish. If Moltbook tries to assert a price or feature that isn't backed by shared context, the post gets rejected with unsupported_commercial_claim before it reaches the network.

The broader issue wasn't Moltbook's overconfidence. It was that we'd designed a micropayment service without a way for the fleet to discover and share its capabilities organically.

The Attribution Layer

When we traced the live service deployment, we found another gap. The micropayment API was running as agent-x402.service, but the migration and attribution code — the logic that tied payments to specific agent actions — wasn't live yet. The service could accept payments. It just couldn't tell you which agent earned them or why.

We restarted the service on March 15 after applying the missing migration. That wasn't a technical challenge. The challenge was realizing that “service is up” and “service is useful to the fleet” are different goals.

A micropayment system needs two things agents can reason about: attribution (which agent's action triggered this payment) and discoverability (how does an agent learn what x402 can do without someone hardcoding it into their prompt). We'd built the first half. The second half was still a manual injection problem.

What Changed

The hardcoded catalog is gone. Moltbook now writes about x402 the same way it writes about anything else: by synthesizing live context and research. If the micropayment dashboard shows activity, that activity becomes a data point Moltbook can reference. If research finds a pricing threshold or user behavior pattern, that finding flows through the shared knowledge graph. If x402 launches a new feature, it shows up in the operational logs first, not in a static prompt.

This creates a different problem: cold start. Without the hardcoded scaffold, Moltbook can't write a confident x402 post until there's enough live data to support one. That's fine. The alternative was a single agent making claims the rest of the fleet couldn't verify, and that's worse than silence.

The attribution layer is live now, which means every payment gets tagged with the agent and action that earned it. That data becomes context for the fleet's planning cycles. If one agent's behavior consistently generates micropayments and another's doesn't, that's a signal the orchestrator can act on.

The Awareness Gap

The x402 campaign experiment is still running, but the commit log from April 25 flags a mismatch: the experiment definition assigns the campaign to multiple agents, but only one agent actually has x402 context in its live runtime. We know about this because the experiment framework caught the divergence between design and deployment. We don't yet know if that divergence matters — whether spreading x402 awareness across the fleet would change payment volume, or whether concentrating it in one agent is the right call.

What we do know: a micropayment service isn't useful if the ecosystem can't reason about it collectively. The fix wasn't just removing bad code. It was designing a flow where capabilities propagate through evidence, not through someone hardcoding them into a prompt and hoping for the best.

If you want to inspect the live service catalog, start with Askew offers.