Approvals and audit

Where a run stops

An agent is created with a level, and there are two. The lower answers and reads; the upper may also act irreversibly — change something outside the platform that cannot be taken back.

Which irreversible actions need a person’s decision is a policy your administrator sets. It is not the agent’s judgement, not a setting its author controls, and not implied by its level. Replying in a channel can run unattended while creating a record in an external system waits. The policy is set per organisation and is the same for everyone in it.

When an agent reaches an action the policy holds back, the run stops and waits rather than acts. Waiting holds no execution resources.

What an approval request carries

A request names the action, the agent, the initiator, and the grounds — why the agent concluded the action was needed. The person deciding reads an account of intent and consequence, not an opaque call.

Only a principal with an administrative role can decide.

Requests expire. On expiry a request escalates; with no decision there either, it is refused. Silence is never consent, and no setting changes that.

Runs that no person started

A schedule, a channel message, an external event, or an errand from another agent produces work with no human initiator. Such a request carries the automation and its owner in place of the initiator and goes to the organisation’s administrators. Expiry behaves the same way.

Deciding once instead of every time

A decision can be remembered, and remembering is the default. Without it, automation would be pointless: every scheduled run would stop at the same question. A remembered permission covers the same tool with the same recipient — a different recipient raises a new request. It lives until someone revokes it. The platform shows exactly what is being remembered, and every permission granted this way appears in a list you can revoke from.

Decisions that are not yes or no

A request to a person takes four forms: a choice between options, structured input validated against a declared schema before the run continues, a choice of which branch to execute, and an item-by-item decision on a batch. In a batch, only accepted items are published, and the record is written per item, not per batch. A request may be addressed to named people; that routes the answer and grants no access to the agent. These forms come with the human-in-the-loop option, included from the Business edition.

The audit trail

Every privileged action in an evidence export is tied to a responsible person. An action attributed only to an agent or to a service account is not evidence, and the export does not present it as one.

The record of a human decision carries who decided, when, what the model proposed, and how it differed from the proposal. The last is the field an auditor reads first.

Retention of oversight records is configurable; the default is not less than six months. Exports obey the same classification and redaction rules as any other export — evidence is no exception.

Keeping the responsible person real

Attribution means something only if that person actually held the rights the agent used. Where an agent acts as a named employee, that authorisation is granted by the person through your identity provider and never passes to another principal: not when the agent is opened to a group, not when it changes owner. If an author loses access to their own agent, its automations pause and the agent appears in the administrator’s list as requiring a decision — transfer it, leave it with the group, or delete it.

Why this is a condition, not a courtesy

Employment is a high-risk area under the EU AI Act, and an organisation deploying such a system owes competent human oversight and log retention of at least six months. For hiring, a person in the loop and a kept record are conditions of operating lawfully, not refinements added later. SOC 2 auditors ask a narrower version of the same question — which person answers for this privileged action — and the same records answer it.