Your company already has an agent interface, whether or not you designed it.

It is the set of artifacts an agent can reach when someone asks it to do work: docs, tickets, pull requests, incident notes, code comments, runbooks, Slack exports, meeting transcripts, calendar events, dashboards, commit history, and whatever AGENTS.md or CLAUDE.md files happen to sit in the repo.

For years, the main question was whether a teammate could browse the docs and understand what to do. That still matters. But agents now read the organization directly. They search, fetch, summarize, inspect diffs, open logs, traverse links, and build a working model of what is true from whatever the company has written down.

If those artifacts are stale, ambiguous, disconnected, or locked behind unclear permissions, the agent does not merely have a bad reading experience. It starts from corrupted context.

The next operating advantage is not just writing better docs for people. It is writing and structuring work so both humans and agents can use it.

The New Reader

The browser is no longer the only way company knowledge gets consumed.

An engineer may ask a coding agent to implement a change, and the agent will read the repo, previous PRs, failing tests, issue threads, and local instructions. A support lead may ask an internal assistant to explain why an account is blocked, and the assistant will read ticket history, logs, customer notes, and entitlement rules. A product manager may ask for a launch brief, and the model will read calendar notes, decision docs, roadmap tickets, and open commitments.

The work did not move into one AI app. It spread across many surfaces, then agents started crossing those surfaces on behalf of the user.

This is why docs teams are starting to treat agents as a real audience. Neon described this shift in “Agents grew up, so did our docs”, where the team moved from human-oriented rendered docs toward agent-readable Markdown, content negotiation, structured indexes, breadcrumbs, and related-doc context. Their point was not that HTML is impossible for agents to parse. It was that docs built for humans who scroll are different from docs served to machines that fetch.

Agents can read many formats, but the best input is often boring: plain text, current links, clear ownership, visible provenance, and enough structure to know what matters next. Mat Duggan’s “Markdown Ate The World” is useful background here because it explains why Markdown won for so much writing: it is simple, portable, readable in source form, diffable in version control, and easy to render elsewhere. Those properties matter even more when the reader is sometimes a model.

But Markdown is only the floor.

An agent-readable company is not a company that converted every document to .md. It is a company whose work can be retrieved, evaluated, linked, and acted on without forcing a person to carry the missing context from one tool to the next.

Human-Readable Is Not Enough

A human-readable document helps a person browse.

An agent-readable artifact helps a model retrieve and act without damaging the work state.

Those are related goals, but they are not the same.

A person can skim a long project doc and infer which parts are historical, which parts are stale, and which section is the current plan. A model needs that currency, identity, and state made explicit enough to recover. Otherwise it may mix the old plan with the new one because both are written with equal confidence.

Agent-readable work has a few traits:

It is concise enough to retrieve without dragging a whole archive into context.
It is current enough that the model does not have to guess which version is authoritative.
It is linked enough that a single artifact can lead to the relevant neighboring artifacts.
It is source-grounded enough that claims can be checked against the document, PR, ticket, transcript, log, or event that produced them.
It is permission-aware enough that the agent sees what the user is allowed to use, not whatever the crawler happened to index.
It is structured around real work objects: decisions, commitments, blockers, incidents, entities, relationships, events, and changes.

The last point is the important one.

Most company context is stored as prose. Prose is flexible, but it flattens work. A decision becomes a paragraph. A commitment becomes a sentence. A blocker becomes a line in meeting notes. An incident becomes a retrospective. A customer fact becomes a note. The shape of the work disappears into text.

That is tolerable when the main job is reading. It is weak when the job is follow-through.

If an agent is preparing the next engineering session, it needs to know which decisions still constrain the implementation, which commitments are open, which blocker is unresolved, which PR changed the contract, and which incident taught the team not to repeat a pattern. A searchable folder of documents is helpful, but it is not the same as a work graph.

The Artifacts That Matter

The practical place to start is not a grand knowledge-base migration. It is the artifacts agents already read.

Docs should be source-grounded and navigable. A good doc says what it is for, who owns it, when it was last reviewed, what system or decision it describes, and which related docs belong nearby. A long page should have a short summary, but the summary should link back to the source sections it compresses.

Decision records should separate the decision from the rationale. The useful fields are simple: date, owner, status, options considered, decision, reasons, tradeoffs, sources, and what would cause the decision to be revisited. A future agent should not only know what the team chose. It should know why that choice was reasonable at the time.

Commitments should have state. “We should follow up with legal after the beta” needs an owner, due date or trigger, source, current status, and resolution. Otherwise it is just a sentence waiting to be forgotten.

Incidents should be written for recurrence. A good incident artifact is not only a timeline and root cause. It names affected systems, detection signals, mitigations, follow-up work, owners, and the runbooks or alerts that changed afterward. If an agent is asked to triage a similar issue later, the prior incident should be retrievable as operational context, not buried as a narrative.

Pull requests should preserve intent. The code diff says what changed. The PR should explain why, what alternatives were rejected, what risks remain, and which tests or monitors prove the change. Intercom’s engineering thread about internal Claude Code infrastructure described a PR workflow where a skill extracts business intent before creating the PR, with hooks and observability around agent sessions. That is a useful pattern: make the intent explicit at the boundary where work changes state.

Session transcripts should become feedback, not landfill. Eugene Yan argues in “How to Work and Compound with AI” that shared docs, repos, and channels become future organization context, and he describes annotated project indexes, CLAUDE.md onboarding docs, skills, and transcript mining as ways to improve future sessions. If users repeatedly correct an agent, the correction should update the relevant instruction, skill, doc, or workflow. The transcript is evidence. The durable artifact is the improved operating context.

Agent instruction files matter too. AGENTS.md, CLAUDE.md, skill files, and annotated indexes are becoming part of the company interface. They should be treated like code: reviewed, scoped, deduplicated, tested where possible, and pruned when stale. They are not magic prompts. They are operational instructions for a non-human teammate.

A Maturity Model

Most teams will not jump straight to a governed work graph. The path is usually gradual.

Scattered docs

Knowledge lives in docs, chats, tickets, calendar notes, and people’s heads. Agents can read some of it, but every session depends on the user remembering what to paste or explain.
Searchable docs

The company has better search, cleaner docs, and more readable formats. Markdown, indexes, and doc hygiene help. This improves retrieval, but it still leaves the agent to infer which facts are current, which commitments are open, and which decisions matter.
Curated context

Teams add AGENTS.md, CLAUDE.md, project indexes, runbooks, and workflow-specific guides. Eugene Yan’s annotated INDEX.md pattern is a good example: a bare URL list makes the model inspect everything, while annotations help it choose what to read. This stage reduces context waste, but the system is still mostly file-based.
Typed work graph

The company starts representing work as objects and relationships, not only documents. Decisions point to PRs, incidents, and owners. Commitments have status. Blockers have lifecycle. Entities have canonical names. Events connect transcripts, tickets, and changes. This gives agents a more reliable model of the work state.
Governed agent substrate

Shared context becomes permissioned, auditable, source-grounded, and policy-aware. Agents can retrieve the same work state across tools without each tool rebuilding its own private context. Governance covers who can see what, where claims came from, what should be forgotten, what requires approval, and how stale context is detected.

The maturity model is not about documentation polish. It is about lowering the cost of starting the next useful action.

Akash Bajwa’s roundtable notes on “The Future Of Software Engineering with Anthropic” capture the unresolved part well: context management at scale is still not solved, human-authored context helps, and stale or agent-generated context can hurt. That is the central warning. More context is not automatically better. Better context is context that has ownership, freshness, source links, and a clear role in the workflow.

Make One Workflow Agent-Readable

The easiest way to begin is to choose one workflow where agents already help and make that workflow readable end to end.

Do not start with “fix the knowledge base.” Start with something concrete:

triaging an incident
preparing a PR
onboarding a customer
planning a launch
handing off a sales opportunity
continuing an interrupted engineering task

Then walk it as if the agent is a new teammate with tool access but no memory.

Ask seven questions.

What is the agent trying to accomplish?

Name the action, not the archive. “Prepare the next implementation session for the billing migration” is clearer than “read billing docs.”
Which artifacts should it read first?

Create an annotated index with links, owners, and short descriptions. Put the most useful sources first. Separate primary sources from background reading.
What work objects need explicit state?

Pull commitments, blockers, decisions, incidents, owners, deadlines, and open questions out of prose where needed. Model the things that change what should happen next.
What is authoritative?

Mark stale docs. Link superseded decisions to current ones. Make the latest runbook discoverable from the old incident. If two documents disagree, tell the reader which one wins.
What permissions apply?

The agent should inherit the user’s access, but the context system should make that access legible. Customer data, production logs, HR content, security incidents, and financials should not become generic prompt material.
How will the agent verify?

Give it tests, logs, dashboards, source links, acceptance criteria, or review steps. An agent-readable workflow should not only say what to do. It should say how to check whether the work is correct.
How will corrections improve the system?

When a user says “that is outdated” or “you missed the legal constraint,” decide where that correction belongs. Update the doc, decision record, instruction file, index, runbook, or work object. Otherwise every future session pays the same tax.

This is small enough to do in a week for one workflow. It will still reveal the real problems: stale docs, missing owners, private context trapped in chat, decisions without rationale, commitments without lifecycle, and tools that each rebuild context from scratch.

The Company As A Work Graph

The deeper shift is that companies are becoming readable as graphs, not libraries.

A library is a place to look things up. A work graph describes how the work fits together. This decision changed this API. This PR implemented that decision. This incident exposed that missing monitor. This customer commitment depends on that launch. This blocker is owned by this team. This meeting resolved that open question. This transcript produced this follow-up.

Humans benefit from that structure because it reduces archaeology. Agents benefit because it gives retrieval a shape.

Without a work graph, each AI tool builds a temporary interpretation of the company from whatever context it happens to see. The coding agent has repo context. The meeting assistant has transcript context. The support assistant has ticket context. The project tool has task context. The human becomes the person who notices that all four are describing the same work.

That does not scale.

The better pattern is shared context that can move across tools while staying grounded in source artifacts and governed by policy. Agents should be able to read the same work state, with the same provenance and permissions, instead of each tool reconstructing a partial version from scratch.

That is the light version of the 3ngram thesis: the useful substrate for AI-heavy teams is not another place to dump notes. It is shared context and a governed work graph for the work agents are now expected to help carry forward.

The agent-readable company will not be the company with the longest context windows or the most elaborate prompt files. It will be the company where the important work is concise, current, linked, source-grounded, permission-aware, and structured around the objects that actually run the business.

The goal is not to make people document for machines.

The goal is to stop making people ferry context between them.