What stays under human approval, and how approvals work

The rule is short. An agent may read, analyse, draft and propose. A person decides whether anything consequential happens. Sending, paying, deleting, pushing code and running shell commands are the usual examples. The rule is only useful if it is built into the way the system works, rather than left to a prompt that says please ask first. A prompt can be ignored. A call that cannot proceed without a recorded decision cannot.

The rest of this page shows where that is true in the platform today and where it is not. Approvals exist in several parts of the platform: in Cortex, in Nexus, in workflows and in the policy engine. They were built at different times, and they do not share one model or one inbox. We say that because a reader planning a governed rollout should know it before they start.

Workflow gates matter most when the person who must decide is busy. A gate is addressed to an assignee, not to a room. If the assignee does not answer, the gate is nudged, then escalated to a named fallback, and if nobody answers it is parked. Parked still means waiting for a decision. The design principle is explicit: a gate never auto-approves, because silence is not consent.

The human input step in a workflow follows the same idea. It pauses the run, waits for the assignee and routes to an approve branch or a reject branch. The default timeout is 24 hours as built. You can design a workflow so that a timeout rejects, which is usually the right choice for money and access. We do not claim that Swfte routes its own approvals through these gates today.

Two examples from our own practice are in use today. The first is a live payment test in our Cortex application. A real charge was made to check billing, and the gate on it required that it be refunded or explicitly marked as kept by the owner. The agents did not decide. The handover said not to infer the decision from a commit request, and the owner later chose to keep it.

The second is the key used to sign releases of the application. It is held by the founder, and the release runbook lists the steps that need the founder, so an agent cannot publish a signed release without that person. Another practice is a repository rule telling AI assistants to propose before executing. It is a rule, not a mode in the app, and many sessions have run autonomously when asked to. We give no names or figures here.

Several things that sound like they exist do not yet. There is no single approval inbox: approvals exist in several parts of the platform, and a person who must handle them all uses several screens. The platform does not enforce that the approver differs from the requester, so the four-eyes rule is something a team applies by how it organises itself. Roles and delegation for approvers are listed as gaps.

The Trust Profile, a single record that names an AI system's owner, risk level and approval rule, is not in the product as one record. Its controls exist in separate pieces that are not joined. Autonomy levels from L1 to L5 are likewise not a setting: no agent carries one. Our platform pages describe both as the design. Treat them as the shape we are building towards, not as something you can switch on.

This is how we would handle customer refunds with an agent, as design intent. We have not run it. The agent reads the request, checks the order, and prepares a refund recommendation. Under the approval threshold it drafts the refund and waits. Above it, the draft is addressed to a named finance approver. Nothing is paid until a person decides.

The approver sees the order, the policy applied and the amount. If they approve, the payment step runs once and the decision is stamped with their identity. If they do not answer, the gate is nudged and escalated, then parked. The ledger records each step. The threshold is <approval threshold - set by the process owner>. If we have a real approval of our own to show, it will replace this one: <real example of an approval Swfte routed through Nexus - founder to fill>.

A person decides anything that moves money, changes access, sends words in your name or deletes something that cannot be restored. A person sets the threshold and chooses the fallback approver. A person reads the ledger when something goes wrong. A person decides to trust an agent with more, one step at a time, and writes down why.

For the wider design of governed agents, with their limits, approvals and records, read the governed agents page. For how the same ideas apply to regulated processes with sign-off, read the compliance workflows page. Both describe how you can do it. They do not describe what Swfte has already done, which is what the evidence table below is for.