For teams putting agents to work
Agent-grade documentation.
The trust layer between your docs and your agents.
Your agents already read. This is the layer that tells them what deserved to be read — and records what happened when they acted on it.
How it works
Your procedures get sharper every time someone uses them.
Write it down once, in the repo you already have. Your agents get it as a live endpoint; your people get an ordinary site. When an agent follows a procedure, the outcome comes back to the page it came from — so the next person to open it sees what actually happened last time, not just what someone intended when they wrote it.
One endpoint
A site for people, a connection for agents.
Agents do the work
The exact steps, never a paraphrase.
And report back
What happened, on the page it happened to.
- 01
Write it once
Plain Markdown in the repo your team already reviews. Bring what you have — existing pages, Confluence and Notion exports come across as drafts.
- 02
One endpoint
People get a fast, searchable site. Agents get a live connection to the same source. There's only one copy, so there's nothing to keep in sync.
- 03
Agents do the work
An agent finds the right procedure and gets the exact steps and commands — never a summary, and never a version that drifted from the original.
- 04
And report back
The outcome lands on the page it came from. That's what keeps the status honest — and it happens as a by-product of the work, not as a chore.
See it
Ask for the job. Watch it get done properly.
Your agent finds the procedure, checks whether it's still trustworthy, follows it, and files the result — in one pass, without anyone opening a wiki.
› deploy the API service ⏺ Looking for the procedure… ⎿ Found: "Deploy the API service" Up to date · reviewed this month Last run: clean, 2 days ago ⏺ Reading the exact steps… ⎿ 6 steps, with the commands to run … the deploy runs, and is verified … ⏺ Reporting the outcome back ⎿ Recorded on the page · still Up to date
Deploy the API service
✓ Up to dateNobody updated that page afterwards. The agent that used it left the record behind.
Why teams let it near production
Every answer arrives with how much to trust it.
The obvious worry about pointing agents at your documentation is an agent acting confidently on something that went stale two quarters ago. So status here isn't a label anyone types — it's worked out from how recently the page was reviewed and how its last real runs went, and it travels with every answer an agent receives.
Status is earned, not asserted
A procedure has to have been reviewed recently and actually worked when it was last run. Writing "verified" at the top of a page doesn't do anything.
Age counts against it
Working commands don't prove a page still describes what you meant. Time alone can move a page out of the trusted tier, and your agents will see it happen.
Failures surface immediately
When something breaks, the page says so — it drops out of what agents treat as trusted and goes to the top of the list of things to fix.
Maintenance
Nothing quietly rots.
When your code moves and a procedure doesn't follow, that gets noticed — and turned into a short, ranked list of what actually needs attention. Your existing agents can work that list and bring back changes as ordinary pull requests your team reviews.
No API key to wire up, no bot to install, no dashboard for someone to check on Fridays. The list empties when the documentation is true, and not before.
One workspace
The same page, for everyone who needs it.
Operational knowledge tends to live in three places at once: a wiki people edit, a pile of context files agents scrape, and the truth in somebody's terminal history. This is one source with three ways in — so there's nothing to keep in sync, and no one is reading a different version.
Your agents
Point Claude — or whatever you already run — at your space. They find the right procedure, get the exact steps, and know how far to trust the page before acting on it.
Your coworkers
The people who know the process don't use git. Your ops lead knows exactly why step four has to happen twice — and won't clone a repo to tell you. They edit in the browser, and it arrives as a change your team reviews.
Your engineers
It's Markdown in your repo, reviewed in your pull requests, checked in your CI. Nothing new to learn, and nothing that traps your content somewhere you can't get it out of.
Handing your docs to an AI is table stakes now — most documentation tools ship some version of it, and plenty ship it free.
The useful question is whether the page deserved to be read, and whether anything changed because it was.
Point it at a repo.
See what your agents do with it.
docpack is in private beta. Sign in with GitHub or Google, connect a repo of Markdown, and you get a hosted space, a connection for your agents, and a browser editor for the people on your team who will never touch Git.
Sign inYour content stays in your repo. Changes come back as pull requests you review.