Vendor memory answers the wrong question for a team

Open the second tool you use. Not the assistant you settled things in last week, the coding agent in a different harness. Ask it what you decided about the pricing page.

Say you settled it recently. The team went back and forth on the layout, you landed on the two-column version with the annual toggle on the right, and you told the assistant you keep open all day. It remembered. The next session it still knew, and it stopped asking the questions you had already answered.

Now the agent that has to ship the change. It reads your repo, follows your instructions, and has never heard of the pricing decision, because the decision lives inside another product and nothing carried it across.

Both tools are behaving correctly.

The question vendor memory answers is "what does this assistant know about me." A team that runs more than one vendor, or more than one person, keeps asking a different question, "what did we decide." That question has no vendor home, and it is already half-built in the AGENTS.md sitting in your repo right now.

What vendor-native memory covers today

Both Claude and ChatGPT ship memory features, and for work that lives inside one vendor's product, they cover it. The assistant stops asking which framework you prefer. You stop re-explaining the constraints of your codebase at the start of every session. It remembers the naming convention you mentioned once and applies it the next time you ask for a component. Inside one product the loop closes. For a solo developer whose work never leaves one harness, this genuinely settles things. The memory is doing exactly what it was built to do. The boundary is the product line, and no vendor's product line is your team's boundary.

What it does not settle: the cross-vendor decision

Run the test again. The decision exists. Your team spent a meeting on it, somebody typed the conclusion into one assistant, and it is out of reach from the second harness, because it was never written anywhere that harness can read.

There is a second boundary, quieter than the first. Memory follows the person and the product. A decision belongs to the team. Even inside one vendor, your assistant's memory is yours, not your teammate's, so the question that fails across vendors also fails across desks the week the person who made the call is out.

This is where the rebuild tax shows up. The context your team rebuilds at every stack change is the asset you keep losing, paid in engineering-months, with no invoice. The decision gets made a second time, or a third, by whoever is standing closest to the new tool, and the person who already made it pays without ever seeing the invoice.

What a company layer still owns

A company-scope context layer owns decisions shared across vendors and people, one place every tool and every person reads and writes, above any single vendor's product.

Before arguing for that, concede what you already built. Markdown in git, a /memory directory, a root AGENTS.md that every agent loads on every session. Another practitioner, formerly_proven on the same forum, argues the opposite case. "There's a pattern where people create AI-specific infrastructure for coding agents which is essentially instantly obsolete because it's pointless." I would take the other side of that, for one narrow reason. A file in the repo is the only thing in most stacks today that every vendor's agent can read. That makes it the first draft of a company layer, not a dead end.

The boundary is the second author. The rule written in five seconds gets worked around for ten weeks. A teammate six months in adds a contradicting rule, and the team re-litigates what it had already closed, because a text file can describe a decision but cannot hold the team to it. The file works at single-player scale, and it keeps working until someone else needs the same decision you made.

This is what we built for that boundary: a company-wide context substrate, snips, bases and projects with hybrid search, that people and AI agents read and write from the same place. The repo file stays. The decisions stop living in one head or one product.

Whether a platform will absorb the company layer

Paul Dix, co-founder and CTO of InfluxData, said it on The Changelog. "But I think within two or three years, maybe a lot of that gets eaten by Anthropic, Google and OpenAI." Whether a platform absorbs this layer is currently unanswerable. I want to say that plainly, because the honest position is that he might be right.

Here is the argument I can offer, held as an argument rather than a proof. A model vendor is best positioned to ship memory for its own agent, and that is the half of this category absorption will most naturally eat. The other half is a store that people and every vendor's agents write into together. That is the half a model vendor is least incentivized to build, because its value shows up when a team also uses somebody else's model, and no vendor's quarterly goal is to make a competitor's agent more useful. Incentives are arguments, not roadmaps. They are the reason to keep the substrate above any single vendor, and to keep asking the question even if the answer someday arrives.

When vendor memory is all you need

There is an honest threshold, and it sits lower than a piece like this suggests. If your work lives inside one vendor's product and one person makes the decisions, use vendor memory and stop reading. A company layer is overhead, and you do not owe anyone overhead.

The threshold is crossed by either of two things. A second vendor, because now a decision has to travel between products that do not share memory. Or a second person who needs the same decision, because memory that follows one person has to start answering to the team. Cross either line and the question changes shape. The assistant knowing things about you stops being the point, and the team having one place where decisions live becomes the point.

Run the test. Ask the second tool what you decided, and count the places a decision lives.

<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "BlogPosting", "headline": "Vendor memory answers the wrong question for a team" } </script>