Not every write FilepadAI or a connected agent makes lands immediately. Higher-risk actions — editing an existing document, moving or deleting files — can pause and ask for your approval first. This guide covers how that review works and how to review effectively.
What triggers a review
Every action is classified by risk. Most reads and some low-risk writes apply immediately. Actions that touch existing content more meaningfully — editing a document, restructuring files — can come back as approval_required instead of applying right away. A small set of destructive actions (batch deletes) always require approval, no matter who's asking.
Reading the diff
When you open a pending approval, you'll see the change line-by-line:
- Lines starting with
+are additions (shown in accent color) - Lines starting with
−are removals (shown in error color) - Context lines show unchanged surrounding content
Each pending change is attributed to whoever (or whatever) requested it — FilepadAI, an external agent, or a workflow — and timestamped.
Accepting a change
Approve it. The change is applied and creates a new version of the artifact, logged in the audit trail.
If the change is almost right but not quite, approve it and edit the artifact directly, or reject it and adjust your instructions before re-running.
Rejecting a change
Reject it. Nothing is applied. The rejection is logged, and the artifact stays on its previous version.
Do not reject silently. If a change is wrong, it usually means the instructions, memory, or context the agent had were off. Ask FilepadAI to help diagnose why.
Asking FilepadAI about a pending change
Before approving or rejecting, ask FilepadAI why the change was proposed:
"Why did the research agent want to change the pricing section?"
FilepadAI can use workspace context and activity history to explain what it's looking at.
Submissions vs. approvals
Two different review flows exist, and it's worth keeping them separate:
- Approvals gate risky writes from FilepadAI or connected agents — this page.
- Submissions are for shared workspaces: a human contributor drafts into their own space and a moderator (Editor/Admin role) approves the draft into the shared tree. This is people reviewing people, not agent governance.
Team access and roles
Workspace members with Editor or Admin roles can review and approve pending changes. Viewer roles can see them but cannot approve or reject.
Assign reviewers intentionally. Whoever reviews memory changes should understand what the workspace is supposed to know.
What the audit log records
Every governed action is logged:
- Change requested (actor, artifact, timestamp)
- Change approved or rejected (user id, timestamp)
- Direct writes that didn't require approval
- Agent Access key creation, rotation, and revocation
The audit log is available to workspace admins.