Don't ship the org chart.

Setting the stage: I spent ten years on Square's developer platform. I helped design the modern (V2) commerce APIs as an IC, then ran product for the Developers & Partners business — 20+ APIs, SDKs in six languages, and the review machinery every Square team went through to ship a public API. Since leaving I've kept building with AI-native tools most days, which means the first consumer of almost every API I touch now is an agent.

So I get the 2026 question from both sides: what do agents change about developer platforms? Less than the demos suggest. But the parts which do change are the parts most platform teams aren't budgeting for, and to show what changes I have to lay the system out first.

Every durable API I've worked on started with the end customer and worked back to the tech. The developer integrating you is the channel. The customer is whoever their software serves. When we designed Square's cards-on-file capability, discovery started with how sellers and buyers save and reuse a card, what a stored card means for a subscription, and what breaks when the card gets reissued. REST semantics came last.

Then the business justification, and the first trap. Developers ask for ultimate flexibility, and it feels customer-obsessed to give it to them. But an API with ultimate flexibility for every use case is, at its extreme, simply a database. Take the request at face value and you've exported your storage layer, and every integrator now does your product work for you, differently, forever. The discipline is one page, written down: a) which jobs this API is for b) which jobs it is not for c) what the business gets when it works. If nobody can tie the API to a business outcome, don't build it.

From there, candidate solutions. Real ones: two or three shapes of the API, sketched far enough for the trade-offs to stop being hypothetical, judged against the jobs on the page. Boring, and it works. Most bad APIs I've reviewed skipped straight from justification to the schema of whatever internal system was closest.

Domain modeling is where platforms fail. The temptation is to expose internal service boundaries as public resources, because the teams are organized around them and the API ships under somebody's OKR. Don't ship the org chart. Your customer holds a mental model of the domain (payments, orders, customers, catalog), and your re-org history is not in it. Inside Square, a single payment crossed systems owned by many teams. Publicly it had to be one resource with one lifecycle, and getting there meant fights over which team's noun becomes the public noun, and who owns the seam when two systems disagree. Those fights were the design work. The schema was the receipt.

The fights are worth having because of the timescale. You'll never make the perfect API, but it will last (almost) forever. APIs we shipped in 2019 are processing payments today, mostly unchanged, for developers who have never spoken to anyone at Square. A public contract outlives the strategy deck, the team, and usually the executive who approved it. So we ran completeness bars before anything graduated: alpha proves a real developer can build on it; beta proves it survives production traffic and support volume; GA is a stability promise with a deprecation policy attached. Design is cheap. A decade of compatibility is not.

Agents read docs like a compiler. A human developer fills gaps with judgment: they poke the sandbox, ask in the forums, read the sample apps, or infer the missing constraint from a 409. An agent fills gaps with confidence. Ambiguity which used to cost you a support ticket now costs a wrong integration, executed at machine speed. The remedies are unglamorous and old: one concept, one name, everywhere; error messages which say what to do next; idempotency anywhere money moves; docs which state the invariants instead of gesturing at them. We always said this mattered. Agents enforce it.

Evals are the new acceptance criteria. For years I evaluated product bets with a written go/no-go rubric: mission fit, customer, differentiation, risks, recommendation. At some point I turned the rubric into a prompt and made a model run my own framework against my own ideas (humbling, and I recommend it!). That's the transferable move — judgment you can write down is judgment you can run continuously. For a platform, the eval worth running is a job: give an agent your public docs and a sandbox key, name a real task a customer pays for, and score whether it finishes. Run it on every release. If the agent can't complete the job from your public surface, your documentation was already broken. The agent just proves it faster.

Distribution moves to the machine-legible. Developers used to find APIs through blog posts, conference talks, marketing pages, and word of mouth. Agents pick tools by what they can parse: specs, schemas, structured docs, tool registries. And an agent traverses more of your surface in one session than a human does in a month, payments to orders to catalog to customers, all in one context window. Every seam between your teams is now visible in a single pass. Don't ship the org chart used to be craft advice; agents turn it into table stakes.

The contract. An agent-built integration still calls the same endpoint next year, and real businesses still run their livelihoods through it. Nothing about agents shortens the decade. Faster building means more integrations sooner, so the compatibility promise compounds earlier, and the bar for what you expose goes up with it.

The customer. The agent is not your customer. It works for somebody — a developer, a seller, a founder gluing systems together at midnight. Start with that person and work back to the tech, same as before. An agent booking the wrong appointment is still a seller's angry customer. The failure just arrived through a new channel.

The people. Someone still decides which jobs the platform serves, which nouns win, and what gets deprecated. A model can draft the spec. Owning the promise is still a person's job, and so is the judgment work which remains: the page of jobs, the fight over seams, the call to walk away from a bet when its goals stop matching the business.

If you run a platform today, my short list: a) pick five real jobs an agent should complete on your public surface, and turn them into evals which run on every release b) fix the nouns before adding endpoints — one concept, one name c) make every error actionable by a consumer which cannot call support d) publish your deprecation policy and honor it.

And use your own platform through an agent, weekly. I ran product for one of the largest commerce developer platforms, and the thing keeping my judgment current is building against these APIs every day. Nothing tells you the truth about your platform faster than watching an agent try to use it.