Guide

Agents

How coding agents work on this solution: how they connect, what they receive, and how they are doing. What they may do (policy, authority tier, language, repositories) is set under ⚙ › Solution settings.

For: Team developer, Project lead, Security & compliance

What agents receive

Agents read the Authority records, their acceptance criteria, the constraints and accepted decisions around them and the standards that apply. Approved records are informative; Retired ones never drive new work. Asked about a story, an agent gets its whole context slice (get_work_context): the chain up to the objective, criteria to meet, tests, conflicts and recent changes, its initiative and component. It also follows the solution's design records (BDR, FDR, NFDR, TDR, ADR): they say what the solution is today.

Solution and initiative

A connection belongs to one solution; an OAuth connection moves with switch_solution. At session start get_agent_policy lists the open initiatives. New work and requirements go to the initiative the agent names, else the parent's, else the one chosen for the session (select_initiative, 12 hours, kept per session — parallel sessions on one token each have their own), else the only open one besides maintenance; otherwise the agent asks you once. Defects without a parent go to the quarter's maintenance initiative. The Claude Code plugin tells CorPole which repository it works in, so findings and code checks go to that repository's component.

Ways to connect

ToolHow
Claude Code (recommended)Install the CorPole plugin and sign in with /mcp (acts as you, no token). That gives the agent CorPole's tools and the plugin's commands — and no hooks: a sign-in leaves nothing on your computer that a hook could use. The plugin's hooks (session context, notices, the code gate, the waiting status) run only with a credential on the computer: create your personal token and store it in ~/.config/corpole/token.
claude.ai, ChatGPT, Claude DesktopAdd a custom connector with the MCP URL, sign in and pick this solution (or create a new one). No token needed.
Cursor, VS Code, other MCP clientsAdd a remote MCP server with the configuration shown and your personal token.
Any agent without MCPPaste the CLAUDE.md / AGENTS.md snippet into the repository.
Plugin commandDoes
/corpole:startCreates the solution if needed and starts it with you: it settles what the solution is, then works through its first requirements the way CorPole's setup brief for the solution describes.
/corpole:onboardBrings an existing codebase in, one repository at a time, as design drafts for people to review.
/corpole:handoverMoves CLAUDE.md rules, documents and ADRs into CorPole as proposals.
/corpole:initWrites the repository kit (the CorPole block in CLAUDE.md and AGENTS.md, short pointer files for Gemini, Copilot and Cursor, team settings, change-request template and CI check).
/corpole:context, /corpole:checkShows the binding records; checks changes against them.

Tokens and connected apps

  • Personal tokens: everyone creates their own, one per machine or tool, with an expiry. An agent using one acts as you: your permissions, and everything it does is recorded under your name. Shown once; revoke it any time.
  • Service tokens are for CI (the change-request check, test results). Only people with the Integrations permission create them; they act for their creator. The single solution token of earlier versions is now listed as a service token.
  • Tick Allow proposing to let the agent propose records, changes, work items and tests and report results.
  • People with the Integrations permission see every token in the solution and can revoke any of them; the owner is notified. Creating and revoking tokens is written to the solution history.
  • Sign-in connections appear under Connected apps; disconnect them there and the next call is refused.
  • An agent never has more permissions than the person it acts for.
  • CorPole masks secret-looking values (tokens, keys, passwords, card and national ID numbers) in everything an agent sends, and tells you when it did — rotate the secret if it was real.

Keep in mind Do not share a personal token: whoever holds it acts as you. Never paste it into a chat, a record or a file in the repository; revoke it if it may have leaked.

Production emergency

When production is broken and a fix cannot wait for its requirements, a person allowed to declare an emergency opens a window (default 4 hours) here or through their agent. Everyone in the solution is told. CorPole opens an urgent demand and an urgent initiative for it. The code gates then advise instead of refusing, a critical defect in that initiative tracks it (already Ready, so the agent can start it) and a red Emergency label shows in the context row below the top bar. Actions the policy forbids stay forbidden. When it ends, a Make good task is opened for the governing requirement and its test, and the requirement owners are asked to complete it. The urgent initiative closes only with a post-incident review: it becomes a proposed lesson, a draft regression test for each missed criterion without a working test, and a runbook.

If the fix needs longer, Extend once adds hours with a reason, up to 12 hours after the declaration in total. Everyone in the solution is told; the extension is kept in the history.

Agent health

Signs that an agent is going the wrong way, caught before the work piles up. L1 the agent was told, L2 you were told, L3 flagged here for the integration managers, L4 the server refused.

SignalWhen
DRF-03A change request cites a Retired or Draft record.
DRF-04Repeated refused actions (policy, role, code gate).
DRF-05The same test keeps failing.
DRF-07Work the agent started has no code link for days.
DRF-08The agent is close to the hourly proposal limit.
DRF-01A change request cites no record or work item and has no no-requirement label.
DRF-10The agent wrote before reading the agent policy.
DRF-11 / DRF-16A claim or finding without evidence (refused).
DRF-13The agent keeps trying a status it may not reach.
DRF-14A change request builds on vague wording (fast, easy, user-friendly) nobody asked about.
DRF-17Most onboarding findings of the last 30 days were rejected.
DRF-18The advisory gate warned about ungoverned code 5 times in a week.
DRF-22A lesson or the same kind of drift keeps coming back: make it a rule.
DRF-23Agents were asked, but no lesson or idea came in for 30 days.
DRF-26The agent created work without naming or choosing an initiative, so it fell to the solution's default (flagged from 3 a week).
DRF-27The agent tried to write to an initiative that is already closed.

Resolve a signal once it is handled: pick the root cause (agent, requirement, configuration, process or false positive) and note what was done. Tick Keep it as a lesson and the note becomes an accepted lesson that agents read in their context.

CorPole closes a signal itself when its condition is gone: the test passes, the stalled item moves or gets a code link, the work reaches Done. Stalled work is checked every day, even if nobody opens this page. Trend shows the last 30 days by signal, signals per active agent-day and the root causes. Thresholds are set on the Account page and can be overridden per tenant in Settings.

Agent metrics

Ten measures of how agents and people work together over the last 30 days: traceable pull requests, accepted proposals, criteria met the first time, time to answer a question, time agents wait, rework, drift density, the learning loop, agent calls per story and flow time. Each shows its target; it turns green or amber once there is enough data.

Label a trivial change request no-requirement so it counts as a deliberate exception, not ungoverned code.

Adherence by client and model shows, whichever client and model your agents use, the share of sessions that read CorPole's context before their first file change, server refusals and drift signals per session, and how many pull requests the CorPole check stopped. The model appears when the client reports it at session start.

Agent activity

Agents → Activity keeps every call a coding agent made to CorPole: what it sent, what CorPole did inside — records changed, notices sent, drift signals raised, actions refused, secrets masked — what it gave back and how long it took. Filter by tool, agent, result, record code or date, and export the list as CSV.

Secrets are masked before anything is stored. The full answer is kept for 90 days; its beginning and a SHA-256 fingerprint stay, so you can later show what an agent was given. People who manage the solution's integrations, tenant owners, admins and auditors see every call; others see the calls made for them.

Repositories, repository kit and activity

Connect the GitHub or GitLab repositories on Solution settings → Repositories and CI so change requests and commits that mention a code link themselves and move stories. The Repository kit makes the repository treat CorPole as its requirements authority; its CLAUDE.md block carries a stamp, and the Claude Code plugin tells you at session start when the agent policy or the authority tier changed and the kit should be re-applied (/corpole:init). Agent activity lists the last 10 reads and proposals.

Change-request check: the repository kit's CI job (GitHub Action or GitLab CI include) checks that each pull or merge request cites at least one existing, non-retired record code — a story code links the work but does not pass on its own; the no-requirement label skips it. It also sends the files the request changes, and CorPole answers: ungoverned code (fails under the enforced gate), a module whose findings are under review, files outside the modules of the cited work, other open change requests changing the same files, and emergency rules. The check's token is a repository secret on GitHub or a masked CI/CD variable on GitLab; CorPole needs no GitHub or GitLab credentials. Re-apply the repository kit to get it.

Feedback for CorPole