AI memory is governed data selected for a purpose, not an unlimited transcript. Tools are application-owned capabilities with typed inputs, narrow permissions, limits, and audit. Consequential actions become proposals that a policy or authorized human approves before idempotent execution. PostgreSQL stores state, provenance, retention, decisions, and outcomes; the model never grants itself authority.
Memory types:
Never convert a model inference into a durable customer fact without validation and provenance.
A tool definition names capability, input schema version, required permission, maximum scope, timeout, idempotency behavior, and output schema. A request creates tool_proposals; policy may auto-deny, auto-approve low-risk actions, or await a human. Execution verifies proposal version, approval, actor, expiry, current authorization, and target version inside a short transaction.
Unique (organization_id, idempotency_key) plus a request hash prevents duplicate effects. Audit rows record proposal, model/prompt, evidence, approver, policy version, executor, database outcome, and external-effect reference.
The system is designed around probabilistic proposals and deterministic authority. A model can draft a reply or suggest priority; it cannot bypass tenant policy, approve its own refund, or rewrite audit history. Memory quality and tool success become evaluated data products.
Test duplicate execution, expired approval, revoked approver, changed ticket version, cross-tenant target, malformed model output, executor crash, and external timeout. Only one allowed effect may commit, and every denial must be auditable without logging unnecessary sensitive content.
Model a “draft and send customer reply” workflow where drafting is automatic but sending needs an agent.
Acceptance criterion: stale/edited drafts require reapproval, duplicate sends are impossible or idempotent, and approval shows exact content/recipient/source citations.