What should one AI agent be allowed to teach another?

A Claude agent researches a problem and writes down what it found. A Codex agent picks up the work later. It reads the note, accepts the conclusion and carries on.

This sounds like progress. The second agent did not start from zero.

It may also have inherited a mistake.

That is the uncomfortable part of persistent agent memory. We have spent a lot of time asking how agents can remember more. The harder question is what one agent should be allowed to teach the next one.

Fewer repeated dead ends

A recent Quesma post described a deep-research run that launched 111 agents, produced 123 claims, verified 25 and exhausted a Claude allowance before it reached the final report.

The revised system spread work across Claude, Codex and Gemini-family agents. It gave them shared memory, assigned different models to finding and verification, and required source quotations before claims could enter an Obsidian knowledge base.

The post did well on Hacker News because it was specific and slightly painful. It showed the counts, scripts, model roles and mistakes instead of announcing that multi-agent research had arrived.

In the comments, the author gave the clearest statement of the goal:

My goal is not fewer dead ends, but fewer repeated dead ends.

That is exactly the opportunity. An agent may need to explore a bad path once. The organization should not have to pay every later agent to explore the same bad path again.

But the comments also exposed the problem with the obvious solution.

One developer warned that anything written for agents can become "doctrine". Early assumptions get copied into project files, future agents treat them as settled, and behaviour locks down before the underlying design has stabilised.

Another commenter described an AI-generated trivia pipeline with multiple models, fetched sources and quality checks. They still reviewed every question manually. Their conclusion was that the review interface might be the most important part of the system.

Both observations point to the same thing:

The hard part of agent memory is not retrieval. It is admission.

An output is not a lesson

The easiest shared-memory implementation is also the most dangerous:

1. Agent finishes a task.
2. Agent summarises what it did.
3. Summary is saved.
4. Future agents retrieve it.

This turns confident prose into institutional knowledge with almost no resistance.

The output may be wrong. It may be correct only for one repository or customer. It may describe an experiment rather than an approved decision. It may have been true when written and false after a migration. It may omit the correction that arrived three messages later.

A source quotation does not solve the problem either. It proves that a source said something. It does not prove the source was correct, current or applicable to the task at hand.

The execution log should therefore remain evidence. Memory should be the governed judgment distilled from that evidence.

That distinction sounds fussy until a shared mistake reaches ten agents at once.

The Headroom mistake

Quesma's most useful example concerned Headroom, a project making a large token-savings claim.

Their admission rule rejected the claim because it could not be validated. Reasonable enough. But the system then excluded Headroom as a project, even though the project itself existed and remained relevant to the research.

The fix was simple to state and important to implement:

Reject the claim, not the entity.

A company, repository, person or project is not true or false. Individual claims about it can be supported, disputed, stale or wrong.

This means memory cannot just be a pile of approved documents. The basic unit needs to be smaller:

{
  "claim": "Project Headroom reduces token usage by X%",
  "entity": "Headroom",
  "scope": ["workload:research", "version:2026-07"],
  "status": "candidate",
  "evidence": [
    {
      "source": "...",
      "quote": "...",
      "retrieved_at": "..."
    }
  ],
  "contradictions": [],
  "verified_by": [],
  "approved_by": null,
  "expires_at": null
}

The project remains in the knowledge graph if that claim is rejected. A different claim may later be verified. The failed claim remains visible as negative evidence so another agent does not waste time trying to establish it again.

That is already more useful than deleting the note.

Shared memory needs a write path

A workable lifecycle looks something like this:

observed
  -> candidate
  -> source checked
  -> independently verified
  -> approved
  -> active
  -> monitored
  -> superseded, revoked or expired

The states matter because they control who can see what.

A candidate can be useful to the agent that created it without being presented to the whole organization as fact. A disputed claim can remain available to researchers while staying out of an operational agent's instructions. An approved policy can be bound into context automatically. A revoked memory can stop influencing future work without erasing why it was once accepted.

The higher the scope, the stronger the admission threshold should be.

A private scratch note may need no review. A team convention should have supporting evidence or repeated successful use. An organization-wide policy affecting production deployments may require tests, an owner and an expiry date.

create_memory should not mean publish_truth_to_every_agent.

Model-on-model verification is not independence

The Quesma system separates the finder from the verifier. That is sensible. It reduces self-confirmation and makes the research process easier to inspect.

It does not eliminate hallucinations.

Two models may have seen the same training data, rely on the same popular but incorrect source, or make correlated assumptions from the prompt. Swapping vendors does not magically make errors independent.

Verification should therefore use the strongest evidence available for the task:

• Execute the code and run the tests.
• Fetch the cited URL and check that the quotation exists.
• Compare a numerical claim with the source table.
• Check a decision against the owner or policy that governs it.
• Re-run a procedure in a clean environment.
• Ask a human when the cost of a false promotion is high.

The verifier model is one signal. It is not the court of final appeal.

This is why the review interface matters. A good system should show the human exactly what changed, where it came from, what supports it, what contradicts it and which agents would receive it after approval.

The interface should make a clean review fast. It should demand more scrutiny, not less, when the proposed memory has broad authority.

Project files are a serious baseline

There is a temptation for memory vendors to dismiss CLAUDE.md, AGENTS.md, skills files and carefully maintained documentation as primitive.

That would be a mistake.

Files have excellent properties:

• Humans can read them.
• Git records changes.
• Every coding tool understands them.
• Teams can review them with familiar workflows.
• They are cheap.

A memory system should not replace a file because vector search sounds more advanced. It should earn its place where files begin to struggle:

• the same rule has different scopes;
• evidence and rationale matter;
• two decisions conflict;
• access differs between teams;
• facts expire;
• an old rule must be revoked quickly;
• the organization needs to know whether an agent actually used the guidance;
• learning must move between models and tools without copying entire project histories.

If a static file performs just as well, use the file.

Delivery is part of memory

Our own small coding-agent benchmark exposed another easy mistake.

Across 15 tasks where Claude Code had access to a shared-memory tool, only one job touched it. The shared-memory arm completed 12 of 15 tasks. A static project-file arm also completed 12. The no-memory control completed 13.

This was not evidence that memory makes agents worse. The sample was small, and the later tasks were too easy for the control to expose much transfer benefit.

It did show that optional availability is not a delivery mechanism. The agent had a library card and rarely entered the library.

A useful memory system needs to distinguish:

eligible
  -> served
  -> bound into context
  -> cited
  -> followed
  -> executed
  -> successful outcome

Retrieval benchmarks usually stop near the top. Real value appears at the bottom.

A relevant memory may be found and then ignored. It may be inserted into context but misunderstood. The agent may follow it faithfully and still fail because the memory was wrong.

Without this lineage, a team can celebrate high recall while the same operational mistake keeps happening.

What should cross between agents?

Not the whole transcript.

Not every self-written summary.

Not a model's private chain of thought.

What should cross is the smallest useful unit of reviewed judgment, with enough evidence to explain and reverse it.

For a coding team, that might be:

• A reviewer correction and the reason behind it.
• A repository convention that is not evident from the code.
• A failed migration approach and the condition that caused it to fail.
• A production incident lesson tied to the relevant service and version.
• A tested procedure with explicit preconditions.
• A customer or compliance constraint that changes implementation choices.

A useful memory packet might say:

Rule:
Operation IDs must remain stable across retries.

Why:
External audit consumers use the ID as an idempotency key.

Applies to:
billing/operations/*

Does not apply to:
internal batch IDs generated after settlement

Evidence:
review comment #1842, integration test idempotency_retry

Status:
approved by payments owner; revalidate after ledger-v3 migration

That is much more useful than "remember to handle idempotency". It is also safer than pasting an entire incident transcript into every prompt.

The metric is repeated correction

Token counts matter, but they are not the main outcome.

The question is whether the organization had to teach the same lesson again.

Useful measures include:

• repeated reviewer corrections;
• recurrence of known incident patterns;
• cross-agent transfer success;
• cost per successful task;
• stale guidance caught before execution;
• time spent rediscovering prior decisions;
• regressions caused by bad memory;
• successful reuse on an adjacent task.

A memory that is frequently retrieved but never changes behaviour is documentation traffic, not learning.

A memory that prevents one expensive production mistake may be valuable even if it is retrieved only once.

The second agent should not start from zero

Advanced teams are already assembling pieces of this themselves.

They update project rules after long sessions. They write skills that encode recurring procedures. They keep shared Obsidian vaults. They route research through several models. They build human review queues because they do not trust generated output to publish itself.

These are sensible local solutions. They also reveal the missing layer.

At Memco, we are working on the system that sits between an agent's execution trace and the next agent's context: capture the correction, preserve the evidence, decide its scope, test it, approve it, serve it at the right moment and stop serving it when it becomes wrong.

We do not think every agent output deserves to become memory. Most should disappear.

The second agent should not start from zero. It should not inherit everything the first agent said either.

It should inherit what the organization has earned the right to trust.

That is how one agent learns without teaching every other agent the same mistake.