DEV Community

Julien L
Julien L

Posted on

Share memory between AI agents without infrastructure

#ai #python #architecture #tutorial

Two AI agents need to collaborate. One researches, the other writes. How do they share what they know?

This is not a theoretical question. Multi-agent systems are the dominant trend in agentic AI right now. Gartner reported a 1445% surge in enterprise inquiries about multi-agent architectures. Every serious AI project is moving from "one big agent" to "specialized agents that cooperate."

But here is the dirty secret: the hard part is not building agents. It is sharing state between them.

The infrastructure tax

When Agent A discovers a fact and Agent B needs to use it, you typically need one of these:

  • Redis for shared key-value state
  • PostgreSQL for structured shared data
  • RabbitMQ/Kafka for message passing
  • A custom API layer to coordinate everything

That is a lot of moving parts for what is conceptually simple: "remember this, so another agent can find it later."

What if both agents could just read and write to the same file?

The architecture

Here is what we are building: two Python scripts that share one VelesDB database file. The researcher agent gathers facts and records events. The writer agent reads those facts and checks what was already covered.

┌──────────────┐         ┌──────────────────┐         ┌──────────────┐
│  Researcher  │───────▶ │  VelesDB file    │ ◀───────│    Writer    │
│    Agent     │  write  │  (shared state)  │  read   │    Agent     │
│              │         │                  │         │              │
│ - search web │         │ semantic memory  │         │ - read facts │
│ - store facts│         │ episodic memory  │         │ - check done │
│ - log events │         │                  │         │ - write draft│
└──────────────┘         └──────────────────┘         └──────────────┘
Enter fullscreen mode Exit fullscreen mode

No Redis. No message queue. No API. Just a folder on disk.

Setup 

pip install velesdb sentence-transformers
Enter fullscreen mode Exit fullscreen mode

That installs the database engine (a ~6MB native binary inside the Python wheel) and the embedding model. No Docker, no API keys.

The researcher agent

This agent searches for information and stores what it finds in semantic memory (facts) and episodic memory (events).

# researcher_agent.py
import velesdb
import time
from sentence_transformers import SentenceTransformer

model = SentenceTransformer("all-MiniLM-L6-v2")

def embed(text):
    return model.encode(text).tolist()

# Open the shared database
db = velesdb.Database("./shared_agent_brain")
memory = db.agent_memory(384)

# ---- Store researched facts in semantic memory ----
facts = [
    (1, "Multi-agent systems saw a 1445% surge in Gartner inquiries in 2025"),
    (2, "CrewAI and AutoGen are the two most popular multi-agent frameworks"),
    (3, "Shared state is the hardest problem in multi-agent architectures"),
    (4, "Most multi-agent systems use Redis or message queues for coordination"),
    (5, "Local-first databases eliminate infrastructure dependencies for agent memory"),
]

for fact_id, text in facts:
    memory.semantic.store(fact_id, text, embed(text))
    print(f"  [semantic] Stored: {text}")

# ---- Record research events in episodic memory ----
now = int(time.time())
events = [
    (1, "Searched web for multi-agent architecture trends 2025-2026", now - 3600),
    (2, "Found Gartner report on agentic AI surge", now - 1800),
    (3, "Compared CrewAI vs AutoGen vs LangGraph for memory handling", now - 900),
    (4, "Identified shared state as the key unsolved problem", now),
]

for event_id, description, timestamp in events:
    memory.episodic.record(event_id, description, timestamp, embed(description))
    print(f"  [episodic] Recorded: {description}")

print("\nResearcher done. Closing database.")
Enter fullscreen mode Exit fullscreen mode

The researcher stores five facts and four timestamped events. All of them are embedded as 384-dimensional vectors using all-MiniLM-L6-v2, so the writer can search them semantically later.

The writer agent

A separate Python script. Different process. Same database path.

# writer_agent.py
import velesdb
from sentence_transformers import SentenceTransformer

model = SentenceTransformer("all-MiniLM-L6-v2")

def embed(text):
    return model.encode(text).tolist()

# Open the SAME database the researcher wrote to
db = velesdb.Database("./shared_agent_brain")
memory = db.agent_memory(384)

# ---- Query semantic memory: what facts did the researcher find? ----
print("Facts about multi-agent trends:")
results = memory.semantic.query(embed("What are the trends in multi-agent AI?"), top_k=3)
for r in results:
    print(f"  [{r['score']:.4f}] {r['content']}")

print("\nFacts about state sharing:")
results = memory.semantic.query(embed("How do agents share state?"), top_k=3)
for r in results:
    print(f"  [{r['score']:.4f}] {r['content']}")

# ---- Check episodic memory: what was already researched? ----
print("\nResearch timeline (most recent first):")
recent = memory.episodic.recent(limit=4)
for event in recent:
    print(f"  {event['description']}")

# ---- Find specific episodes by topic ----
print("\nEpisodes about framework comparison:")
similar = memory.episodic.recall_similar(embed("framework comparison analysis"), top_k=2)
for s in similar:
    print(f"  [{s['score']:.4f}] {s['description']}")
Enter fullscreen mode Exit fullscreen mode

Real results

Run the researcher first, then the writer:

python researcher_agent.py
python writer_agent.py
Enter fullscreen mode Exit fullscreen mode

Here is the actual output from the writer agent:

Facts about multi-agent trends:
  [0.6159] CrewAI and AutoGen are the two most popular multi-agent frameworks
  [0.5812] Shared state is the hardest problem in multi-agent architectures
  [0.5255] Most multi-agent systems use Redis or message queues for coordination

Facts about state sharing:
  [0.6717] Shared state is the hardest problem in multi-agent architectures
  [0.5047] Most multi-agent systems use Redis or message queues for coordination
  [0.4449] Local-first databases eliminate infrastructure dependencies for agent memory

Research timeline (most recent first):
  Identified shared state as the key unsolved problem
  Compared CrewAI vs AutoGen vs LangGraph for memory handling
  Found Gartner report on agentic AI surge
  Searched web for multi-agent architecture trends 2025-2026

Episodes about framework comparison:
  [0.2404] Compared CrewAI vs AutoGen vs LangGraph for memory handling
  [0.1861] Searched web for multi-agent architecture trends 2025-2026
Enter fullscreen mode Exit fullscreen mode

The writer found exactly the facts the researcher stored, ranked by semantic relevance. The query "How do agents share state?" returned "Shared state is the hardest problem" at 0.67 even though the query words do not match the stored text literally. That is semantic search working as expected.

The episodic timeline gives the writer a chronological view of what research was already done, so it does not duplicate effort.

How it works under the hood

VelesDB stores everything in a local folder. The agent_memory(384) call creates three internal collections (semantic, episodic, procedural) backed by HNSW indexes for fast vector search.

When the researcher writes and closes the database, the data is persisted to disk. When the writer opens the same path, it reads that persisted state. No network calls, no serialization protocol, no connection string.

The key insight: the database file is the message bus.

Limitations

This approach has real constraints you should know about:

Single-process access. VelesDB locks the database file for writes. Two agents cannot write simultaneously to the same database. This means sequential workflows only: researcher runs, finishes, then writer runs.

No real-time streaming. If you need Agent B to react the instant Agent A stores something, you need a message queue or pub/sub system. VelesDB is not that.

Workarounds that do work:

  • Sequential pipelines. Most multi-agent workflows are already sequential (research, then write, then review). This fits naturally.
  • Read-only mode. One agent writes, multiple agents read. VelesDB allows concurrent reads after the writer closes.
  • Periodic snapshots. Copy the database file for each reader agent. They get a consistent snapshot without locking conflicts.

For a two-agent pipeline where one produces and the other consumes, this is a practical fit. For a swarm of 50 agents writing simultaneously, you need a different architecture.

When to use this vs. Redis/Postgres

Scenario Use VelesDB shared file Use Redis/Postgres
2-5 agents, sequential pipeline Yes Overkill
Agents on the same machine Yes Unnecessary
Need semantic search over shared facts Yes (built-in) Requires extra setup
50+ concurrent writing agents No Yes
Real-time pub/sub between agents No Yes
Zero infrastructure requirement Yes No

Getting started 

pip install velesdb sentence-transformers
Enter fullscreen mode Exit fullscreen mode

VelesDB is source-available under the Elastic License 2.0. The full code and documentation are on GitHub:

What is your multi-agent architecture? Are you running sequential pipelines or full concurrent swarms? I am curious what state-sharing problems you have hit in practice.

Top comments (0)