Your Agents Don't Need Better Models. They Need a Shared Brain.

Last week I watched a compliance team spend three hours in a meeting explaining EU AI Act implications to their sales team. What they covered: which claims they can no longer make to European prospects, which features need human-in-the-loop before they can be sold, which contract language legal needs to review. Standard cross-functional knowledge transfer. The kind of meeting that happens in every enterprise, every week, across every department.

Three hours. Eight people. And by Friday, half of what was discussed had already been paraphrased incorrectly in a Slack thread, and nobody had told the two sales reps who were out that day.

Now imagine every team in that company also has AI agents. The engineering agents don't know about the EU constraints. The sales agents are still pitching features that legal just flagged. The marketing agent is drafting copy using language that compliance ruled out forty-eight hours ago. Each agent is individually capable. Collectively, they know nothing about each other.

This is the problem nobody's solving.

The wall

Every enterprise will deploy agents across every function within two years. The economics are too compelling not to. But there's a growing body of evidence that these deployments keep failing for the same reason, regardless of domain.

Jason Cui at a16z wrote about it for data agents this week. Their research found that most enterprise AI deployments "fail due to brittle workflows, lack of contextual learning, and misalignment with day-to-day operations." He walks through a specific example: a data agent that can't answer "what was revenue growth last quarter?" because it doesn't know whether revenue means ARR or run rate, which tables are canonical, or that the semantic layer was last updated by someone who left the company a year ago.

Harrison Chase, the CEO of LangChain, made a parallel argument about engineering teams. Coding agents have made implementation so cheap that anyone can produce a working prototype. But the bottleneck has shifted from building to reviewing — because the agents don't have the organisational context to know whether what they've built is well-architected, solves the right problem, or fits how the team actually works.

A research group at Oxford and City University of Hong Kong took this further. They proved that when agents cache and reuse knowledge they've learned, token usage drops by up to 80% while accuracy improves. But — and this is the part that matters — the knowledge only persists within a single agent's session. It never reaches other agents. It never reaches other teams. It dies when the process ends.

Three different groups, three different domains, arriving at the same conclusion. The bottleneck isn't intelligence. It's memory. Not the model's context window — the organisation's.

Where tribal knowledge goes to die

Right now, teams solve this with static files. Engineers write agents.md or .cursorrules files describing codebase conventions. Data teams maintain YAML semantic layers. Sales teams paste product docs into agent prompts and hope for the best.

This is the equivalent of onboarding a new hire by handing them a document last updated by someone who left the company eight months ago. Except you're doing it for every agent, in every team, every day. And nobody's checking whether the documents are still accurate.

It gets worse. Even if the docs were perfect, they're siloed. Engineering's context never reaches sales. Compliance's findings never reach product. Finance's cost analysis never reaches the team that caused the spike. The information exists somewhere in the org — it just doesn't travel.

And the most valuable context never gets written down at all. An engineer doesn't document "always check the rate limiter config before deploying." They just do it. A sales rep doesn't write "never lead with pricing on the first enterprise call." They just know. A compliance officer doesn't file a ticket every time they update their interpretation of a regulation. They adjust their mental model and move on.

Twenty years of asking people to write better documentation hasn't fixed this. It's not going to start working now that we also need to onboard a hundred agents.

What changes when knowledge travels

Go back to that compliance meeting I described at the start.

In the version of the world I'm interested in, the compliance agent reviews the EU AI Act, identifies the constraints relevant to the product, and commits its findings to a shared memory layer. Not to a ticket. Not to a Slack channel. To infrastructure that every agent in the org can query.

A sales agent preparing a pitch for a German prospect surfaces the EU constraints and adjusts its messaging without anyone telling it to. An engineering agent building a risk classification feature knows it needs human-in-the-loop before writing a single line of code. Marketing avoids the flagged language without a review cycle.

That three-hour meeting? It doesn't happen. Not because the knowledge isn't shared — but because it shared itself, the moment it was created, to everyone and everything that needed it.

The same pattern works across every boundary where knowledge currently gets stuck:

A security agent discovers a vulnerability in a dependency. Engineering agents working on affected services know immediately. Support can explain the situation to customers. Sales has the updated security posture for their next call.

A finance agent catches a 40% spike in cloud costs from a newly deployed pipeline. The team that shipped it finds out the same day — not three weeks later in a cost review that half the room hasn't prepared for.

A customer success agent notices three enterprise clients asking about the same missing feature in the same week. Product sees the demand signal. Engineering starts scoping. Sales knows the feature is coming when the fourth prospect asks.

Each of these happens today through meetings, forwarded emails, and Slack messages that get buried. It's slow, it's lossy, and it's exactly the kind of coordination work that agents should make unnecessary — if they had the infrastructure to carry it.

Privacy isn't optional

This is where "just use a vector database" thinking falls apart.

Not all knowledge should travel everywhere. Engineering's architectural decisions, sales playbooks, compliance working interpretations — these are team-private. They're where competitive advantage lives. They stay within the team's boundary.

Cross-functional knowledge — customer patterns, regulatory constraints, dependency vulnerabilities, product direction — benefits the whole org. Every agent and every person should be able to access it. But it never leaves the company.

And some knowledge is genuinely public. When one team discovers that a third-party API behaves differently than documented, or a library has an undocumented breaking change, that helps everyone. This layer is opt-in, anonymised, and community-driven.

Three tiers. Team-private, org-private, public. Without this structure, enterprises won't adopt shared memory at all. No serious company is going to pipe its tribal knowledge into a system without hard guarantees about what stays where.

The observation problem

Storage and retrieval are solved problems. The genuinely hard part is getting knowledge into the system without asking humans to write it down.

This is the part most people skip over. They assume you build a knowledge base and people fill it in. That's a wiki. We know how that ends — six months of enthusiasm followed by years of decay.

The approach that works is observation. Watch agents and humans work. Extract the patterns worth keeping.

An engineering agent that consistently refactors a certain anti-pattern is demonstrating a team convention, whether anyone thought to document it or not. A sales agent that adjusts messaging for a specific industry vertical is encoding market knowledge. A compliance agent that flags a particular contract clause every time is surfacing regulatory context.

Observation captures what people actually do. Documentation captures what people think they do. The gap between those is where most organisational knowledge lives, and it's the gap that's been impossible to close until agents created a stream of observable behaviour that can be analysed at scale.

Why this compounds

Most enterprise tools deliver linear value. Add a user, get a user's worth of output. Shared memory doesn't work like that.

Every agent interaction makes the memory richer. Every new hire — human or agent — onboards faster because the context already exists. Every cross-functional handoff is smoother because the knowledge already travelled before anyone thought to send it.

An enterprise running agents without shared memory has a thousand capable workers with no institutional knowledge. They'll make the same mistakes in parallel, each one missing context that exists somewhere else in the building. Fast workers, empty heads.

An enterprise with shared memory has something that didn't exist before: an organisation that actually retains what it learns, across every team and every tool, and gets meaningfully better at it over time.

What we're building

That's Memco. Spark observes agents as they work, extracts the knowledge worth keeping, and makes it available across teams, tools, and models. Private where it needs to be. Shared where it helps. Always evolving.

We started with coding agents because the feedback loop is tightest there — code has tests, CI, deployments, observable outcomes that tell you whether shared knowledge actually helped. But the architecture was always designed for the whole enterprise. The same pipeline that captures engineering conventions captures compliance constraints, sales patterns, and operational knowledge.

The future org doesn't need smarter agents. It needs agents that share a brain.

If you're thinking about this problem — for any domain — I'd like to hear from you. I'm @ScottTaylor on X.