Agent Capstone: Durable Memory with Approval Gates
Build an assistant that remembers approved user preferences and prior cases, retrieves allowed tools, proposes actions, and requires approval for high-impact effects. pgvector supplies semantic candidate retrieval; PostgreSQL supplies identity, validity, row security, transactions, and audit. Completion requires correction, expiry, deletion, injection, authorization, idempotency, and partial-failure evidence.
What is the mission?
The agent helps a user prepare and execute business tasks. It may remember an explicitly confirmed preference, recall a reviewed prior outcome, and suggest an approved tool. It may not infer sensitive permanent profiles, grant itself a capability, expose another user, or execute a risky action without exact arguments and valid human approval.
What are the core data contracts?
- Memory: subject, tenant, type, content, source event, confidence, sensitivity, validity, consent, status, model, vector.
- Tool: versioned name, description, typed schema, risk class, environment, allowed principals/scopes, approval rule.
- Proposal: goal, selected tool/version, typed arguments, evidence IDs, policy decision, expiry.
- Approval: approver, exact proposal hash, scope, time, expiry, decision.
- Execution: idempotency key, authorization snapshot, attempt, outcome, side effects, compensation, audit ID.
What are the milestones?
- Create two-user RLS fixtures and memory consent policy.
- Implement candidate, approval, correction, supersession, expiry, and deletion.
- Add semantic retrieval filtered by subject, validity, status, and sensitivity.
- Build a tool catalog with no credentials in descriptions.
- Retrieve tools under policy and validate typed proposals.
- Build an approval UI/API showing exact arguments and consequences.
- Recheck authorization and approval immediately before execution.
- Add idempotency, timeout ambiguity, compensation, and audit.
- Red-team memory/tool injection and poisoned prior cases.
- Run load, recovery, deletion, and rollback tests.
What are the launch gates?
- zero cross-user/tenant memory or tool exposure;
- prohibited memory categories never persist;
- correction and deletion propagate within SLO;
- every high-impact action has valid proposal-bound approval;
- duplicate calls produce at most one side effect;
- stale approvals and changed resource state fail closed;
- complete audit reconstruction without secrets;
- recovery preserves or safely reconciles idempotency state.
What adversarial cases matter?
Memory saying “ignore policy,” a tool description containing secret-looking text, similar names across tenants, approval for altered arguments, expired consent, poisoned successful-case memory, network timeout after side effect, replayed execution, and partial compensation.
How do you verify it?
Demonstrate one complete trace from user goal to memory/tool candidates, policy, proposal hash, approval, execution-time decision, idempotent action, result, audit, correction, and deletion. Then demonstrate each failure path with the expected fail-closed behavior.
What breaks in production?
- The model stores every conversation fact.
- Similarity retrieves the right tool but policy is skipped.
- Approval applies to a mutable proposal.
- Timeout retries duplicate side effects.
- Prior successful outcomes become unquestioned procedures.
AI pair-work prompt
Review my agent capstone as a safety engineer. Trace identity, memory consent, retrieval filters, tool policy, proposal immutability, approvals, execution-time checks, idempotency, compensation, audit, correction, and deletion. Produce adversarial timelines and block launch on unproven gates.
Verification contract: High-impact execution must remain impossible when the model, memory, retrieved document, or tool output is malicious.
Check your understanding
- What binds an approval to exact action arguments?
- Why reauthorize at execution time?
- Which states support memory correction?
Official references