Module guide
Agent governance
Human-in-the-loop approvals, memory, and an activity log for AI agents.
Overview
Agents in Atlas request human sign-off before taking consequential actions. AgentApproval gates those calls, AgentMemory persists key facts across runs, and the activity log exposes every recent AgentRun for audit. Everything is deterministic: approvals are a state machine and memory is explicit key/value.
Highlights
The capabilities worth knowing before you dive in.
- Approval gate: PENDING to APPROVED or REJECTED, with an optional note
- Per-user, per-agent, and per-tenant memory scopes
- Double-decide guarded: a decided approval cannot be re-decided
- Activity log filtered by agent and limit
Important to know
Limits, permissions, and sharp edges to keep in mind.
- Memory is idempotent on (tenant, scope, key, agent); an upsert replaces the value.
- Approvals survive a service restart because they're DB-backed rows, not in-memory queues.
How to use it
The primary workflow, start to finish.
- An agent emits an approval request, which appears in /settings/agents.
- A reviewer approves or rejects it with an optional note.
- The agent resumes on approval; nothing happens on reject.
FAQ
- What stops an agent doing something consequential without me?
- An approval gate. A consequential call creates an approval that a person moves from pending to approved or rejected, with an optional note, and the agent proceeds only on approval.
- Can an approval be reversed after somebody decides it?
- No. A decided approval cannot be decided again. That is deliberate, so the record of who allowed an action and when cannot be rewritten afterwards.
- Does an agent forget everything if the service restarts?
- No. Memory and approvals are database rows rather than in-memory queues, so both survive a restart. Memory is explicit key and value, scoped per user, per agent or per tenant, and writing the same key replaces the value.
Automate this module