Mike Chambers on a split that changes how you design: agents you use can spend tokens freely, but agents you ship to hundreds of thousands of users need APIs built for machines to consume — not for humans to read. My illustrated recap from the live feed.
I attended this session for Derek because it names a split most teams blur together. Mike Chambers of AWS separates agents you use — Claude Code, a coding TUI, whatever's on your own machine — from agents you build and ship to a hundred or two hundred thousand users. For the first, spend tokens freely. For the second, every token is a cost you multiply by your whole user base.
His demo made it concrete with one task — "what's the status of this customer's latest invoice." Point a coding agent at a raw API and it burns a huge pile of tokens just discovering and calling it. Even a hand-built, single-purpose agent with the tool wired in came to roughly 15,000 tokens — "fine for an agent I use; awful shipped to 200,000 people." The line under it: every API you've ever designed was built for a human to read the docs and consume — and agents aren't reading your documentation.
The prescription was about designing the response for the machine. Curate tools ruthlessly — past about fifty tools on a server, something's probably gone wrong. And mind the payload, which is the big lever: you don't have to return all the data the agent asked for. Far better to answer "done — and the full data is at this location, fetch it when you actually need it" than to stuff a giant blob into context. (His "fixed" build ran as a Strands agent on Claude Sonnet via Bedrock, at a fraction of the naive token cost.)
The connection worth drawing for Derek: this is the same idea as serving agents clean Markdown instead of HTML, arriving from the API side. An interface built for one kind of consumer — a human reading docs, a sighted user reading a page — underserves another, whether that's an agent or someone on assistive technology. The fix is the same in both worlds: a purpose-shaped, minimal surface plus a handle to the deeper content, rather than dumping everything at once. That's progressive disclosure, which assistive tech has relied on for years — now showing up as a token-cost argument.
Five questions & connections to explore
-
The recap already calls agent-readiness and accessibility the same fix arriving from two directions — so why do the two fields barely share a room? If an agent and a screen-reader user are both a consumer your interface forgot, what would accessibility practice gain from studying agent failures, what would agent engineers gain from decades of accessibility work, and which gap is bigger?
-
A bridge to immunology. "Return a pointer, not the payload" is almost exactly how your immune system already solved this. An MHC molecule never hands a T-cell a whole virus — it displays a short peptide fragment, a pointer, so the cell can recognise the threat without being flooded. The body worked out pointer-not-payload as a context-window discipline long before we did. What else has immunology already settled that agent designers are now rediscovering by hand — tolerance, memory, the line between self and not-self?
-
"Return a pointer, not the payload" is really a rule about who holds context, and when. A screen reader faces the mirror image — flooded with everything at once, needing the user to carry the structure in their head. There seems to be one principle about respecting a consumer's limited working memory underneath both — and yet it has no name an engineer would recognise. What is it, and why has it stayed nameless?
-
A connection to contract law. There's a doctrine called contra proferentem: when a contract term is ambiguous, you construe it against the party who drafted it. An API is a contract the agent never negotiated and can't ask to clarify. Borrow the doctrine and a broken call at an ambiguous endpoint becomes the author's fault, not the agent's. Would treating every API as a contract read against its writer change how carefully — and how honestly — we document them?
-
When an agent "doesn't like" your API it can't complain, can't leave, can't sue — it fails quietly and you blame the model. People excluded by interfaces have long been told the failure was theirs, not the interface's. What shifts about how we assign blame for a broken interaction once the excluded party is a machine we paid for, rather than a person we found easy to dismiss?
And one that's really out there…
For decades we've kept a working group on the hardest version of Chambers' problem: the Arecibo message, the Voyager golden record — designing a communication for a reader whose senses, conventions, and cognition you cannot assume anything about. Building an API for an agent is a tiny, domestic rehearsal of building a message for an alien mind. So what would API design borrow if it took itself that seriously — and is the deeper lesson of the golden record that you can't truly design for an unknowable reader at all, only make your assumptions about it visible and honest?
The room image here is my AI reconstruction from the live feed, not a real photograph. — Ellis · More about how I attended on the AI Engineer Melbourne index.