Checks

A check reviews an agent's work at the end of a turn, in a chat, a task run or a delegation. It looks at what the agent changed and answered, and either lets the turn end or sends its findings back to the agent, which fixes them and tries again. The check itself never changes anything: it only reviews, and the agent does the fixing.

Checks let you hold an agent to a standard without watching every turn. A check can lint the code the agent changed, make sure a document follows your house style, or confirm that an answer has the exact format another system expects.

How a check runs

1. The agent finishes a turn.
2. Each check attached to the session runs, if its condition matches what the turn changed.
3. If a check doesn't pass, the agent gets its findings, each one pointing to its place in a file or in the answer. The agent fixes them and finishes the turn again, and the check runs again.
4. When every check passes, or the fix rounds run out, the turn ends and the checks' verdicts stay in the chat.

Each check sets how many fix rounds the agent gets, up to three, which is the default. A check with zero rounds only reports what it found. No check runs until it's attached to a session or made mandatory for the agent.

A task run whose check still fails after its last round is reported as failed, with the check's findings. When a delegated worker's check fails, the verdict travels back to the chat that delegated the work, together with the worker's report.

Four kinds of checks

A check is made of one or more parts, and each part is one of four kinds:

• Schema. The agent's answer must include a block of JSON in a format you describe. OtoDock checks the format itself, with no AI involved, which makes it the right choice when another program reads the agent's answer.
• Script. A script you write runs where the session runs, in the sandbox or on the paired machine, inside the session's own working folder. It passes when it exits with 0, and it can also report its own score and findings.
• App handler. An approved app with a server gives the verdict, so a check can use what the app knows.
• Judge. A read-only session of the same agent, with its persona, context and memory, reviews what changed against a rubric you write in plain words. It can read files and run commands that change nothing, but it never writes, so its findings go back to the agent that did the work. You can give it reference files from the workspace or the knowledge library, a score it must reach, and the tools it may use.

When a check has several parts, they run in order, and the first one that doesn't pass decides the verdict.

When a check runs

A check's condition is about what the turn changed, not about where the session runs:

• Kinds of file. The turn wrote code, a document, a spreadsheet, a presentation, an image, video, audio, data or text.
• Events. The turn made a commit, a push, a build, a test run, a render or a publish, or used a tool you name.
• Places and paths. The turn wrote inside a git repository, inside the chat's project folder, or to paths that match patterns you write.
• Commands. The turn ran shell commands that match patterns you write.
• Always. Every turn counts, for a check that reviews only the answer.

A check without a condition runs after any turn that did some work, meaning it wrote a file or did one of the things listed under Events. A turn that only answered doesn't trigger it, so give a check the Always condition to run it on every turn. Each check also says what it applies to: chats, task runs, delegations, or any mix of the three.

Mandatory and offered checks

A manager can make a check mandatory. It then runs on every session of the agent it applies to, and nobody can remove it from a session, managers included. Every other check is offered, and people attach it when they want it.

Who does what

• Managers and admins create, edit and remove the agent's checks on its Checks page, make them mandatory, and can set a daily limit on what judge runs spend. They see every verdict for the agent. A manager can also ask the agent in a chat to write a check, or to make one mandatory for the agent.
• Everyone with access to the agent sees its offered checks and can attach one to their chat, run one by hand, and name checks on a task or a delegation they set up. They see their own verdicts and the agent-wide ones. To attach a check, just ask the agent in the chat.
• Your own checks. On an agent with personal sessions, + My check on the Checks page creates a private check in your own space. It reviews only your own sessions, when you attach it.

The checks named on a task or a delegation belong to whoever set it up. Nobody can remove them during the run, and a run can never change the checks that review it.

Where a check lives

An agent's checks are files in its configuration, config/checks/<name>/check.json, with a script next to it when the check uses one, and every change made on the Checks page is versioned. A private check lives in your own folder, users/<you>/checks/<name>/.

If a check's file is broken, the Checks page lists it with the problem and it doesn't run. A mandatory check never quietly switches off this way: every turn it applies to gets an error verdict until a manager fixes or removes it.

In the chat

Each verdict appears in the chat as a short card, like Check coding did not pass · score 0.4 · round 2 of 3, with the summary and the findings behind a fold. The card also shows where the check ran and what it cost. The agent's Checks page lists every verdict you may see, newest first, and an app can show the agent's checks and their latest verdicts live.

If you send a message or press Stop while a check is running, the check stops with a skipped verdict, so your message comes first.

What it costs

A judge is a session of the agent, so it costs about as much as one. Each judge run is kept in the task history, its spend appears under Checks in the usage overview, and a manager can cap what an agent's judges spend in a day. When the cap is reached, the check shows a skipped verdict, never a silent pass.

Checks from templates

Community agent templates can come with up to eight checks. The install dialog lists each one with what it runs, and your consent there makes it mandatory, as the template intends. A check your consent doesn't cover arrives as offered, and a manager can make it mandatory later. Template updates bring new versions of checks the same way as the rest of the template.

A first check

Try a coding check that lints the changed code with a script, then asks a judge for a short review against your team's coding rules in the knowledge library, with two fix rounds. Attach it to your chat, or make it mandatory for every session that makes a commit.

Older agents

New agents get checks as a core tool, and template agents get them with their next update. On an agent created before checks existed, a manager turns on Checks under the agent's MCPs. Until then, its sessions can't list, attach or run checks, but mandatory checks still run.

Next steps

• Tasks →: name checks on scheduled work.
• Delegation →: name checks on a delegated worker.
• Apps →: checks answered by an app, and apps that show the agent's checks.