The third consequence
The Company Is a Protocol
When intelligence becomes personal, management becomes interface design.
Private intelligence
09.16.26
Can a capable stranger contribute?
A company does not need one mind. It needs a clear way to accept good work.
The first article in this sequence told young people to build their own stack. The second told companies to let those stacks cross a visible, permissioned boundary. One problem remains: what is waiting on the other side?
Most companies are still organized around the assumption that intelligence lives inside the institution. The company selects the software, defines the workflow, stores the knowledge and teaches the employee how to move through it. The employee becomes competent by absorbing the unwritten rules: who can approve a discount, which spreadsheet is current, what a “finished” proposal looks like, when a customer promise becomes binding and which mistake can be fixed quietly before anyone notices.
A personal AI arrives without that social apprenticeship. It may be extraordinarily capable and still be unable to contribute safely. It does not know which rule is real, which document is stale, which field triggers an invoice or which manager’s casual sentence overrides the handbook. The company has an intelligence problem on the outside and an ambiguity problem on the inside.
The next enterprise advantage will come from making work legible: not exposing every internal thought, and not automating every decision, but describing the points where a person or agent may enter, what authority is available, what artifact is required, what proof must accompany it and where the accepted result becomes part of the company record.
That is a protocol.
Every organization has an unofficial operating system. It is made of remembered exceptions, Slack archaeology, filenames ending in FINAL-v7, and the colleague who knows what the owner really means.
Humans are remarkably good at compensating for this. We watch faces. We infer status. We learn that the written policy is less important than the example our manager praised last Thursday. We ask Susan before we touch the account because everyone knows Susan will catch the thing the checklist forgot.
AI does not remove that ambiguity. It makes the cost of it visible. Give an agent an unclear instruction and broad access, and it can produce the wrong result with astonishing fluency. Constrain it until nothing can go wrong, and it can do nothing useful. The familiar debate about “how much autonomy” misses the design problem. Autonomy is safe only relative to a clear contract.
The contract does not have to become software on day one. It can begin as a page that answers five questions: What outcome are we pursuing? What may be touched? What must be produced? What counts as proof? Where does the accepted result live?
Writing those answers forces the company to discover whether it actually understands its own work.
A good manager has always translated institutional purpose into work another person can perform. AI makes that translation explicit enough to inspect.
Consider the ordinary request: “We need a strong article about this new service.” A person inside the company can spend six or eight hours filling in the blanks. Who is the audience? What claims are allowed? Which sources are credible? Can the website be changed? Does “publish” mean draft or live? Who checks the mobile page? Which metric defines success?
An agent can ask those questions too. The difference is that the answers should not have to be rediscovered for every assignment. Turn them into a reusable work contract.
Notice what this changes. The manager can improve the contract instead of correcting the same hidden assumption in every output. The worker can use Codex, Claude, Gemini, a local model or no model at all. The company becomes more consistent without demanding identical cognition.
The contract travels farther than a prompt. A prompt tells one intelligence what to do now. A protocol tells any authorized contributor how the institution accepts the result.
04 / Open the specification
Five ports for real work
Open each port. Together they form the smallest useful interface between a sovereign intelligence and an accountable company.
01IntentThe business outcome and the human reason it matters.+
State the change, not the activity. “Prepare a report” describes motion. “Help the owner decide whether to add a second crew” describes a decision. A protocol gives the contributor enough purpose to resolve small ambiguities without inventing the objective.
02PermissionThe exact systems, data and actions available for this work.+
Authority should have edges. Read the customer history. Draft the proposal. Do not change the price table. Do not send. Expire access when the assignment ends. A useful agent needs real capability; a trustworthy company makes that capability scoped and revocable.
03ArtifactThe thing that crosses from private work into company space.+
Name the deliverable precisely. A transcript is not a proposal. Research is not a recommendation. Activity is not completion. The artifact may be a draft, a structured record, a decision memo, a pull request or a scheduled appointment. It should be reviewable before it becomes consequential.
04EvidenceThe proof that lets another person trust or challenge the result.+
Completion needs a receipt. Show the source, the comparison, the test, the screenshot, the calculation or the customer confirmation. Evidence is how judgment survives delegation. It lets the next person inspect the work without replaying the entire process.
05RecordThe governed place where accepted work becomes institutional fact.+
The company keeps the ledger. Approved prices belong in the price system. Customer commitments belong in the CRM. Published claims belong in the site history. The personal stack may create the work, but the institutional record establishes what the company has agreed to do.
Software became composable when services stopped requiring every consumer to understand their internal machinery.
The OpenAPI Specification defines a language-agnostic description for HTTP interfaces so humans and computers can discover and understand a service’s capabilities without seeing its source code or inspecting its network traffic. The Model Context Protocol tools specification applies a related idea to AI clients: a tool can declare a name, description, input schema and optional output schema, giving the client a structured way to understand and call it.
A company is richer and messier than a software service. Customer promises contain judgment. Exceptions matter. Authority comes from law, ownership and role, not from a JSON file. Still, the architectural lesson transfers: clearly described capabilities reduce guesswork.
The company of the AI era will publish an internal catalog of meaningful actions. Quote this service. Propose this discount. Create this campaign draft. Schedule this crew. Reconcile this invoice. For each action, the organization states the inputs, authority, expected output, review point and record.
This is what turns a pile of automations into an operating system. The interfaces remain stable while models, apps and personal methods change around them.
A protocol does not eliminate human judgment. It shows where judgment belongs.
Humans choose the purpose. Humans define the unacceptable outcome. Humans decide which exceptions require escalation and which actions can proceed automatically. Humans approve the artifact when the consequence deserves review. Humans remain accountable for the system they designed and the authority they granted.
The NIST AI Risk Management Framework Core treats governance as a continuing organizational function. It calls for transparent policies, documented responsibilities, human-AI oversight and practices that connect technical systems to organizational values. That is broader than a work protocol, but it explains why the protocol matters. Clear interfaces are where policy becomes behavior.
Person
Brings context, methods, judgment and a preferred intelligence layer.
Protocol
Defines the authorized crossing: purpose, scope, artifact, proof and destination.
Company
Owns the policy, system of record, institutional promise and consequence.
When something fails, this structure creates better questions. Was the intent unclear? Was the permission too broad? Was the artifact underspecified? Was the evidence weak? Did the wrong record become authoritative? “The AI made a mistake” is rarely enough to improve a system. A protocol gives the mistake an address too.
Small companies can become protocol companies first because they can still see the whole business.
Pick three recurring outcomes that cost real time or regularly produce errors. A service proposal. A published article. A completed invoice. Do not begin with a model comparison. Sit with the person who currently does the work and write the five fields.
Then run the contract manually. Give it to a capable colleague who has never performed the process. Watch where the questions appear. Tighten the language. Separate the draft from the commitment. Add the evidence a reviewer actually uses. Remove permissions that are convenient but unnecessary. Only then decide which parts deserve connectors, scheduled agents or full automation.
This sequence prevents a common failure: buying an AI system to automate a process the company has never made coherent. The software arrives, the ambiguity remains and employees become the integration layer again.
A well-written protocol produces value even if no agent ever calls it. It improves onboarding. It exposes brittle dependencies. It shows where one employee carries too much unwritten knowledge. It makes delegation fairer because “good work” is no longer whatever the powerful person remembers wanting after the work is done.
The industrial company standardized the worker’s tools because consistency required shared machinery. The software company standardized the worker’s applications because coordination required shared data. The AI-native company can standardize the crossing instead.
People arrive with different models, histories, methods and strengths. One person thinks by talking. Another builds prototypes. Another researches before speaking. Another has spent years teaching a personal AI how to challenge her assumptions. Flattening those differences into one company chatbot destroys accumulated advantage.
The protocol preserves variety while protecting the institution. The person keeps the instrument. The company keeps the ledger. The boundary says what may cross and what must remain. The work contract says what a valid contribution looks like when it arrives.
Onboarding changes. Instead of spending the first month learning which buttons to press, a new employee learns the company’s promises, capabilities and protocols. Offboarding changes. Company permissions disappear, company records remain and the person keeps the general methods she built. Procurement changes. A new AI tool earns adoption by working with the company’s interfaces, not by demanding that the company rebuild itself inside another vendor’s menus.
This is a more durable institution. It can replace applications without losing its operating logic. It can welcome capable people without annexing their intelligence. It can audit consequential action without surveilling every intermediate thought.
Build your stack. Bring your own AI. Then ask the company to meet you with a clear protocol.
Evidence / checked 09.16.26
Sources
- OpenAPI Specification 3.2.1, published September 10, 2026, for the role of language-agnostic interface descriptions in making service capabilities discoverable to humans and computers.
- Model Context Protocol: Tools, for declared tool names, descriptions, input schemas and optional output schemas.
- NIST AI Risk Management Framework Core, for transparent governance, documented roles, human-AI oversight and continuing accountability. NIST notes that AI RMF 1.0 is being revised.