Why we built 1on1 to read prior sessions, not transcribe meetings

Most AI built for 1:1s reads one meeting at a time. You finish a session, the tool transcribes or summarizes what was just said, and you get a tidy recap of that single conversation. It is useful, and it is also the wrong unit.

A 1:1 is not a one-off meeting. It is the latest entry in a relationship that has been running for weeks or months. The thing a manager actually needs help with is rarely "what did we say today." It is closer to "what has been happening between us, and what keeps slipping." That signal does not live in any single transcript. It lives across sessions.

So when we built the AI in 1on1, we made a different bet: recurring context first, better transcription second. The product reads the history of the manager-report pair, not just the meeting that ended a minute ago.

Why single-meeting AI is the wrong unit

A summary of one meeting can only tell you about that meeting. It cannot tell you the things that become visible only when you line several sessions up next to each other.

Consider three signals, each invisible inside a single recap.

The first is a repeated blocker. A report mentions the same dependency holding up their work. Once, it is a status note. When it surfaces for the fourth session in a row, it is a pattern, and probably an organizational problem rather than a personal one. A single-meeting summary treats the fourth mention exactly like the first.

The second is an action item that keeps slipping. Something gets agreed to, then quietly does not happen, then gets re-agreed the next session with slightly different words. Read one meeting at a time, each instance looks like a fresh commitment. Read across sessions, it is the same item failing to close three times running.

The third is the direction of the session itself. If you attach a simple 1-5 read to each meeting, one number on its own means little. A read that drifts from 4 down to 2 over six weeks means a great deal, and you can only see that drift by comparing sessions.

Those examples are illustrative, not numbers from real accounts. They describe the class of signal that single-meeting AI structurally cannot produce, no matter how good the summary of any one meeting gets.

What "reads prior sessions" actually means

"Reads prior sessions" is a claim, so here is what it concretely does.

When a session ends, the pipeline assembles context for that specific manager-report pair. It pulls the prior sessions in the series, with the most recent few included in full answer-level detail and older ones carried as summaries and scores to stay within a sensible budget. It includes the action items across the whole series, each tagged with whether it is open or closed and which session it came from. And it includes the trend in the per-session rating, so the model can reason about direction rather than just the latest point.

All of that goes into one structured call to Anthropic's Claude ^source, which returns the session summary, key takeaways, suggested action items, the 1-5 rating, and a separate manager-only addendum. Session content is sent to the model in real time, is not used to train it, and is not retained by the provider ^source.

The hard part is not the call. It is the shape of the input and output. The schema was built for a recurring relationship between two specific people, so the model reasons over a thread instead of an isolated transcript. A generic meeting-summarizer can be pointed at a 1:1, but it was designed for the meeting, not for the relationship the meeting belongs to.

The boundary that matters

The output splits in two, on purpose.

The session summary, with its takeaways, decisions, and action items, goes to both people. Manager and report see the same shared record, which is the whole point of having a record.

The addendum is different. It carries a short sentiment read, a few risk indicators, and up to a few coaching suggestions, and it is meant for the manager alone. The report's view never includes it, and access is restricted to the manager (and admins) on the server. This is not the AI watching the report. It matches what managers already do when they keep private notes after a 1:1, except the notes now live in a governed place instead of a personal document.

Two things underneath that are worth stating plainly, because they are the substrate rather than the addendum rule. Tenant data is isolated by Postgres row-level security at the database layer, and a manager's private notes are encrypted at rest with per-tenant keys ^source. The access boundary on the addendum is enforced in the application; the isolation and encryption around it are enforced lower down.

The risk, and the limit

Two honest caveats.

First, AI summaries are easy to buy now. If the pitch were "we summarize your meeting," that would be easy to match by next quarter. The useful difference is in the input: prior sessions, action items, and the rating trend for the same manager-report pair, assembled before the model writes the summary.

Second, this is not magic, and it does not work on day one. Recurring context needs recurrence. One session gives the model almost nothing to compare against. The signal starts to appear around the third or fourth session, which is why we treat session 4 as the minimum interesting unit rather than session 1. If you judge the AI on its read of a first meeting, you are judging it on the one thing it was not built to do well.

If you are evaluating tools for your 1:1s

One question separates a memory product from a transcription product with a summary feature: what does your AI read.

If the answer is "this meeting," you are looking at a single-meeting tool, however good its summaries are. If the answer includes prior sessions, the open and closed action items between them, and the trend across the relationship, you are looking at a product that can reason over the thread instead of only the latest meeting.

You can test ours on exactly that, with one manager and one report, before changing anything for the rest of the team ^source.