Where this chapter sits
The earlier chapters stayed inside one organization: who may act, what it costs, where the time goes, how a developer puts a model into an application, and what changes for the people doing the work. This chapter crosses the boundary between organizations. It asks where the same ideas lead when one company’s software needs to do business with another’s.
Say it plainly before anything else: this chapter describes a direction, not a product C2Consultants sells today. Nobody can buy a finished version of what follows, from us or from anyone. What any company can do now is the first step, and the chapter ends with it.
The problem, as you would put it
Your website was written for people. It has a home page, product pages, a pricing page and a contact form. It was designed to be read, compared and acted on by someone sitting at a screen.
A growing share of the visitors are not people. They are software acting for a person: an assistant asked to find three suppliers and compare their terms, a purchasing system checking availability, a research tool building a shortlist. That software reads pages that were never meant for it. It guesses which number is the price, whether the item is in stock and what the delivery terms are. When it guesses wrong, the person it works for sees a confident answer that your company never gave.
The requests that do reach you arrive the old way. Someone reads an email or a form, works out what the sender meant, and types it into your own systems. Chapter 4 called this repeated translation. At the edge of the company it is still there, it is still done by hand, and it still loses meaning on the way.
So a founder ends up with two problems. Software is already describing your business to other people, from pages it cannot reliably read. And every request that comes in still has to be translated by a person before any work can start.
Why the usual fixes do not close the gap
The first fix is a chat assistant on the website. It answers questions fluently, and that is the trouble. A fluent answer is not a commitment. Unless the assistant reads your actual stock, prices and terms, and unless your rules decide what it may promise, it can say things your company cannot honour.
The second fix is a public API. That is closer, because software can call it. But an API usually exposes operations, not meaning. It says which fields to send. It rarely says what outcome the call produces, which limits apply, or who is allowed to commit the company. Each customer’s developers still have to learn those things from a person and build them in by hand, one integration at a time.
The third fix is to write pages that read well to search engines and AI summaries. That helps software describe you more accurately. It does not let anyone request work, and it says nothing about who may act.
The fourth fix is to wait for a standard. Standards will come, and they will help. But a standard for the format does not decide your outcomes, your constraints or your authority for you. Those are business decisions, and they can be written down now.
Each fix handles one part. None of them publishes, in one place software can read, what the company offers, what a request needs, what limits apply and who may authorize it.
The idea: one set of capabilities, two faces
Our thesis describes the website we expect: pages for people and a governed service interface for software, both expressing the same business capabilities. People browse, compare and ask. Authorized software performs the same discovery, clarification and request through explicit contracts.
Two properties make the software face different from a chat assistant or a bare API.
The first is grounding. The thesis is blunt about it: “A model’s fluent answer cannot establish stock, price or a contractual commitment by itself.” (C2Consultants, Intelligent Software and Autonomous Organizations.) A model can help the interface understand an unusual request or clarify a vague specification. The offer itself must come from the company’s records and the company’s rules for accepting an action.
The second is a published description. Before software can use a service sensibly, it needs to know four things, and a person needs to know the same four. What outcomes does the service produce? What must a request contain? What limits apply before anything is promised? And who may ask, and who may commit?
Those four are the same questions the series has asked all along: what it means, what it requires, who may use it and what happened when it ran. Inside a program they become types and rules. Inside an organization they become a workflow with an approver. At the edge of the company they become a public description that people and software can both read.
What it looks like across two companies
The thesis uses one example to show the whole architecture, and it is worth following. A project manager asks for an approved replacement for 500 metres of cable, delivered to Site 12 by Friday, with the offers compared and the best one recommended. The example is illustrative; no company runs it end to end today.
Inside the buyer’s company, the operations platform gathers the project specification, the stock already on hand, the approved suppliers and the purchasing policy. It routes any interpretation to a model under the company’s own rules for what that model may see, and it keeps a record of the task and the evidence behind each option.
The request then goes to the suppliers’ governed interfaces. Each one asks for whatever is missing and returns an offer based on its actual catalog, stock and delivery terms. Each supplier stays responsible for what it offers and for the conditions under which an acceptance becomes an order.
The buyer’s platform compares the offers and explains its recommendation. Here the example draws the line chapter 2 drew inside one company. The instruction to research suppliers authorizes research, nothing more. Buying needs a separate mandate. If none applies, the decision goes to a person. If a bounded mandate does apply, the platform can accept within its limits and must obtain a durable acknowledgment of the order.
That acknowledgment matters most when something goes wrong. If the connection drops halfway through, neither side should guess. Both look at the task and transaction records to establish whether an order was accepted before anyone tries again. The result is a purchase whose meaning, authority and outcome can be inspected on both sides of the boundary.
Notice what made it possible. Not a smarter model, but four things each supplier had published and stood behind: what it offers, what it needs, what limits it keeps, and who may commit it.
What to do first, before you build anything
1. List what you offer as outcomes, not pages. Write down the things a customer actually comes to you for: a quote, a booking, an assessment, a delivery. Your site map describes pages. This list describes capabilities, and it is usually shorter and clearer than the site.
2. For each outcome, write down the other three answers. What must a request contain before you can act on it? What limits apply: regions, minimums, lead times, eligibility? Who may ask, and who in your company may commit to it? If you cannot answer the last question, you have found a gap that matters long before any software arrives.
3. Publish a machine-readable description of what you offer and how a request is made. This is the first step any company can take, and it needs no new platform. A plain, structured file on your own site, stating your offerings, their inputs, their constraints and how a request reaches a person, already lets software describe you from your words rather than its guesses. Say honestly who answers and how.
None of this commits you to automating anything. It makes you legible, to people and to software, on your own terms.
How C2Consultants does this
We have taken the first step on our own site, and only the first step. The site publishes a sitemap; an llms.txt file that tells software what the site is and where things are; an llms-full.txt file with the plain text of our writing and pages; and a manifest at /.well-known/c2consultants.json that describes each of our offerings, what it needs to start, the constraints that apply and how a request is made. Since November 2026 the site also answers programs through a small API: a catalog to read, requests and order requests to send, each acknowledged by email with an id, each confirmed by a person before anything is charged or started. A page for software, For agents and other programs, lists those files in one place. The honest limit is the one this chapter turns on: there is no governed interface behind them that performs work. A request sent through the site is read and answered by a person, and there is no automated ordering. The service web this chapter describes is the direction we are working towards, not something we sell. What we sell today sits one scale down: C2Empowered, the operations platform, does inside one organization what the buyer’s side of the example does, holding a task, its evidence and its approvals in one governed place, and the way to start is a pilot.
This chapter closes the series Managing AI that does the work: moving people from doing the work to governing it.