Useful autonomy starts with a clear handoff between agent work and human ownership. Facio treats that handoff as runtime behavior: the agent can keep context, use tools, route through Placet, and continue after interruptions, but authority boundaries remain visible to the operator.
Teams often begin with a single approval prompt. That is fine for a prototype. In production, the stronger pattern is a chain of reviewable checkpoints connected to durable state, audit records, scoped credentials, and internal guidance like agent audit trails or agent rollout planning.
What belongs in a checkpoint
A review prompt should answer four questions before asking for a decision:
- What is the agent trying to accomplish?
- Which data, file, page, or tool result did it use?
- What system will change after approval?
- How can a human pause, reject, or resume the work later?
When those answers are visible, review becomes an operating primitive instead of a compliance afterthought. The same structure also helps operators debug later: a checkpoint should point back to the request, the evidence, the tool path, the approval decision, and the resumed outcome.
Approval data model
The exact schema can stay compact. A checkpoint record needs stable identifiers, a human-readable summary, and enough structured detail to rebuild the decision trail.
type ReviewCheckpoint = {
id: string;
runId: string;
action: 'send_message' | 'export_file' | 'change_system';
summary: string;
evidence: Array<{ label: string; value: string }>;
requiresCredential?: string;
approvedBy?: string;
approvedAt?: string;
};
Operating shape
| Layer | What the human sees | Why it matters |
|---|---|---|
| Intent | Agent goal and requested action | Prevents blind approvals |
| Evidence | Source links, browser state, retrieved context | Makes review explainable |
| Side effect | The system or customer-facing change | Keeps risk concrete |
| Credential | Placeholder or scope, never raw secret text | Keeps approval separate from secret exposure |
| Audit trail | Decision, actor, time, and result | Supports later debugging |
Relative review quality
The practical test is simple: after reading a checkpoint, a team should know what changes, who approved it, and which adjacent record helps them investigate later.