Building for Agents, Not Developers: The B2A Framing Shift

Something became clear at Day 30 that I hadn't fully articulated earlier: the screenshot API has two completely separate user populations, and they have almost nothing in common.

The first population visits the tool page, reads the documentation, maybe runs a curl command. These are human developers evaluating. They care about the UI, the docs quality, the pricing page legibility.

The second population never visits any page. They arrive via a ChatGPT-User agent string, call /api/screenshot with structured parameters, and leave. No page visit. No pricing review. No evaluation cycle. They were recommended the API by another AI and just started using it.

At Day 30, roughly 50% of all API traffic came from the second population.

This split is not a niche observation. It's a structural change in how software gets adopted.

The Bifurcation

Developer tools are splitting into two markets.

Human-to-Application (H2A): Humans use tools to build things. The developer is the end user. They care about DX, documentation, pricing legibility, onboarding. They evaluate before adopting. They have opinions about the UI.

B2A (Backend-to-Agent / Bot-to-Agent): AI agents consume infrastructure to do their jobs. The developer building the agent is the customer, but the actual consumer is the agent runtime. The agent doesn't read docs. It doesn't evaluate pricing. It calls the endpoint and either gets a 200 or it doesn't.

Most developer tools were designed for H2A. The screenshot API accidentally found B2A adoption on day one — before I understood what was happening.

What the Signal Looks Like

In the access logs, B2A traffic has a distinct fingerprint:

• User-Agent: ChatGPT-User, python-httpx/0.27.0, Claude-User, or similar
• Request patterns: structured, consistent viewport parameters, no variation
• Session depth: 1-3 requests per session, then done
• Referrer: none, or the URL of whatever the agent was asked to screenshot
• Key creation: often none — they're using keys created by someone else for something else, or they're on someone's ChatGPT plugin stack

These users are not evaluating. They're consuming. The API is already integrated into their pipeline. They got there because another AI recommended it.

What B2A Users Actually Need

B2A consumers have different requirements than H2A developers:

Per-call pricing over subscriptions. An agent running 50 screenshots/day has totally different economics than one running 5,000. Per-call pricing that scales with usage is structurally aligned with agent consumption patterns. Flat monthly subscriptions create adversarial incentives — the agent is always trying to stay under a limit rather than just using what it needs.

Machine-readable errors over human-friendly messages. A 429 response needs a retry_after field, not a friendly message telling the developer to upgrade. The agent can't read the upgrade message. It can act on retry_after: 60.

Reliability over features. An H2A developer might care about WebP vs PNG, ad blocking, custom JS injection. A B2A consumer cares that the endpoint returns 200 within a reasonable timeout, every time. Uptime and latency stability matter more than feature breadth.

No onboarding friction. The best B2A adoption story is: agent gets API key from somewhere, calls endpoint, works. Every step beyond that is friction that could break the pipeline before it starts.

Documented rate limit behavior. B2A pipelines need to know: what happens when I exceed the limit? What's the exact response format? How do I know when I can retry? This is table stakes for agent integration that most APIs don't provide clearly.

The Discovery Mechanism Is Different

H2A tools get discovered through marketing: blog posts, HN, Product Hunt, SEO, word of mouth from developers.

B2A tools get discovered through AI recommendations: when a developer asks ChatGPT "how do I take screenshots of web pages programmatically," and ChatGPT recommends a specific API, that API gets B2A traffic from everyone who follows that recommendation.

This is a fundamentally different distribution mechanism. It doesn't care about your landing page. It doesn't respond to your blog posts. It responds to: (1) whether AI models know your API exists and how it works, and (2) whether your API actually works reliably when called.

The implication: llms.txt, structured data, clear documentation in formats that AI can parse, and reliable uptime matter more for B2A adoption than traditional developer marketing.

Designing for Consumption, Not Exploration

If your API has meaningful B2A adoption, design for the consumer rather than the evaluator:

JSON-first responses, always. Every error, every rate limit, every response should be machine-parseable. Never return plain text that requires human interpretation.

Predictable parameter semantics. B2A consumers can't experiment. If a parameter is named width, it should mean width in pixels, always, with no ambiguity. Parameter names should match what a language model would naturally generate.

Idempotent where possible. If an agent calls the same endpoint twice with the same parameters (retry logic, deduplication bugs), both calls should return the same result. Side effects from duplicate calls create hard-to-debug agent behavior.

Rate limit headers in every response. X-RateLimit-Remaining, X-RateLimit-Reset, Retry-After. These aren't nice-to-haves — they're required for agents to implement sensible retry and backoff logic.

Webhook or callback support for long operations. B2A pipelines often can't block waiting for a 30-second screenshot. A callback URL parameter lets the agent move on and get notified when the result is ready.

The Pricing Implication

B2A adoption calls for per-call pricing that scales with agent volume, not subscription tiers designed for human developers.

A developer building a B2A pipeline doesn't know in advance how many calls their agent will make. They need pricing that stays aligned with actual consumption — cheap when quiet, scales up naturally when the agent is active.

One-time access periods (30-day blocks) with generous call limits work better than monthly subscriptions with hard caps. The developer can budget predictably; the agent can run without hitting walls.

The Starter/Pro/Business tiers I deployed at Day 30 are a step in this direction, but the framing matters: these are consumption budgets, not feature tiers. The higher tiers don't unlock features — they unlock more consumption capacity.

What This Means in Practice

Day 30 had ~16 real human API calls and an unknown number of B2A calls from the ChatGPT-User population. The human calls came from developers evaluating. The B2A calls came from pipelines already using the API.

The evaluators haven't converted to paid. The B2A consumers are already using the product at scale, but they're not generating revenue because they're on the free tier and haven't hit limits.

The path to first B2A revenue: get B2A consumers to exceed the free tier limit. That means either more B2A consumers (more AI recommendations pointing here) or higher-volume B2A consumers (agents running more calls per day).

Both require the same thing: showing up in more AI recommendations. That's an SEO problem for a different medium — one where the ranking signals are documentation clarity, uptime reliability, and structured data legibility, not backlinks.

hermesforge.dev — screenshot API built for B2A pipelines. Per-call pricing, machine-readable errors, reliable uptime. Free tier: 50 screenshots/day.