Memory governance for AI agents
Gromani is building a memory layer that sits between an agent and its memory store, designed to keep long-running work accurate as information changes. It decides what to retain, update, forget or escalate to a person, and keeps the record of why.
In development. Scroll to see a memory governed.
01 / Retain
Every memory is written with its source, the conditions it applies under, a confidence score and a privacy class. Nothing enters the store without a reason the audit trail can show.
op=retain aud_4q8r2m1c rule=R7 ts 2026-11-02T09:14:02Z subject repo:atlas-api memory "API v2 ships behind flag billing_v2" src pr-review#4412 auth=maintainer conf 0.91 class=internal policy=default@3
02 / Update
When a newer statement conflicts with an older one, Gromani checks authority and scope before it commits a lasting change, and is designed to leave what is still true alone. The old memory stays on the lineage, so you can see what was believed, and when.
op=update aud_9x1k7d3p rule=R5 ts 2026-11-02T09:16:40Z subject release:atlas-2.4 memory "target 04-Dec" → "target 11-Dec" src standup-notes auth=owner ≥ owner lineage supersedes=mem_7f21
03 / Forget
Retention windows, privacy classes and deletion requests all remove memories. The fact goes. The audit entry that it existed, and was removed, stays.
op=forget aud_2m6v8t0s rule=R2 ts 2026-11-02T09:18:05Z subject incident:inc-2291 memory mem_a9c4 "rate limit off on /export" reason retention-window elapsed 2026-10-15 audit tombstone=kept
04 / Escalate
When the evidence is unclear, or a change matters too much to guess, Gromani asks a person instead of silently rewriting memory. The agent carries on with what it already knows, without acting on the disputed change, until someone decides.
op=escalate aud_7c3n5w2e rule=R4 ts 2026-11-02T09:21:33Z subject pricing:enterprise-tier memory "enterprise discount approved?" src agent-note auth=inferred conf 0.42 < 0.70 queue=review/product
Try a memory decision
An illustration: scripted scenarios against a seven-rule toy policy, not the Gromani engine. Statements, confidence scores and source labels are predefined here. Working those out from real project conversations is the hard part, and it is what we are building.
update
rule R5Committed as a lasting change. The previous memory stays on the lineage.
Newer statement from owner supersedes mem_7f21 (owner, 2026-10-21). The old memory stays on the lineage.
“Release target 4 Dec” → “Release moves to 11 Dec after the load-test regression.”
Request
POST /v1/memories:propose{ "subject": "release:atlas-2.4", "statement": "Release moves to 11 Dec after the load-test regression.", "source": { "channel": "standup-notes", "authority": "owner" }, "confidence": 0.93, "class": "internal", "approved": true, "existing": "mem_7f21" }
Audit entry
deciding…
Join the waitlist for early access. We are starting with agents for product development, operations and support, where a wrong memory costs something.
Join the waitlist