A person reads the spec once and remembers what they remember. An agent reads exactly what you hand it, on every run. CorPole keeps your requirements, decisions and constraints with a state on each — binding, or retired — and hands the agent only what binds today.
Five short scenes: a founder starts a solution in a conversation and comes back weeks later to ask what's next; the agent drafts records, stops at a conflict, and builds only what people approved, proven by tests. On the left, the chat with the agent; on the right, CorPole keeping the record as it happens.
Same agent, same prompt. The only difference is whether it reads what binds your solution.
Three days later you are rewriting what a “client” meant.
The first commit already has requirements behind it.
/mcp to sign in. You need a CorPole account; request access if you don't have one.claude mcp add --transport http corpole https://corpole.com/api/mcpEach one is a real situation from building with agents, and each answer is something CorPole does today.
Run the kickoff interview before the first line of code. The agent asks the questions, CorPole records the answers as requirements, and nothing binds until you approve it.
/corpole:startOnboarding reads the code, tests, documents and commits, and proposes the modules, behaviour and decisions it finds as findings for you to confirm, correct or reject.
/corpole:onboardHandover moves your rule files, ADRs and glossaries into CorPole as proposals. Conflicts come up side by side, and once you approve, the file stops being the authority.
/corpole:handoverDecisions are records, not chat history. Every session starts from what binds in the solution, on whichever machine and in whichever session you are.
/corpole:contextRetiring a record takes it out of every agent's context at once. What you dropped cannot steer the next run.
/corpole:contextAn agent can only propose. A change to an Authority record arrives as a proposal with a diff, and nothing binds until a person approves it.
/corpole:checkOne MCP server. Every client reads the same Authority records, so the rules do not change with the editor.
claude mcp add --transport http corpole https://corpole.com/api/mcpThe agent reads the records for its task, not your whole docs folder, and nothing that was retired.
Ask your agent“What binds the task I'm on?”
The agent can ask what changed since it last read the solution: which record, who changed it and why.
Ask your agent“What changed in CorPole since yesterday?”
Acceptance criteria are separate items. Tests verify them, CI marks them Met or Not met, and a story with a failing test cannot be closed.
Ask your agent“Which acceptance criteria are not met yet?”
Standards and solution rules are records the agent reads for its task, and the plugin checks each edit against the governed code areas.
/corpole:initDecide per solution whether an agent may write migrations, add dependencies, touch CI or merge: allowed, ask first or forbidden. The repository kit turns it into Claude Code permission rules.
/corpole:initDeclare an emergency and the agent can fix it now, with a defect on record and a make-good task so the shortcut gets cleaned up later.
Ask your agent“Declare a production emergency for the checkout outage.”
Drift signals flag an agent that is going off course, and Agent health shows them per solution, before the damage compounds.
Everything an agent writes to CorPole is masked first, so keys and tokens do not end up in your records.
Retrospectives record lessons and improvement ideas, and a lesson can become a solution rule the agent follows from then on.
/corpole:retroThey connect their own agent with their own identity and read the same Authority records, decisions and open work. Nothing to forward, nothing out of date.
claude mcp add --transport http corpole https://corpole.com/api/mcpEvery agent reads the same Authority records and proposes into the same review queue, so they cannot drift into two versions of the truth.
Decisions are records with their reasons, and every change keeps who made it — person, agent, GitHub or CI — and why.
People write and approve requirements in the web app. The agent reads only what they made Authority.
The agent does not have to remember the rules. CorPole answers at the moment it acts: some things it refuses, some it stops, some it simply lets through.
When the agent tries to approve, close or merge its own work
The server refuses. The agent tells you who can do it and where in CorPole it is done.
RefusedWhen the agent reports a criterion as met without evidence
The report is refused. A criterion is met by a test or a named proof, not by a claim.
RefusedWhen two binding records disagree
The agent does not pick a winner. It stops, shows you both codes, and a pull request citing a record in a confirmed conflict is flagged.
StoppedWhen the same test fails three times in a row
The agent is told to change its approach or open a question, and you are told why.
RedirectedWhen the agent writes before reading the policy and standards
Its next reply tells it to read them first, so the session starts on the rules rather than on a guess.
RemindedWhen the change is a typo, formatting or a rename
No interview and no record. The pull request carries the no-requirement label and the check lets it through.
Let throughWhen you want to start a solution without opening the web app
The agent creates it from the chat, in your tenant and with your permissions, and switches its connection to the new solution.
HandledWhen the agent in Claude Code is waiting for your answer
CorPole shows it in the app, so a question does not sit unseen in a terminal you closed.
SurfacedEvery icon below is the one you see in the app. Each kind of record has its own shape, and its group has its own colour, so a requirement never looks like a decision and a risk never looks like a test.
Why the solution exists.
What the solution must do and be.
Boundaries it must respect.
How each requirement is proven.
How the delivery flows.
How the work is done, and what was learned.
What may go wrong.
Every work type has its own board and its own columns. An agent picks only what a person moved to Ready, moves it to In progress and Code review, and stops there: verification and Done belong to people, and a failing test keeps a story out of Done.
Decide what binds, and keep it that way.
Get to binding requirements before code.
Turn requirements into work people can pick up.
Hand the agent what binds, and only that.
Show that it works, and see when it stops.
Catch drift early, and don't repeat mistakes.
The state is the product. Everything else follows from a record being able to answer one question: does this bind right now, in this solution?
A record is drafted, approved, made Authority or retired. Only Authority binds the agent, and retiring a record takes it out of every agent's context at once.
What governs nowRequirements refine objectives, constraints constrain them, a new record replaces an old one. An open conflict stops a record from becoming Authority.
Criteria are separate items. Tests verify them; CI results mark them Met or Not met, and a story with a failing test cannot be closed.
Traceability and qualityThrough MCP the agent reads the Authority records, criteria, constraints, decisions and standards for its task — and nothing that was retired.
Governed contextDecide per solution whether an agent may write migrations, add dependencies, touch CI or merge. The repository kit turns it into Claude Code permission rules, so the agent stops or asks before it acts.
Every change is appended, never rewritten: who made it — person, agent, the repository (GitHub, GitLab) or CI — what changed and, for Authority records, why.
The fastest way to lose an experienced reader is to imply the system knows what is correct. It does not, and it is not built to.
The system surfaces conflicts and tells you what currently binds. Which record should win is a judgement, and it stays with the people accountable for it.
Whatever an agent proposes — a requirement, a decision, a relation — arrives as a Draft or a proposal. Nothing binds until a person approves it.
A connection acts for the person who created it and carries at most that person's permissions in the solution. A read-only connection cannot propose anything.
Onboarding reads your tests, documents, code and commits and proposes the requirements, decisions and constraints it finds — for you to confirm, correct or retire before any of it binds the agent.