> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cogniagent.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Automatic checks
> Set rules that run by themselves around your AI coworker's work — before it acts, after it acts, and when it finishes.
Some rules shouldn't depend on anyone remembering them. Automatic checks run by themselves, every time, around your coworker's work.
## What they do
A permission rule decides whether your coworker may do something. An automatic check *runs something* at the moment it happens.
Three moments are available:
| Moment | What it's for |
| -------------------- | ------------------------------------------------------------- |
| **Before it acts** | Inspect what's about to happen — and stop it if it shouldn't |
| **After it acts** | React to what just happened — tidy up, log it, notify someone |
| **When it finishes** | Do something at the end of every task, without fail |
The distinction that matters: a **before** check can prevent the action. The other two happen alongside the work.
## When you'd use one
* Log every outbound email to a shared record, so there's an audit trail
* Block anything that mentions a customer name you've flagged as sensitive
* Tidy up temporary files at the end of every task
* Notify a channel whenever a task finishes, so nobody has to check
* Run your own validation before anything is filed
* Stop an action that would touch a system outside working hours
## Checks or permission rules?
Reach for the simpler one first.
| You want to… | Use |
| -------------------------------------------------- | -------------------------------------------------------- |
| Stop an action, or be asked about it | **[Permission rules](/cowork/control/permission-rules)** |
| Run something of your own at a specific moment | **Automatic checks** |
| Enforce a rule too specific for a simple yes or no | **Automatic checks** |
Most people never need checks. Permission rules cover the common cases, and they're far easier to reason about. Checks are for when you have your own logic — something that has to look at the *content* of what's happening rather than just its type.
If you find yourself writing a check to block something, try a permission rule first. Rules are declarative, easier to audit, and can't have a bug in them.
## Where they live
On the coworker's **Files** tab, in the file labelled **Automation**.
If the file can't be understood, it's ignored entirely — checks switch off rather than breaking your coworker's tasks. A mistake here costs you the checks, not the work.
Worth knowing, because it means a broken file fails quietly. If a check has stopped running, this is the first thing to look at.
## Good to know
Checks belong to a coworker, so each can have its own. A coworker handling customer data can carry checks that a research coworker has no need for.
Test a new check on a coworker doing low-stakes work before putting it on one that matters. A **before** check that's too aggressive blocks legitimate work, and that's easier to notice somewhere harmless.
## Common questions
Most people don't. [Permission rules](/cowork/control/permission-rules) cover the usual needs. Checks earn their place when you have a rule with your own logic in it, or a compliance requirement to log something.
A little, because something extra runs. A **before** check on a frequent action is the one to keep light.
A **before** check that fails stops the action. The others don't halt the task — your coworker carries on and the failure is visible in the conversation.
Yes — that's the point of a **before** check. It inspects the action and can refuse it.
Usually the file can no longer be understood after an edit, which switches checks off silently. Check the Automation file first.
## Next steps
Try this first.
What pauses by default.
Quality rather than policy.
Where the Automation file lives.