A short piece of fiction, written by API Evangelist. The reader is imagined; the post, and every number and quotation from it, is real: "Start With The Flow, Not The Agent," Kin Lane, October 26, 2026, https://apievangelist.com/2026/10/26/start-with-the-flow-not-the-agent/
Priya ran platform engineering at a company that processed refunds for online shops, and she opened the post on a Monday because her director had sent it with one line: are we doing MCP or A2A? She had a half-built MCP server on her own list and was hoping to be told to finish it.
The post began by calling that the wrong first question. She bristled. She had spent two weeks on the server, and being told the question was wrong felt like being told the two weeks were wrong. She read on with her arms crossed.
The part about agents not being new annoyed her more. The post says web APIs were not made only for humans, and that what has changed is "a more persistent client". She thought that undersold what she was seeing in her logs. Then she scrolled to the list of things providers have been asked to publish for sixteen years: complete OpenAPI with examples, a well-known catalog, OAuth metadata, rate limits, pricing. She checked her own company against it, and the answer was uncomfortable. Her OpenAPI file had no examples. Rate limits lived in a support article. Next to that list the post says "It is overdue work." She read the line twice and did not enjoy it.
She did not agree with all of it. The post calls MCP an API, JSON-RPC over a long-lived connection, and she thought that was too neat. Her team had chosen MCP partly because the tool descriptions were something a model read directly. But the post's larger claim, that the right protocol usually becomes obvious once you walk every step, was harder to wave away. She could not say who initiated half the steps in a refund. Some started with a customer. Some started with a webhook from a payment processor. One started when a nightly job found a mismatch. None of them was clearly an agent.
The section on failure made her laugh, because she had watched it happen. An agent had retried the same refund call several times in one afternoon in the test environment. The post says agents will try again "even when they have everything they need". She had blamed the agent. The post pointed at her API. Refund creation had no idempotency key, and the error responses were a mix of plain strings and whatever the framework produced that day. The post asks for "Fail fast, fail consistently", and her service did neither.
She also noticed what the post asks you to hand back to people: money, error thresholds, improvements. Refunds were money. Her draft server could issue one with no human in between. She did not like that, and she did not pretend otherwise.
She would not tell her director a protocol that morning, and she was not going to delete the server either. The post's advice to sit in on the working group meetings, because the specs are still being worked out, felt like permission to stop pretending the question was settled.
Before lunch she opened a blank page and typed the title of the post's first instruction, "Map the flow, step by step". Under it she wrote out just the refund flow, one line per step. Next to each line she wrote who or what starts it, and whether it is a request, a webhook, or a queued message. She got through eleven lines before her coffee went cold. Three of them had a question mark where the initiator should be.
She did not touch the MCP server. She sent the page to her director with a note saying she would rather answer the protocol question after those three question marks were gone.