An AI system can turn a note into a clean summary in seconds.

That does not make the summary a trustworthy memory.

The harder product question is what happens after generation. Can a person still see what they originally wrote? Is a structured detail a reviewed fact or an uncertain interpretation? Can it be corrected without erasing the evidence? Which parts may an external agent retrieve?

Memoato is where we put those questions under real product constraints.

It is currently a personal memory product, not a finished context platform for software teams. Personal memory is the first workspace because it gives us a concrete place to test capture, interpretation, review, retrieval, and external access without hiding the trust model behind an enterprise claim.

Evidence, fact, and inference are different records

Consider a short entry:

Rough night. Big call at nine. Skipped the gym, but walked for 20 minutes after lunch. Energy came back by dinner.

The original words are evidence. “Walked for 20 minutes” can become a structured fact. A possible relationship between sleep, the call, and energy is an inference.

Those records should not collapse into one generated memory.

Memoato preserves the raw entry first. Reviewed facts are stored separately from it. Inferences have their own record type and point back to supporting entries. Processing runs and human corrections are recorded as part of the path from source to current interpretation.

That separation creates a useful property: processing can improve without rewriting history.

Recall should return a reason

Compact answers are convenient, but a memory result should not ask the caller to trust the answer on presentation alone.

Memoato recall keeps source evidence available with the result. External recall is limited to accepted facts, while the raw entry remains visible for inspection in the product. This gives a person or connected agent a way to check why a result was returned.

Search embeddings are treated as rebuildable projections. PostgreSQL remains the canonical store for raw entries, reviewed facts, corrections, inferences, processing runs, and the data needed to reconstruct search.

This boundary matters. A vector index can be useful for retrieval without becoming an opaque second source of truth.

Agent access is a product boundary

Memoato exposes an HTTP API and MCP access for connected agents. Keys can be scoped to:

  • logging new raw entries
  • recalling accepted facts and evidence
  • both capabilities

A capture-only integration does not need access to recalled personal facts. A recall-only tool does not need a write path. Combining the two is an explicit choice rather than the default.

This is a small access model, but it proves the principle in working code: permissions belong in the context architecture, not only in the prompt that describes how an agent should behave.

What this does and does not prove

Memoato already implements a useful foundation for trustworthy personal memory. It does not yet prove permission-aware context across teams, repositories, tickets, chat, and internal documents.

That next layer needs more structure: workspace roles, source-level permissions, immutable source versions, precedence between conflicting claims, freshness rules, and retrieval traces that preserve the actor and permission snapshot.

The current architecture gives us a base for that direction because evidence, interpretation, corrections, search projections, and access are already separate concerns. The remaining work should still be described as product direction, not shipped functionality.

For the detailed implementation view, read the Memoato case study. The product is open source on GitHub, and the wider research is published in the Trustworthy Agent Memory guide.