Memoato started with a simple idea: write what happened in normal language and make it useful later.
I did not want another habit tracker with more forms, streaks, and dashboards. I wanted somewhere to write a messy note like low energy today, skipped the gym, walked after lunch, slept badly, big client call in the morning and preserve the context that specialized apps usually miss.
That still matters. In fact, it matters enough that it changed what I think Memoato should become.
Memoato is moving from a personal memory app toward a trustworthy context product for people, teams, and AI agents. This is not a reset and it is not a move away from personal memory. The personal product is the first workspace and the place where the hard parts became visible.
The pivot is really a sharper answer to one question: what does useful memory require before a person or an agent should trust it?
The first version solved capture
The earliest version of Memoato looked more like a flexible tracker. It had categories, amounts, goals, charts, schedules, and a timeline. That was useful, but it still asked the user to decide the structure before saving what happened.
Real life does not arrive in database columns.
A single note can contain movement, mood, pain, a person, a place, a constraint, and a reason something changed. Forcing that note through a category form loses the relationship between those details. It also creates friction at the exact moment when capture should be effortless.
So the product moved to a raw-first model:
- Save the original words immediately.
- Extract facts and labels in the background.
- Keep uncertain interpretations separate.
- Let the user review, fix, or ignore derived facts.
- Use those facts for recall without hiding the original evidence.
That sounds like a UX improvement. It turned out to be an architectural principle.
The hard problem was not extraction
It is easy to demo an AI model turning a paragraph into structured JSON. The demo gets much less impressive when the model labels something incorrectly, invents a relationship, merges two events, or returns the right answer for the wrong reason.
Once Memoato could extract facts, the important questions changed:
- Can I see the exact note behind this fact?
- Was this read by a local rule, a model, or a human?
- Has the user corrected it?
- Is it accepted, uncertain, rejected, or stale?
- Can I delete or edit the original without leaving misleading derived data behind?
- Why did this memory appear in a recall result?
Those are not model questions. They are data ownership, provenance, review, and retrieval questions.
The original note has to remain canonical. Extracted facts must stay linked to it. Inferences must not quietly become facts. Search embeddings need to be rebuildable projections, not the only copy of what the system knows. AI output can propose an interpretation, but evidence and policy decide whether it becomes durable context.
This is where Memoato stopped looking like a smarter tracker and started looking like context infrastructure.
Recall exposed the wider product
Capture is only half of memory. The other half is finding the right detail when the question was not known in advance.
Memoato recall now combines raw entries, reviewed facts, stable concepts, lexical search, typo tolerance, Croatian and English aliases, and multilingual vector search in PostgreSQL. AI synthesis is optional and receives only the evidence already selected for the user.
The order matters. The system retrieves evidence first. A model may summarize that evidence afterward. The summary is never allowed to replace the sources that support it.
While building this, I realized the same contract applies to coding agents and teams.
A person may ask Memoato, what usually happened before my low-energy days? An engineer may ask an agent, why does this service retry payments three times? These are different domains, but the trust questions are similar.
- Which source supports the answer?
- Who is allowed to see that source?
- Is the source still current?
- Did a human approve the durable conclusion?
- What changed since the last answer?
A context window full of text does not answer those questions. Neither does a vector database by itself.
One Memoato, not two products
The obvious temptation was to split the idea. Keep the personal app under one brand and build a separate team context product beside it.
I decided against that.
There is one Memoato. memoato.com explains the product, app.memoato.com is the unified application, and api.memoato.com is the scoped API and MCP surface.
Personal memory is the first workspace, not an old app waiting to be removed. It keeps the capture, memory review, recall, views, privacy modes, and existing data. Team and project context become additional workspace types only when their permission and evidence boundaries are ready.
This matters because personal memory is not just a convenient MVP. It forces the product to handle ownership, correction, deletion, language, imperfect input, and sensitive data from day one. Those constraints are useful preparation for a trustworthy team product.
What the broader architecture adds
A personal note belongs to one user. Team context is more complicated. A GitHub organization, repository, Linear team, ticket, pull request, and decision can all have different visibility and authority.
Memoato therefore needs structural concepts that cannot be faked with tags:
- Workspaces and members define identity, role, and membership state.
- Source connections define a read-only boundary to systems such as GitHub and Linear.
- Source objects and immutable versions preserve what was observed and when it changed.
- Claims and evidence separate a useful conclusion from the records that support it.
- Retrieval traces record the permission snapshot, policy, filters, and ranking used for a request.
- Context packets return visible claims, evidence, freshness, exclusions, and a memory diff.
The most important rule is that permissions are filtered before ranking, reranking, and synthesis. Restricted information must never enter the candidate set and influence an answer that is cleaned up later.
The first team vertical slice is deliberately read-only. Memoato can connect an allowlisted GitHub scope and Linear team, preserve versioned records, propose claims, require human review, build a permission-filtered context packet, and show what changed between packets. Permission-leakage and stale-context evaluations are part of that work.
Autonomous writes are not the milestone. Trustworthy reading comes first.
Why PostgreSQL remains the center
It would be easy to make the pivot sound more dramatic by adding a graph database and describing everything as an AI-native memory engine.
I do not think that would improve the product today.
Memoato's core relationships fit relational data well: raw entry to facts, facts to entities, claims to evidence, users to workspaces, members to permissions, sources to immutable versions. PostgreSQL already gives the product transactions, constraints, full-text search, fuzzy matching, and pgvector.
Using one canonical database also keeps backup, deletion, export, migration, and privacy behavior understandable. A graph database can become useful later if measured multi-hop retrieval requires it. Adding one before that would create dual-write and consistency problems without proving user value.
The architecture should become more sophisticated only where the trust contract requires it.
The model is replaceable
Memoato uses deterministic parsing first and calls OpenRouter only when an entry is ambiguous, low-confidence, or contains several contexts. Clear inputs should not wait for an AI round trip. Raw capture should never fail because a model provider is slow or unavailable.
The same principle applies to recall and team context. Models will change. Embedding models will change. Context windows will get larger. Agent frameworks will come and go.
The durable part is the contract around them:
- raw evidence remains inspectable
- derived meaning is reviewable
- permissions are enforced before retrieval
- stale context is visible or excluded
- corrections and decisions leave an audit trail
- model output is never canonical without evidence and policy
That is the product I find much more interesting than another AI chat interface.
What the pivot does not mean
Memoato is not trying to replace GitHub, Linear, Obsidian, Todoist, Calendar, email, Garmin, or Strava.
Those products already own valuable source data. Memoato should preserve the missing human context between them, connect claims back to evidence, and give people and agents a safer way to recall what matters.
It is also not trying to remember everything forever. Good memory needs correction, expiration, supersession, and deletion. Maximum retention is not the goal. Dependable recall is.
Finally, it does not mean the personal app becomes secondary. The personal loop is still the product proof: write naturally, keep the original, review what the system understood, and find it later with evidence.
Where this is going
I now think of Memoato as a private context layer that can serve both humans and their tools.
For one person, that means remembering the detail that trackers and calendars missed. For a software team, it means giving an agent a permission-safe packet of current claims and inspectable evidence. In both cases, the value is not that AI remembered something. The value is knowing why the memory deserves trust.
The implementation is open source at hrvojepavlinovic/memoato-app. The broader research is public in the Trustworthy Agent Memory and Context guide.
Memoato began as a way to remember messy life context. The pivot is realizing that trustworthy context is a much larger product, and the small personal app already contained the right first principles.