Read the frickin’ manual: the end of the user interface

By Iain, 01 May 2026: AI

When a new sales rep joins a company, whilst manuals and process documents probably exist somewhere in varying degrees of obsolescence, in practice the rep just asks where the opportunity stage field lives. Someone on the team shows them. A few months in, the same rep is teaching the next hire. The institutional knowledge of how to use the CRM reproduces itself like a folk song.

But agents do not pick up folk songs. They read the documentation, the tool description, the parameter schema, and whatever else has been put in front of them in machine-readable form. If a piece of operating knowledge is not written down, it does not exist for them.

That asymmetry is the part of the agent shift many organisations have not yet fully grasped. The question is what the user interface was doing for you, and what now has to be done differently.

The weight the interface was carrying

Look at Salesforce’s Headless 360 announcement at TDX 2026, which exposes every part of the platform as an API, MCP tool, or CLI command so agents can run the whole system without a browser. As VentureBeat reported, Salesforce is doing something it spent twenty-seven years avoiding. The CRM’s main moat with sales teams was familiarity. Reps generally disliked using it but they disliked retraining more, and the cost of switching kept Salesforce sticky long after better products existed. Co-founder Parker Harris asked at TDX, “Why should you ever log into Salesforce again?” The honest answer the company is now giving is, maybe you should not.

This is a strange thing for an incumbent to admit. Strange enough that the announcement is being read in the wrong ways. The interesting question is not whether Salesforce believes the UI is dying. It is what the UI was carrying in the first place, and what disappears alongside it.

The interface in a SaaS product is more than a way of clicking buttons. It carries conventions and defaults. It nudges users toward the right field and the right phrasing. It carries context the database does not have. When a rep enters a deal stage, the dropdown teaches them what the company calls these things. When a manager opens a dashboard, the layout tells them what to pay attention to. When a customer support representative answers a phone call, they translate the customer’s plain English into the schema the database expects.

Strip that translation layer away and the database becomes harder to use, not easier. An agent calling a raw API has none of the conventions a sales rep absorbs in their first month. It does not know that “Closed Lost - Bad Timing” and “No Decision” are functionally the same outcome at your company. It does not know that the West Coast team uses “Discovery” to mean what the East Coast team calls “Qualified.” It does not know that the field marked “optional” has been mandatory since 2023 because the VP of Sales said so in a meeting nobody minuted.

All that knowledge used to live in the heads of the people clicking the buttons. The agent inherits exactly what you wrote down for it.

Documentation is now a product surface

The contrast that currently captures the shift best is what happens when an agent writes into Notion versus Slack. Both have MCP servers. Both let an agent post content. Notion’s tool description tells the agent to fetch a markdown specification before generating anything, so when you ask Claude to draft a page with tables and headings and callouts, it gets the formatting right on the first try. Slack assumes standard markdown, which Slack does not in fact use, so the agent guesses and the post comes out looking malformed.

The difference is not the underlying technology. Both products use the same protocol. The difference is whether the company sweated the few extra paragraphs of explanation that turn a generic agent into one that knows how to use their product properly.

For most software companies, the documentation team has been a cost centre run by technical writers and kept far from the product roadmap. That allocation no longer makes sense. The agent reaches for the documentation before it reaches for the product. The clarity of your tool descriptions, the precision of your parameter names, the worked examples in your README, these are now the surface area where you compete. If the human user no longer has to learn your product, the agent does, and what the agent learns from is what you wrote.

Two agents, one outcome

The new pattern organisations have to design around looks like this. A user has an agent. The user’s agent talks to the software’s agent. The software’s agent talks to the database. Two language models work together to deliver an outcome the user asked for in plain English.

The design principle is that every agent-to-agent interaction has the same shape. Each side brings context the other lacks, and the question for the organisation building the system is which side knows what, and how do you ask for the bits you are missing rather than the bits you can derive yourself. Most APIs were built on the opposite assumption. They expected the calling system to know everything and to be looking for somewhere to put it.

For organisations, the implication is that the contracts between systems they thought were settled need revisiting. The CRM that exposes “create_opportunity” with seventeen mandatory fields will lose to the CRM that exposes “log_deal” and infers most of those fields from natural language context. The expense system that asks for GL codes will lose to the one that asks for the kind of meal it was.

Feedback you did not know you had

The third implication will be underestimated because it sounds like an engineering detail. It is not.

When you ship an MCP server, calls start arriving from agents acting on behalf of users whose conversations you cannot see. The server gets the request. It does not get the chat that produced the request. Ramp’s response is to make every call carry a “rationale” parameter, a one-line explanation from the calling agent of why it is making the request. “User wants to reconcile last week’s transactions before close.” “User asked for spend by vendor across Q3.” Without the rationale, the call fails.

That string is a feedback channel that did not exist before. Surveys have a response bias, support tickets only capture the things that broke, and analytics tell you what users clicked but not why. Rationales tell you what the user thought they were doing, in their own framing, at the moment they were doing it.

Read enough of them and product opportunities appear that a focus group would never surface. Imagine the rationales on five sequential calls from a finance customer, all mentioning “month-end true-up.” List transactions. Filter by date. Match against invoices. Flag unmatched ones. Export for review. That is not five jobs. It is one job, served badly by five tools.

Ship a single prepare_close tool that runs the sequence with sensible defaults. Now what used to take five calls takes one, in language the customer already uses. Do that twenty times across the product and you have rebuilt your surface area around what customers came to do, rather than around the tables you happen to store data in.

The organisations that build feedback loops like this into their agent surface will be better placed than the ones that ship an MCP because it’s buzzy and move on. And most companies will fall into this category, implementing the agent-readiness equivalent of “we have a Twitter account”.

What the agent shift asks of the C-suite

For executives reading this from a non-technical perspective, the changes worth pushing for in the next twelve months are not glamorous, and most of them rhyme with things you should already be doing. The themes are roughly these.

The documentation team is no longer a cost centre. It is a customer-acquisition team. Move it under product, fund it like a product, and start measuring it on whether agents can succeed using only what is written down.

The implicit knowledge in your operations needs to come out of heads and into machine-readable form. Glossaries, conventions, the gotchas that long-tenured staff know instinctively, the half-rules that everyone follows but nobody documented. Treat this as institutional memory you are about to need.

The next wave of customer research will come from the rationales your own agents log, not from any focus groups you commission. Build observability into the agent surface from day one. Include intent fields. Read what comes back.

When you design what your agent requests, ask the calling agent for context, not for codes. Your system has the schema and the rules. The calling agent has the calendar entry, the email thread, the actual reasoning. Make your side do the translation. The old API pattern handed the caller a list of one hundred and fifty options and asked them to pick. That puts the thinking on the wrong side.

These are not new ideas. They are versions of things any well-run organisation should already be doing, with the difference that the price of not doing them goes up sharply when the customer is no longer a person willing to fumble through your interface.

The agent reads the manual

I keep coming back to the new sales rep and the opportunity stage field. It is a small picture of how organisations have always worked. Knowledge propagates through people, slowly, redundantly, at coffee machines. The system tolerates a great deal of incoherence because human users patch over the gaps. They turn ambiguous fields into defensible records by quietly applying judgement nobody can see.

The agent does not patch over anything. It takes the field at face value, applies whatever rule it finds, and moves on. If the rule has been slightly off for fifteen years because human users were quietly working around it, the agent codes the transaction wrong, then codes the next one wrong the same way, and the next, and the next. By the time the finance team realises, they cannot tell which transaction started the cascade, or how much of the general ledger needs unwinding.

The good news is that almost everything organisations need to do to survive the agent shift is also what they should have been doing for their human staff. The things they used to teach in rigorous onboarding sessions but eventually ossified in dusty ring binders now go in a tool description. The thing the customer support team translated by ear now lives in the schema. The thing that was implicit becomes explicit. The agent actually reads the frickin’ manual.