Every Domain Needs Its AGENTS.md

A CIO I trust called me last month — the details below are a composite, the pattern is not. His team had done everything the vendor decks said to do. Copilot seats were live across the enterprise. Three MCP servers were procured and running in a governed catalog. His platform team had stood up an agent-maintained wiki. Each business function had a named "skill" registered in a central skills registry.

He had four pilots. None of them had moved in six weeks.

"The agents work in demos," he said. "They don't work here."

I asked him to send me the four. They all failed the same way. The agents could reason. They could invoke tools. They could quote the wiki. What they could not do was resolve a single request without a human translating the enterprise's actual intent — the unwritten policy, the tacit exception, the approval chain that lives only in someone's head — into an instruction the agent could act on.

Same story, four times, one diagnosis.

The agent is ready. The enterprise is illegible.

If you have been reading Part 1 of this series, you already know why software crossed this line first: its work came with a free grader. But grading is downstream. The precondition to grading is legibility — the enterprise has to be readable to a machine before the machine can act on it. Software solved legibility decades ago and did not notice it was solving anything. Git is not a developer tool. Git is a machine-readable record of intent, policy, and state, versioned and diffable. Every other function in the enterprise is running on forms, decks, email chains, and a wiki that nobody trusts.

Which brings us to AGENTS.md.

What AGENTS.md actually is

The name is right. The mental model is wrong.

AGENTS.md started as a file in the coding-agent world — a small markdown document at the root of a repo telling an agent what the codebase is, how to run it, what conventions to follow. It is a good pattern. It is not what your enterprise needs.

What your enterprise needs is an interface stack. Six layers, one name:

• A versioned repository that stores the whole thing.
• A machine-readable policy pack — approvals, permissions, data boundaries, escalation rules — that agents evaluate before they act.
• A skill catalog — reusable, portable capability bundles the agent can execute.
• An MCP server (or several) — the governed tool catalog that grants access to systems of record.
• An audit and observability stream — every call, every result, every session, streamed to a place your security team already trusts.
• A README on top — for the humans who still need to skim it.

AGENTS.md is not a document. It is an MCP server, a policy pack, a skill catalog, and an audit stream — with a README on top.

Every enterprise vendor pitching an "agent strategy" this quarter is pitching some subset of that stack. The interesting question is not whether you have one. It is whether you have all six, versioned together, in a form your agents can execute and your auditors can read.

Almost no enterprise does.

The five translations

To get there, an enterprise has to make five specific translations. This is the framework. Call it the five translations, and I will call it that for the rest of the series.

Each translation takes a human-facing artifact that has served the enterprise for thirty years — often served it well — and produces the agent-facing artifact it now needs to run alongside.

Read the map left to right. The left column is what the enterprise runs on today: forms, approval chains, tribal knowledge, status meetings, and documents-as-artifacts. The right column is what an agent needs to operate on the same work. The middle column — the translation — is where most of the pilots are stuck.

1. Forms → intent capture. A form is a workaround for a system that cannot understand intent. It gives the human a fixed shape to force the enterprise to accept. An agent does not need the form; it needs the intent. Adobe's Customer Experience skills shipping inside Claude Enterprise and M365 Copilot on 2026-06-22 are a small existence proof of agent-facing, governed actions — and the direction these suites are pointed is unmistakable: the platform captures the intent and dispatches skills against it, and the brief-as-form withers. Forms are intent written for humans. AGENTS.md is intent written for machines.

2. Approval chains → policy-as-code. A DocuSign chain is a workflow diagram that pretends to be a legal control. An agent can honor a chain only if the chain is executable. ServiceNow's Build Agent, announced in W26, made the split explicit: build the agent in any IDE you want; deploy only through the governed ServiceNow runtime — approvals, AI Control Tower, MCP context. Flexible creation surface, governed execution surface. That is the split every enterprise will run. My prior post on designing the AI control plane is where this lives architecturally; the news is that the incumbents are shipping the runtime, not describing it.

3. Tribal knowledge → context packages. Anthropic's Agent Skills went GA in W19 as composable, portable, executable capability bundles across every Claude surface. Ten of them targeted financial services out of the gate, complete with audit logs and managed credential vaults. That is what tribal knowledge looks like when you translate it: not a wiki page, a signed bundle. And when a domain is serious — see the public anthropics/claude-for-legal repo (2026-05-28) — the context package lives in git.

4. Status meetings → observability streams. Every enterprise runs on synchronous status meetings because there is no other way to know what the humans did. Agents do not require that ceremony; they emit telemetry. GitHub's Copilot agent session streaming to SIEM and Purview (2026-07-01/02), and the AI-credit session limits shipped alongside it, are the shape of it: budget primitives and audit primitives built into the loop, not written into a runbook.

5. Documents-as-artifacts → documents-as-executable-context. LangChain's OpenWiki, released 2026-07-02, is a scheduled agent whose entire job is to keep a repo wiki legible to other agents — updated, structured, versioned, without a human writing it. Read that sentence again. The wiki is no longer the deliverable. The wiki is the runtime. Don't train the model on your wiki. Rebuild the wiki for the agent.

Five translations. One repository. Pieces of every translation have shipped as product primitives in the last five weeks. Not one enterprise I have seen has all five, wired together, for a single non-engineering business unit. If it is not versioned and audited, it is not an agent strategy — it is a change-management program.

MCP is the new procurement boundary

There is an emergent property when you cross the five translations against the vendor moves of the last month.

Enterprises are no longer comparing chat UIs. They are comparing governed tool catalogs.

Look at what shipped in a thirty-day window. Microsoft Dynamics 365 Service Agent went GA on 2026-06-30, and Microsoft's own launch language described it as "powered by a robust MCP server" with 70+ tools. Google shipped a remote MCP server for Gemini Enterprise on 2026-07-01. Adobe put its Customer Experience skills into Claude Enterprise and M365 Copilot on 2026-06-22. Workday shipped Agent-Ready Tools on 2026-06-02. ServiceNow shipped Build Agent in W26. Databricks published OpenSharing through the Linux Foundation on 2026-06-12 — a standard for sharing skills, models, and unstructured data so that agents can consume them without bespoke integration.

Six incumbents. One month. All shipping the tool catalog, not the chat surface.

MCP is now the procurement boundary. When your team benchmarks an enterprise AI vendor in 2026-H2, the question is not "how good is their chat," it is "how good is their catalog, and how does it govern." That is a very different RFP.

It is also a new attack surface. CVE-2026-30856, disclosed 2026-07-02 (CVSS 7.6), documents an MCP tool-name collision combined with indirect prompt injection to hijack an agent's tool call. Legibility without tool-identity trust is exposure. If you are reading the context engineering landscape post, this is exactly the shape of the gap that piece flagged — the pieces exist; nobody owns end-to-end. Legibility is one such piece. Tool trust is another.

The MDM trauma, steelmanned

The right instinct — the enterprise instinct — reading everything above is skepticism. I share it. The critique is easy to name.

This is the failed MDM/clean-data dream of the 2010s, rebranded.

We spent a decade and hundreds of millions of dollars trying to build a canonical master data model, a single glossary, one ontology to rule them all. We produced governance councils, data stewards, PDF policies, and lineage diagrams. We did not produce a data-legible enterprise. The instinct that a top-down "make it all machine-readable" program produces expensive furniture is correct, and it is earned.

Steelman conceded. Now the difference.

Two things changed. First, the artifact this time is not a monolithic ontology written by a committee. It is a set of small, versioned, composable pieces — a skill, a policy, a tool contract, a context package — authored piecemeal, and increasingly authored by agents themselves. LangChain's OpenWiki is not a metaphor for this pattern; it is a scheduled agent whose specific job is to maintain agent-legible documentation without a human writing it. That is what breaks the MDM curse: the marginal cost of making something legible falls near zero when a competent agent does the writing.

Second, and more important: this artifact only pays off if it is validated against ground truth. If you ship all five translations but never wire in the verification loop — the domain unit tests, the audit assertions, the pass/fail gate — you have built exactly the furniture the MDM decade built. Context without verification is Potemkin agent-readiness.

That is not a hypothetical. The context layer took roughly $122M in a single month in mid-2026: Jedify's $24M Series (Snowflake Ventures strategic) for a model-agnostic "context graph" over warehouse, CRM, Slack, and documents; Engram out of stealth with $98M for a "learned memory layer" claiming 1–10% of tokens with Microsoft, Notion, and Harvey as partners. Both are vendor-reported. Both are pointed at the same real gap. Neither is a substitute for the eval loop that Part 3 will spend its full length on. If you have read Context Compilation Part 2, the missing systems layer is exactly this — context assembly and verification, treated as one system. Half the system is fashionable this quarter. The other half is where the pilots die.

The rule from the 2028 featured report already stands: governance must be executable, not a PDF. Part 2 is that rule narrowed to the enterprise interface: your intent, your policy, your context, and your telemetry all have to be executable, not a slide deck.

Predictions on the record

Three, dated, measurable.

By 2026-11-30, at least one major enterprise application suite ships a first-class, admin-managed artifact explicitly equivalent to AGENTS.md — covering policy, tool permissions, and audit in one governed surface. Precursor evidence is already shipped: Microsoft Service Agent's 70+ MCP tools (2026-06-30), ServiceNow Build Agent (2026-06), and GitHub Copilot session streaming to SIEM/Purview (2026-07-01/02). The pieces exist. The wrapper is next.

By 2027-Q1, at least one Fortune 500 publishes a versioned public AGENTS.md-equivalent repository for a non-engineering business unit — following the anthropics/claude-for-legal pattern. The pattern was seeded 2026-05-28 with Anthropic's own public legal repo of workflow plugins, agents, and connector patterns. The forcing function is the same one that produced open source in the first place: reproducibility becomes cheaper than reinvention.

By 2027-03-31, at least five widely used enterprise SaaS platforms expose governed MCP-compatible tool catalogs designed for agents — not for humans. Six incumbents shipped in the last thirty days; the pipeline is short. The corollary — flagged with vendor-reported hedges — is that catalog quality, not chat quality, becomes the enterprise buyer's primary differentiation lens by mid-2027.

If these hold, the "enterprise AI strategy" you write in 2027 will look almost nothing like the one you wrote in 2024. It will look like an interface spec.

What to do on Monday

Three moves, in order.

1. Pick one business unit and inventory its five translations. Not all of them. One. Write, in plain language, what the intent capture, policy-as-code, context packages, observability stream, and executable context look like today. If any of the five is "we have a form" or "we have a wiki," that is the gap. Naming the gap is the work.

2. Publish an internal AGENTS.md-equivalent repository for that one unit — in git. Make it versioned. Make it reviewable. Start with the policy pack and the skill catalog; the tool catalog and telemetry stream will come as the MCP surfaces you already own get connected. For the reference framing of what "executable context" looks like on the non-engineering side, the AI-native computer part 2 piece on capability graphs is where I would point your architects.

3. Refuse to fund any agent pilot that cannot answer three questions. What is its intent capture? What is its policy pack? Where does its telemetry stream go? Pilots that cannot answer these three do not have a legibility problem you can fix; they have a strategy problem. Send them back with a spec, not with more compute.

Do that in one unit and the second unit is a template. The third unit is a pattern. That is how the AGENTS.md era actually gets built — not as a program, as a pattern that compounds.

Next in this series, Part 3: The Verification Gap. Legibility is necessary. It is not sufficient. Part 3 takes on the half of the problem that decides who owns the margin: the domain that verifies cheaply prices on outcomes, tunes smaller open models, and compresses vendor markup. The domain that cannot stays hostage to frontier tokens and seat pricing. Verification is not a reliability blocker. It is a pricing lever.

Operate. Publish. Teach.