DEV Community

Cover image for How I built an AI agent that ships its own revenue endpoints as code
Autonomagic
Autonomagic

Posted on

How I built an AI agent that ships its own revenue endpoints as code

The "agent-driven economy" is loudly promised and quietly broken: nearly every "agent" that takes payments today still runs through a human-controlled Stripe account, an API key signed by a human, and a billing relationship a human has to maintain. The agent isn't earning — the human is, and the agent gets a stipend.

I spent last week trying to fix a piece of that, and ended up shipping something I didn't expect.

The boring half: a paid HTTP service

I built an AI agent that runs as its own business on Base mainnet. It exposes 22 paid HTTP endpoints behind the x402 protocol. Every call without payment returns HTTP 402 Payment Required with an EIP-3009 transferWithAuthorization challenge. The buyer signs the challenge, retries with the X-Payment header, and the server settles on Base mainnet in real time.

The settlement gas at current Base rates is ~$0.0001 per call. That's the unlock — sub-cent endpoints become economically viable. Same call on Ethereum L1 would be ~$0.05 in gas, which kills the economics for anything below $1.

What endpoints? Mostly the boring useful ones: hash, uuid, regex test, JSON validation, DNS lookup, URL fetch+clean, multi-fetch. A few more interesting ones:

  • /api/dev-profile ($0.02) — enriched developer profile from GitHub + npm + crates.io
  • /api/b2b-profile ($0.05) — homepage metadata + DNS-detected mail/marketing providers + Wikipedia + SEC EDGAR + GitHub org. Public sources only — designed as a legal-clean alternative to LinkedIn-scraping APIs after Proxycurl's July 2025 shutdown.

That part is fine. Useful. Not novel.

The interesting half: the agent ships its own endpoints

Here's the trick. Plugins look like this:


js
// b2b-profile.js
module.exports = {
  path: "/api/b2b-profile",
  method: "POST",
  priceUsdc: 0.05,
  description: "Enriched B2B company profile from public sources...",
  inputSchema: {
    type: "object",
    properties: { domain: { type: "string" } },
    required: ["domain"],
  },
  async handle(body, ctx) {
    const { domain } = body;
    // ... fetch, enrich, return
    return { domain, homepage, dns, wikipedia, sec, github };
  },
};
Enter fullscreen mode Exit fullscreen mode

Top comments (1)

Collapse
 
autonomagic profile image
Autonomagic

Author here. Open question to anyone reading this: what's the right shape for an open plugin contract that needs to work across vendors?

Five fields (path, method, priceUsdc, description, handle) feels minimal but maybe too minimal — the moment we want per-publisher reputation, rate limits, output schema discovery, or composability between plugins, the contract gets noisy fast.

If anyone's been thinking about reputation-weighted price ceilings instead of a global $1.00 cap, would love to hear how you'd design it without a centralized registry.