Every product org runs on knowledge that lives in exactly one head. The PM who was on the customer call knows why the integration was descoped. The designer knows which flow the CPO rejected in March, and why. The engineer knows the migration is blocked on a vendor, not on the team. None of it is written down anywhere a colleague would find it, so the org keeps paying the same costs: the same debate re-litigated a quarter later, a commitment made to a customer that contradicts one made last month, a new hire who takes eleven weeks to become useful, and a decision quietly reversed because nobody remembered what the original evidence was.

That is the silo problem, and it is not a documentation problem. Teams already write things down. The issue is that what gets written is scattered across tools, undated, unlinked, and stale within weeks, so nobody trusts it enough to look. What a team actually needs is organizational memory: a shared, durable, current record of what the company knows and decided, maintained without anyone volunteering to maintain it.

What organizational memory gives a team

Once shared memory exists and is trusted, four things change:

Decisions outlive the people in the room. "We chose usage-based pricing in March, and here is what we believed at the time" survives reorgs, holidays, and turnover. The reasoning is recoverable, not just the outcome.

Nobody re-litigates settled questions. The most expensive meeting in a product org is the one that reaches a conclusion the company already reached. Shared memory makes the prior conclusion, and the evidence behind it, retrievable in seconds.

Customer context stops being one person's property. Any teammate can answer what a named account needs, what was promised, and what state the relationship is in, without waiting for the account owner to come back from leave.

Onboarding compresses. New hires ramp against the actual decision history of the company rather than a wiki that stopped being true in Q1.

And there is a second-order effect that matters more every quarter: your AI assistant becomes useful at the level of the company rather than the level of the chat window. An assistant that only remembers your conversation with it is a very fast intern who has never met your team. An assistant with organizational memory answers roadmap and customer questions the way a well-briefed colleague would.

The work does not happen in the chat window

Here is the constraint every AI memory feature runs into. The facts worth remembering are almost never typed into the assistant. They are said on a call, argued in a thread, recorded in a ticket, drawn in a doc, and merged in a pull request. Memory built only from chat transcripts captures a thin slice of the company and misses the substance.

So Second Axis builds memory from the systems where work actually happens. You link the sources you want it to read, and a scheduled pass does the reading.

How Second Axis builds organizational memory from meetings, chat, tickets, docs, code and product data

Two properties of that pipeline are worth stating plainly, because they are the ones enterprise buyers ask about first. It reads only the sources you explicitly link, enforced by what the running agent is technically able to reach rather than by instructions in a prompt. And it never copies your documents into memory: what gets stored are facts and pointers, not content lifted out of your systems of record.

Personal and organizational memory are different products

Every memory is either personal or organizational, and the distinction is decided by who the fact is about, not by which tool it came from.

Personal memory is about you: your role, how you like specs written, which tools you prefer. It is yours and nobody else sees it.

Organizational memory is about the company: strategy, funding, customers, competitors, product direction, who owns what. It is shared with your team, and it is the half that makes the assistant useful to an org rather than an individual.

Shared scope is also where the hard problems live. A fact about someone's compensation, health, immigration status, or performance must never surface in a teammate's sidebar, and "we told the model not to" is not a control. In live chat the human is the gate: an organization-scope write pauses on an approval prompt you see and decide. Scheduled passes have no human present, so three independent layers replace that gate, each an enforced hook the agent cannot skip:

a pattern guard that blocks the obvious categories before the write lands,
an independent reviewer agent, with write access removed at the platform level, that reads every shared write cold the way a teammate would and returns keep or remove verdicts,
a stop gate that refuses to let the pass finish while shared writes sit unreviewed.

The same pass runs inside a write fence: read-only against the outside world, with write access to the memory store alone. An agent whose job is reading your meetings has no business renaming them.

That is the product. The rest of this post is how it works underneath, which matters if you are evaluating whether a memory layer will still be correct in month twelve.

The unit: one fact, self-contained, dated

Every memory is a single fact that stands on its own:

"Second Axis moved its weekly advisor sync to Wednesdays as of July 2026."

Not a paragraph covering four topics. Not "he prefers the other format" with no antecedent. One fact, full names, and a date on anything that can go stale.

This is a retrieval constraint rather than a style preference. A memory is found by matching a search against its whole text, so a memory covering three topics matches all three weakly and none of them strongly, which makes it unfindable for every fact it contains. Extraction is hard-lined on this rule: if a memory needs "and" or a bullet list to hold together, it is more than one memory.

Two axes, because one taxonomy always fails

Every memory carries two independent labels:

What kind of statement it is: identity, preference, decision, fact, context, or reference.
What it is about: product, engineering, roadmap, customer, sales, marketing, competitor, team, process, company, finance, or general.

A decision about a customer is decision by kind and customer by subject. A metric about the pipeline is fact by kind and sales by subject. Collapsing these into a single taxonomy forces the bad trade you would expect: either you cannot find all decisions, or you cannot find everything about a customer.

Retrieval deliberately does not filter on these labels up front. We measured that version against the alternative, and guessing the category first lost facts, because a wrong guess makes them unreachable. Instead, search casts wide and returns a facet breakdown ("40 of these matches are filed under customer"), and the agent narrows in a second step when it needs to.

Time is a first-class dimension

Facts are not overwritten. They are superseded.

When pricing changes, the old memory is not edited. A new memory is saved that supersedes it, the old one leaves the live search surface, and the two stay linked in a chain. That chain is the decision timeline: what the company believed in February, what replaced it in March, and when. "What is our pricing" returns one current answer. "How did our pricing evolve" returns the history.

Deletion works the same way. Memories are retired with a recorded reason, never silently removed, because an audit trail you cannot explain is not an audit trail.

Superseding facts, entity cards, the alias registry and reference change logs

Cards: the ledger stays, the synthesis is maintained

Six months of working with one customer produces dozens of dated episodic memories. "What is the state of that account" should not return an arbitrary five of them and force the model to re-synthesize an answer every time.

So a consolidation pass maintains entity cards: one living summary per entity that matters, covering what it is, its current state, and the compressed arc, updated through the same supersede mechanism, with the episodic memories underneath as its evidence. Episodes grow linearly forever. Cards stay proportional to the number of entities you actually work with, which is what keeps retrieval sharp in month twelve instead of only in week two.

The same pass compresses redundancy where it costs most. Identity facts pinned into every prompt get deduplicated, and high-frequency operational noise, one memory per commit or per standup, gets rolled up into weekly summaries with the originals chained underneath rather than deleted.

Names are the hard problem nobody warns you about

Your sources disagree about what things are called. Meeting transcription mishears company names. Repos use slugs. Chat uses nicknames. Every unresolved variant silently creates a phantom entity, a second copy of a real customer whose facts never rejoin the original, because nothing links the two strings.

We hit this on a real store during testing: a customer's closed pilot, recorded under a name the transcription service invented, invisible to every search for the real company. Two failures at once. The customer's card was missing its most recent state, and "which customers do we have" returned a company that does not exist.

The fix is an entity registry: canonical names, aliases, and a one-line description per entity. Before saving a fact, names are resolved against it. Retrieval expands queries through it, so a search under any recorded variant finds the canonical entity's memories, and that expansion happens before the query is embedded, because a vector built from a misheard name carries no signal about the real one.

What we refuse to automate is the merge itself. String similarity cannot tell a mistranscription from a genuinely different company, and merging two real entities is silent corruption, worse than the phantom it fixes. So the agent is the matcher: it judges from context (same deal, same people, same dates), verifies against the original source recording when a name looks garbled, and the registry records the verdict. Discovery of suspect names, by contrast, is deterministic code rather than agent judgment, because a phantom is only findable under the wrong name and no semantic search reliably surfaces it.

References: memory knows where truth lives

Some things should never be copied into memory: the spreadsheet that is the roadmap, the doc that is the pricing. Mirroring their contents guarantees staleness, since a copied status field is wrong the moment someone edits the source.

So memory stores references: pointers that name a thing, record exactly where it lives, and instruct the agent to open it live rather than answer from recall. When someone says "check the roadmap," the agent knows precisely which spreadsheet that word means. When the canonical location moves, the reference is superseded like any other fact, because where truth lives deserves a history too.

On top of references sits a change log. A daily pass checks each reference target. If the revision marker has not moved, the check costs one metadata call and stores nothing. If it has, the agent records the delta ("launch date moved, two rows added under Enterprise") as a dated entry. Retrieval surfaces the most recent entries inline whenever that reference comes back, with the full history one call away.

The storage rule is absolute: document content is never at rest in memory. Entries are capped at sentence scale, the structural fingerprint used for diffing is capped at a few kilobytes, and the log keeps a bounded window, so the document itself remains the only archive of its own content. Cost scales with how often things change rather than how large they are. A quiet ten gigabyte sheet costs one metadata ping a day.

Built on the same rails as the rest of the product

There is no separate memory pipeline service. Reconciliation runs in the same per-session agent sandboxes that power everything else in Second Axis, reading only your linked sources, writing through the same audited tools, with the same deduplication, validation and review on every path.

Long backfills covering months of meetings, chat and commits do not run as one overnight session, because we measured what happens to long sessions: they die, and take the night with them. A long window is split into bounded weekly slices, each an independent job that can fail, retry, or defer on its own. A crash costs one week of window rather than the entire run.

Where this sits

Most agent memory shipping today is personal memory: one user's preferences and facts, attached to a chat. That is the easy scope. The problems that define organizational memory only appear when memory is shared. A private fact reaching a teammate. A misheard customer name splitting six months of account history. A "current" number that three sources disagree about. A document that is the source of truth and must not be duplicated.

Everything above exists because of that scope. We have not found another shipping agent memory system that combines supersede chains, structural privacy review, an agent-judged entity registry and delta-only reference logs. If you know of one, we would genuinely like to read about it.

What we would tell you to steal

One fact per memory. Retrieval quality is decided at write time.
Supersede, never overwrite. The timeline is the product for anyone making decisions over months.
Separate what a statement is from what it is about, and filter after retrieval rather than before. We measured it. Guessing first loses facts.
Treat names as infrastructure. Phantom entities are silent and they compound. Let the agent judge merges, make discovery deterministic, and never merge on string distance alone.
Point at systems of record and log deltas. Never mirror documents into memory.
When no human is in the loop, make review structural. An independent reviewer plus a gate that will not lift beats a paragraph of prompt guidance every time.