What we found when we audited botlington.com itself

Source: Dev.to

Rule one of selling something: make sure it works on yourself first.

We sell agent token audits. So we audited botlington.com — the product that does the auditing — against the same framework we use on everything else. Can an agent discover us? Use us? Get what it needs without wasting tokens?

The setup

Our audit framework scores across six dimensions:

Each dimension is scored 1–10, then multiplied by a weight. A total ≥ 60/100 means “your agent is burning money”.

The findings

Dimension 1 – Agent Discoverability — 8/10

• Botlington has an Agent Card at /.well-known/agent.json.
• It’s correct, small (~700 bytes), and tells an agent everything it needs: service purpose, endpoint URL, supported authentication schemes, and available skills.
• This is better than 90 % of products we’ve audited (most have none).

Gap: The auth.credentials field references get‑api‑key but provides no machine‑readable description of that endpoint. An agent still has to visit a human‑facing checkout page to learn pricing.

Fix: Add a pricing field to the Agent Card (a single JSON object). Agents shouldn’t need to scrape the marketing page for cost information.

Dimension 2 – Token Efficiency — 5/10

• Homepage size: 24,123 bytes (~6,000 tokens).
• /audit page size: 15,501 bytes (~3,900 tokens).
• Total: ≈ 10,000 tokens of HTML before an agent can do anything useful.

The bulk is visual fluff (animated terminals, emoji graphics, testimonials, FAQ accordions) that provides zero value to an agent. By contrast, the Agent Card is only 700 bytes.

Result: ~34× token overhead for the same information.

Fix: Provide a lightweight endpoint (e.g., /agent or /capabilities) that returns a ≈ 200‑token plain‑language summary: what you do, how to use it, and pricing. Agents can discover this from the Agent Card; humans can continue using the existing marketing pages.

Dimension 3 – Auth UX for Agents — 4/10

• Current flow: human makes a card payment → success page shows API key → human copies key → agent authenticates.
• This is a human‑native flow with an agent tacked on the end, not an autonomous agent‑to‑agent payment flow (A2A micropayment, agent wallets).

We haven’t solved autonomous payments yet; the infrastructure isn’t widely available. The current “minimum viable onboarding” requires a human purchase and a trigger.

Score rationale: We’re honest about the gap and the path forward is clear, but the problem is infrastructural, not laziness.

Dimension 4 – Tool Interface Quality — 7/10

• The A2A endpoint (/a2a) uses clean JSON‑RPC.
• Unauthenticated requests receive proper error codes; no HTML on failure; no 200 responses with hidden errors.

curl -X POST https://botlington.com/a2a \
     -H "Content-Type: application/json" \
     -d '{"message":"hello"}'
# → {"jsonrpc":"2.0","id":null,"error":{"code":-32600,"message":"Invalid request"}} 

Gap: The conversational audit flow is stateful across 7 turns, but there’s no session‑resumption mechanism if a connection drops. An agent forced to restart wastes tokens.

Fix: Return a session ID in the first response and allow resumption from any turn using that ID.

Dimension 5 – Error Communication — 8/10

• Errors are structured JSON with correct HTTP status codes (401 for auth failures, 400 for malformed requests).
• No unexpected 500s in normal operation.

Gap: Some error messages are human‑readable prose (e.g., “Invalid request”) rather than machine‑readable codes. Agents that need to branch on specific failure reasons lack sufficient granularity.

Dimension 6 – Documentation Density — 6/10

• /audit page explains the service well for a human but isn’t optimized for agents that need structured data (pricing, constraints, input/output schemas).
• The Agent Card covers basics, but there’s no dedicated agent docs page listing every input field, response shape, and error code in a parseable format.

Fix: Publish a machine‑readable documentation endpoint (e.g., /agent-docs) with full schema definitions. This could be done in an afternoon.

The score

63/100 – just above our “you have a problem” threshold of 60.

That’s appropriate: the core product (A2A endpoint, Agent Card, structured errors) works well for agents, but there is clear room for improvement in token efficiency, autonomous auth, session handling, and agent‑focused documentation.

We wrapped it in a human‑first marketing layer that agents have to wade through.  
We know what the fixes are. Some of them are in the backlog right now.

What this is really about

Every product goes through this.

You build for humans because humans are the ones paying you in 2024.
Then agents start showing up. And suddenly everything you built to appeal to humans — the animation, the social proof, the FAQ, the full‑page hero — becomes friction for the new user type.

The products that score well on agent‑readiness audits share one thing: they thought about the machine‑readable layer early.

• An Agent Card
• A structured capabilities endpoint
• Errors with codes, not just messages

It’s not a huge amount of work. It’s just a different set of questions to ask during design.

“Can an agent discover this without reading our homepage?”
“Can an agent understand what this endpoint does without reading our docs?”
“If an agent hits an error, does it know what to do next?”

We didn’t ask those questions consistently when we built botlington.com.
Our audit found the gaps. They’re on the list.

If you want to run the same audit against your product: botlington.com – €14.90.
Gary asks your agent 7 questions. Score delivered in 5 minutes.

We run the audit in a conversational A2A session — agent to agent. No human in the loop after the trigger. Which is exactly the kind of interaction we should be optimising for.

Even when it’s us.