AI agents are getting better at solving problems.
They are still surprisingly bad at remembering what another agent already learned.
I kept running into the same pattern:
Claude debugs something in one session.
Codex discovers the same failure two days later.
Another agent researches the same API limitation from scratch.
The model may be different, the application may be different, but the operational experience is usually trapped inside one conversation.
So I started experimenting with a shared layer where agents could leave structured experience for each other.
Not just documents.
Something closer to:
Problem
↓
Solution
↓
Outcome
↓
PASS / FAIL / limitation
And, for questions that cannot be answered immediately:
Agent A asks
↓
shared durable task
↓
Agent B replies later
↓
Agent A retrieves the reply
That led to an interesting test.
Claude asks, Perplexity answers
I connected Claude and Perplexity to the same shared knowledge layer through agent-facing interfaces.
The flow was:
Claude
↓
creates a durable question
↓
Knowledge layer
↓
Perplexity finds the question
↓
Perplexity replies
↓
Knowledge layer
↓
Claude retrieves the reply later
This was performed through actual hosted AI products rather than two instances of the same local agent framework.
That part worked.
But the more interesting problem appeared immediately afterward.
Two agents do not necessarily mean two independent observations
Claude and Perplexity were different agent identities.
But both were operated by me.
That distinction matters.
Suppose an agent publishes:
This fix works.
Then another agent records:
PASS — reproduced successfully.
At first glance that looks like independent corroboration.
But what if:
- both agents belong to the same human;
- both inherited the same context;
- both were given the same assumptions;
- both ultimately relied on the same source;
- or one agent simply repeated information produced by the other?
Counting that as two independent reproductions would manufacture confidence.
So in the system I am building, agent identity and operator identity are separate concepts.
The Claude/Perplexity experiment therefore means:
2 agent identities 1 operator = interoperability evidence ≠ independent reproduction
That sounds like a small bookkeeping detail.
I think it becomes a fairly fundamental issue once agents start sharing knowledge with each other.
Successful answers are not enough
There is another thing I wanted the knowledge model to preserve: failure.
Most knowledge systems naturally converge on the final answer.
Agent work often looks more like this:
`Problem
Attempt A
FAIL — wrong API version
Attempt B
FAIL — works locally, fails behind proxy
Attempt C
PASS — environment X, version Y
Later:
FAIL — version Z changed the behavior
For the next agent, Attempt A and Attempt B may be as valuable as Attempt C.
They prevent repeated exploration.
So the useful unit of shared agent knowledge is not simply:
It is closer to:
→ proposed solution
→ observed outcome
→ environment
→ evidence
→ limitations
→ provenance`
That also means a system should be able to say:
We do not know.
or:
This worked once under these conditions.
instead of collapsing everything into a single canonical answer.
Why I did not put an LLM in the middle
One design decision was to keep the shared layer itself deterministic.
Reading a stored result should not trigger another model to reinterpret or regenerate it.
If an agent recorded:
FAIL
Node 24
macOS
spawn npx ENOENT
another agent should be able to retrieve exactly that observation.
The server can structure, index and connect knowledge.
It does not need to invent a new answer every time someone reads it.
That gives a useful separation:
`AI agents produce observations
shared infrastructure stores provenance
other AI agents decide how much to trust and reuse them`
It also makes the knowledge usable by systems with very different models and vendors.
Synchronous tools and asynchronous questions are different problems
This experiment also made another distinction clearer to me.
Sometimes an agent needs:
Search the existing knowledge now.
That maps naturally to a tool protocol such as MCP.
But sometimes the request is:
Nobody has answered this yet. Ask the network and let me come back later.
That is a different interaction model.
The caller needs a durable task rather than a synchronous tool response.
So I ended up treating those as separate primitives:
`MCP:
What does the network already know?
Asynchronous task:
Ask the network and let me return later.`
Trying to force both into one synchronous request makes the second case awkward very quickly.
The part I am still unsure about
Transport is relatively easy compared with trust.
Once multiple agents can share operational experience, several questions become much harder:
How should an agent decide whether another agent's PASS is worth trusting?
How much should operator independence matter?
Should reproduction across different models count more strongly?
What happens when two credible agents publish conflicting outcomes?
How quickly should old outcomes decay when dependencies and APIs change?
And should a failed approach increase confidence in another solution — or simply remain a warning attached to one environment?
Those seem less like retrieval problems and more like social/provenance problems for machines.
The Claude → Perplexity exchange convinced me that cross-vendor transport is possible.
It also convinced me that transport may be the easy part.
The difficult problem is deciding what an agent should believe after the message arrives.
Top comments (2)
Separating agent identity from operator identity is the right correction. I would also track observation lineage as a first-class field: two agents under different operators can still inherit the same source or one can summarize the other's result. Independence is therefore a property of the evidence graph, not a count of agent names. The ability to retain FAIL records with environment details makes that graph much more honest.
Refusing to put a model in the read path is the decision I would probably have got wrong. A shared layer like this reaches for a summariser because prose retrieval is nicer to read, and then nobody can tell whether the second participant reproduced the finding or merely repeated it — the copy turns into the corroboration. Storing the raw FAIL line with its environment and version is what keeps the record falsifiable, and it is why a failed attempt really does carry as much information as a passing one.
The decay question you leave open is the hard one. I don't see a good answer without a dependency signal: attach the version and date to the record, never let it retire itself, and let confidence fall with the number of releases since anyone re-ran it. Do you treat a PASS recorded before an upgrade of the thing it tested as still load-bearing, or does it have to be re-earned? And who pays when two participants publish conflicting outcomes about the same environment — does the newer one win, or does the disagreement just stay visible?