We can get agents to use tools, follow instructions, coordinate through chains and graphs. What we can't easily do is get them to collectively improve at a task over time.
Most multi-agent systems are disposable. You spin up agents, they do work, the output goes somewhere, and the agents disappear. Next time you run them, they have no idea what happened last time.
People solve this with RAG — shove past outputs into a vector database, retrieve them before each run. That works for lookup. It doesn't work for improvement. There's no mechanism for the system to tell good knowledge from bad, recent from stale, confirmed from speculative. Everything is flat.
What you actually want is a layer underneath your agents that behaves more like a brain than a filing cabinet. Something that scores what it knows, forgets what's outdated, strengthens what's been validated, and lets agents build on each other's work without someone curating the knowledge manually.
That's what I mean by "cognitive layer." It's the piece that turns a disposable agent pipeline into a system that actually gets better over time.
I'll walk through how to build on top of one. The reference implementation is in the SRE domain (incident response), and the cognitive layer is SenseLab, but the architecture applies anywhere agents do repeated investigative work.
There are three layers. Each one has a specific job:
The first two layers are swappable. You can use a different orchestrator pattern, different tools. The third layer — the cognitive layer — is what creates the self-improvement property. Without it, you have agents that do work. With it, you have a system that compounds what it knows.
Every agent follows a protocol when interacting with the cognitive layer. There are five steps.
Before doing anything, the agent asks: what does the system already know about this?
briefing(entity_path="myapp/checkout-service")
recall("myapp/checkout-service", "pattern-timeout-cascade")
search(query="connection pool exhaustion", min_confidence=0.5)
What comes back is ranked. High-confidence, recently-validated entries come first. Stale speculation sits at the bottom. The agent can decide how much to trust each piece based on its score and age.
The agent does its actual work — pulls logs, checks metrics, reads recent deploys, whatever the investigation requires. It uses MCP tools to get live data and correlates it against what the knowledge graph said.
If the read step returned a 0.85-confidence playbook matching this exact failure, the agent can skip exploratory investigation and go straight to verifying whether the known fix applies here.
After completing work, the agent writes structured findings back:
write("myapp/checkout-service", "pattern-pool-exhaustion",
"Connection pool exhaustion caused by N+1 queries from commit abc123. "
"Symptoms: 504s, p99 > 10s, pool_active hits ceiling. "
"Resolution: connection timeout config + query batching.",
confidence=0.75, memory_type="experience")
The confidence is 0.75 — this worked once, it hasn't been confirmed by a second incident yet. The memory_type is "experience" (something the agent actually did and observed), which decays slower than "belief" (a hypothesis).
Later, the outcome gets reported:
commit_outcome("checkout-pool-fix", "success")
Or "failure". The system links this outcome back to every read and write that contributed. It now knows which knowledge led to a good result and which didn't.
Confidence scores update. A successful outcome pushes the contributing knowledge from 0.75 toward 0.9. A failure drops it. Knowledge that sits unvalidated for months drifts downward on its own — this is temporal decay.
No human made these adjustments. The system corrected its own knowledge base through use.
The cognitive layer isn't per-agent storage. It's shared. Agents read each other's work, and the system tracks those reads.
Here's a concrete example:
read_from(agent_a). It correlates that pattern with a recent commit that introduced unbounded queries. Confirms the fix works. Outcome: success. Confidence on the original pattern rises to 0.9.
The cognitive layer tracked all of this — who wrote what, who read from whom, which reads led to good outcomes. That's institutional knowledge building itself, without anyone writing a runbook or updating a wiki page.
You could store agent findings in Postgres. Stuff them into Pinecone. The technical difference:
The reference implementation is an incident response system that runs on your machine against your actual infrastructure. The repo is at github.com/raia-live/sre-sample.
SRE is a good fit for this architecture because:
To run it you need an LLM API key (Anthropic or OpenAI) and a SenseLab account (senselab.ai). You point it at your infrastructure through MCP configs — Datadog, GCP, GitHub, Jira, PagerDuty, whatever you use — and start it with docker compose up or make dev.
The first few incidents are fully exploratory. By incident ten or fifteen, common patterns are already stored with validated playbooks. The system is noticeably faster on repeat failure modes without anyone changing a line of code.
The pattern generalizes. Anywhere you have agents doing repeated investigative work — security triage, code review, support escalation, compliance checks — the same architecture applies.
A few things I'd do from the start:
SenseLab handles the decay mechanics, scoring, propagation, and provenance as infrastructure. Your job is to write agents that follow the protocol: read before acting, write after completing, report outcomes. The layer does the rest.
Free tier. No credit card. Connect in minutes.
