DEV Community: bluecolumn

Audio-First Memory for AI Sales Agents

bluecolumn — Mon, 27 Jul 2026 19:30:22 +0000

Audio-First Memory for AI Sales Agents

AI sales agents are having a moment. Voice agents on Vapi and Bland AI are making calls. Video avatars on Tavus and HeyGen are running demos. These agents sound human, handle objections, and scale in ways that outbound teams never could.

But they share a critical blind spot: they don't remember.

Every call starts from zero. The agent doesn't know if this is the third time it's contacted the same prospect. It doesn't recall the objection from last week. It can't build on a relationship because it has no concept of relationship.

This isn't a limitation of the agent platforms themselves. Vapi, Tavus, and their peers are excellent at what they do — voice synthesis, conversation flow, integration tooling. The missing piece is memory infrastructure purpose-built for audio conversations.

The Audio Memory Problem

Most "memory for agents" solutions today were designed for text. You store a string, you retrieve a string. That works fine for chatbots where every interaction is already text.

Voice agents are different. The raw input is an audio stream. Getting that into a retrievable memory format requires:

Real-time transcription (you can't wait for post-call processing — the agent needs context mid-conversation)
Speaker diarization (who said what matters in a sales conversation)
Conversation-aware chunking (a sales call has structure: opening, discovery, objection handling, next steps)
Multi-modal storage (the transcript is useful, but the tone, timing, and emphasis matter too)

None of these are hard problems individually. But assembling them into a reliable pipeline that works at scale — that's where most agent teams get stuck.

What Memory Looks Like for a Sales Agent

Here's the scenario. A voice agent calls a prospect for the first time. The conversation goes well — the prospect is interested, raises a pricing concern, and agrees to a follow-up.

On the second call, the agent should know:

That the prospect was interested in the product
That pricing was the main objection
What price range was discussed
What next steps were promised

Without memory, the agent re-introduces itself, re-explains the value proposition, and re-discovers the pricing objection. The prospect gets frustrated. The deal stalls.

With memory, the agent opens with: "Hi John, good to speak with you again. I know pricing was on your mind last time — I've put together a couple of options I'd love to walk through."

That's the difference between a robotic interaction and a human one.

The Audio-First Approach

Building memory for audio agents means rethinking the ingestion pipeline from the ground up.

Real-time Whisper integration. The agent's audio stream feeds directly into a Whisper-powered transcription service. The transcription is chunked by conversation turn (not by character count) and embedded in real time. By the time the prospect finishes a sentence, that sentence is already in the memory store.

Conversation structure awareness. A sales call isn't a blob of text — it has phases. Discovery questions generate different kinds of memory than pricing discussions or objection handling. The memory system should tag and organize accordingly.

Cross-session retrieval. When a new call starts, the agent queries memory by prospect identifier. It retrieves not just raw transcripts but structured summaries: key objections, expressed interests, promised next steps. The agent gets a brief before every conversation.

How It Integrates with Agent Platforms

The integration surface is deliberately small. Two API endpoints.

Storage: After each conversation turn (or after the full call), send the audio to the memory API. It handles transcription, embedding, and storage.

from bluecolumn import BlueColumn

bc = BlueColumn(api_key="your_key")
bc.remember(
    session_id="prospect-123",
    audio_file="call-segment-1.wav",
    metadata={
        "prospect": "Acme Corp",
        "phase": "discovery",
        "objections": ["pricing"]
    }
)

Retrieval: Before a new call, query for everything the agent needs to know.

context = bc.recall(
    session_id="prospect-123",
    query="What were the key objections and next steps?"
)

That's it. The memory system handles the complexity — real-time Whisper pipelines, embedding infrastructure, multi-tenant storage, and retrieval optimization — behind a API calls.

For Vapi users, this slots into the endCall webhook for storage and the assistantRequest hook for retrieval. For Tavus, it populates the custom context field on each new session. For Synthflow, it runs as a custom action in the conversation pipeline.

Why Audio-First Matters for Sales

Sales conversations are fundamentally different from text interactions.

Pacing matters. In text, you can pause and think. In a voice conversation, silence is awkward. The agent needs memory retrieval fast enough that it doesn't break conversational flow.

Tone carries information. A prospect who says "interesting" in a flat tone means something different from one who says it with enthusiasm. Audio-first systems can capture and surface these signals in ways text-only systems miss.

Relationship builds across calls. Sales cycles span multiple touchpoints. A prospect might take two discovery calls, a demo, and a pricing discussion before deciding. Each touchpoint informs the next. Without cross-session memory, every call is a cold call.

The Architecture Behind It

A properly designed audio memory pipeline for sales agents has a few key components:

Real-time transcription layer. Whisper (or equivalent) running with low latency. Streaming input, incremental output.
Embedding pipeline. Each transcribed turn gets embedded into a vector space optimized for conversation similarity (not document similarity — they're different).
Multi-tenant storage. Every prospect's memory is isolated. No cross-contamination between conversations.
Conversation-aware retrieval. Queries returning chunks aren't good enough. The retrieval layer should return structured context: summary, key points, action items.
Database-agnostic backend. The memory layer shouldn't tie you to a specific vector database. You should be able to use Pinecone (great default), Weaviate, Qdrant, or your own cluster.

What This Makes Possible

With audio-first memory in place, voice and video sales agents transform from call automation tools into something closer to digital sales reps.

Outbound agents that warm leads over time. The agent remembers that Prospect A was interested in analytics, Prospect B needs pricing flexibility, and Prospect C is still evaluating competitors. Each follow-up is tailored.

Video avatars that build relationships. A prospect who watched a demo last week gets a follow-up avatar that remembers exactly which features caught their attention. The avatar can say: "Last time we showed you the reporting module — I wanted to spend more time on that today."

Smarter qualification sequences. As memory accumulates across calls, the agent builds a richer prospect profile. It knows what matters to each decision-maker, what objections have been handled, and what information is still needed.

Better human handoffs. When a voice agent qualifies a lead and hands off to a human rep, the full conversation history comes with it. The rep doesn't start from zero.

Getting Started

If you're building voice or video sales agents, memory infrastructure should be part of your stack from day one. It's much harder to retrofit than to build in from the start.

The integration surface is small — two API endpoints, one SDK, three lines of code to get started.

pip install bluecolumn
export BLUECOLUMN_API_KEY="your_key"

Your agent already sounds human. Give it the memory to match.

Built for teams on Vapi, Synthflow, Bland AI, Tavus, HeyGen, and Soul Machines. Compatible with any agent stack.

Why Agent Memory Is Harder Than RAG (And What To Do About It)

bluecolumn — Fri, 24 Jul 2026 08:45:54 +0000

Why Agent Memory Is Harder Than RAG (And What To Do About It)

RAG works great when your agent needs to find a fact. It falls apart when your agent needs to remember something from three conversations ago. They look like the same problem. They're not.

I've been working on agent memory infrastructure for the past year, and the most common mistake I see in production is treating memory as "RAG but smaller." It leads to architectures that are overengineered in the wrong places and underengineered in the critical ones.

Here's the distinction: RAG answers questions. Agent memory carries context. Most teams build the first and convince themselves they've built the second. By the time they realize the difference, they're buried in vector DB costs and their agents are forgetting who users are between sessions.

Let's dig into exactly where the two diverge and what it means for your agent stack.

1. The Fundamental Difference

RAG solves a search problem. You have a corpus of documents. A user asks a question. You find the relevant passages and feed them to the LLM. Every query is independent — you don't need to know what the user asked yesterday.

Agent memory solves a state problem. Your agent interacts over time. It needs to know what happened in a previous session, what the user's preferences are, what commitments were made. The same user, same context, different conversation.

The metrics are different too:

Property	RAG	Agent Memory
Data volume	Gigabytes–terabytes	Megabytes–gigabytes
Query pattern	Find best match	Find last + match
Latency requirement	<500ms is fine	<100ms preferred
Write frequency	Batch, async	Every turn, synchronous
What matters most	Recall@K	Recency + relevance

A RAG pipeline that returns the wrong document gets a 70% relevance score. An agent that returns the wrong memory tells the customer "I don't know who you are" — and they hang up.

Real example: My fence company agent handled 47 calls last week. A returning caller said "the gate I asked about last time." A RAG-only agent would search for "gate" across all 47 transcripts, find 14 mentions, and feed 6,000 tokens of unrelated gate discussions to the LLM. A memory-aware agent loaded a single consolidated object: "Customer requested 4ft gate on Maple Street, aluminum, self-closing hinge." 200ms vs 1.2s. 6,000 tokens vs 200. One worked. One didn't.

2. The Session Merge Problem

This is the one nobody talks about until they deploy.

Your agent talks to a user for 45 minutes. That's roughly 15,000–25,000 tokens of conversation history. You can't store all of it verbatim — every new session tries to load history and your context window fills up in two interactions.

So you need to consolidate. But what do you keep?

The user's stated preferences? Yes.
Their address? Yes.
The order they placed? Yes.
The fact that they asked about pricing three times? Maybe.
Their offhand complaint about the weather? No.
Their phone number? Yes, but with privacy retention limits.

A RAG system doesn't have to make these decisions. It indexes everything with equal weight. An agent memory system has to be opinionated about what matters — because every byte of irrelevant memory is crowding out relevant context in the next session.

Consolidation in practice

Here's what a real memory write looks like:

curl -X POST https://xkjkwqbfvkswwdmbtndo.supabase.co/functions/v1/agent-remember \
  -H "Authorization: Bearer bc_live_xxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "text": "Customer called about 6ft privacy fence for backyard on Maple Street. Also needs a 4ft gate with self-closing hinge. Quote requested. No material decision yet.",
    "session_id": "sess_8f3a1c",
    "metadata": {
      "type": "call_summary",
      "customer_id": "cus_42",
      "priority": "high"
    }
  }'

And here's what recall looks on the next session:

curl -X POST https://xkjkwqbfvkswwdmbtndo.supabase.co/functions/v1/agent-recall \
  -H "Authorization: Bearer bc_live_xxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "What did Maple Street customer ask about?",
    "user_id": "cus_42",
    "max_results": 5
  }'

Response:

{
  "answer": "The customer requested a 6ft privacy fence for their Maple Street backyard and a 4ft aluminum gate with self-closing hinge. They received a quote but haven't decided on materials yet.",
  "sources": [
    {
      "title": "Call Summary - April 28, 2026",
      "relevance": 0.94,
      "timestamp": "2026-04-28T14:32:00Z"
    }
  ],
  "tokens_used": 83
}

The agent gets back a synthesized answer with source attribution, not a wall of raw chunks. This is the key architectural difference: RAG returns documents. Memory returns understanding.

3. Where RAG Breaks for Memory

The similarity scoring that works great for documents works poorly for conversation history.

Conversations are temporal. The fact that a customer said X yesterday is more relevant than the fact that they said Y three months ago — even if Y is semantically closer to the current query. Most vector similarity search doesn't weight recency unless you explicitly build it in.

Conversations have implicit context. "The one I mentioned last time" refers to something that exists in the agent's memory but has no semantic similarity to the current query. RAG won't find it.

Conversations are sparse. A 20-turn conversation might have two or three pieces of actionable information. The rest is filler: pleasantries, clarifications, dead ends. Indexing everything with equal weight means your retrieval is 85% noise.

I've seen teams spend weeks tuning embedding models for document retrieval, only to find their memory recall quality barely improved. The bottleneck isn't semantic similarity — it's deciding what to remember.

Three memory tiers, one API

The architecture that works in production uses three storage tiers:

Tier	What	Retention	Example
Ephemeral	Full conversation verbatim	Current session only	"What did the user say 5 turns ago?"
Consolidated	Compressed session summaries	Stored permanently	200-token summary of a 45-min call
Permanent	Key-value facts	Until deleted	Address, preferences, account details

BlueColumn exposes exactly this pattern through distinct API endpoints — but the concept applies regardless of what you use.

4. Cost Curves Diverge

This is the practical consideration that bites you at scale.

RAG costs grow with document volume: more documents → more embeddings → more storage → more retrieval compute. It's a linear cost curve that's well-understood.

Memory costs grow with interaction volume: more users → more sessions → more turns → more writes → more consolidation passes. It's a multiplicative curve that's easy to underestimate.

Here's what that looks like at different scales:

10,000 users, 5 sessions/week/user, 20 turns/session

Memory writes: 1M/month
Memory reads: 500K/month
Consolidation passes: 40K/month

100,000 users, same engagement

Memory writes: 10M/month
Memory reads: 5M/month
Consolidation passes: 400K/month

At the lower end, you can get away with throwing everything into a vector DB and paying the per-operation costs. At the higher end, every microsecond and microcent adds up.

The way to keep costs manageable is to embed during the write operation (no separate embedding API call) and use session-level consolidation to keep storage sub-linear with interaction volume. The write path stays cheap because embedding is bundled into the write cost, and the read path stays fast because the index is optimized for recency-weighted recall rather than raw semantic similarity.

Pricing reality check:

Operation	DIY (Pinecone + OpenAI embeddings)	Bundled (embedding included)
Write (embed + store vector)	~$0.003 (embedding) + $0.001 (storage)	~$0.02 flat
Read (query + retrieve)	~$0.003 (query embedding) + $0.001 (search)	~$0.05 flat
Audio minute (transcribe + embed)	~$0.006 (Whisper) + ~$0.003 (embedding)	~$0.50 flat

The DIY approach looks cheaper per-operation, but you're paying for infra management, retries, error handling, and the engineering time to wire it together. The bundled approach costs more per-op but eliminates the operational overhead. For most teams under 100K writes/month, the bundled approach wins on total cost of ownership.

5. When You Actually Need Both

Most real agents need RAG and memory. They're complementary, not alternatives.

RAG for: product catalogs, documentation, pricing sheets, policies
Memory for: customer history, preferences, conversation state, commitments

A good architecture routes queries differently: factual questions hit the RAG pipeline, context-dependent questions hit the memory layer, and compound questions hit both with a merge step.

The mistake is treating memory as "RAG for small documents." They need different storage backends, different retrieval strategies, and different cost models.

What This Means for Your Architecture

If you're building an agent today:

Don't use RAG infrastructure for memory. It'll work at prototype scale and fall over at production. You'll spend more time patching a RAG pipeline to handle conversational data than you would building a dedicated memory layer.
Design for consolidation from day one. Three tiers: verbatim current session, compressed summaries for completed sessions, permanent key-value store for hard facts. Different retention policies for each.
Measure recency-weighted recall, not just semantic similarity. If your memory retrieval returns the perfect match from six months ago and misses what the user said last week, it's broken — even if the similarity score looks good.
Know your cost curve. Memory costs scale with interactions, not documents. Model your expected interaction volume before committing to a storage architecture. A solution that costs $50/month at 10K writes might cost $5,000 at 100K.

I work on memory infrastructure for AI agents. If you're running into these patterns in production, I'd be interested to hear about it.

BlueColumn — bluecolumn.ai — Free tier: 100 memory writes + 100 reads + 30 audio minutes/month

BlueColumn vs Mem0: Which AI Agent Memory API Should You Use?

bluecolumn — Tue, 21 Apr 2026 02:52:38 +0000

If you are building AI agents and need persistent memory, you have probably come across both BlueColumn and Mem0. Both solve the same core problem — agents that forget everything between sessions — but they take different approaches.

Here is an honest comparison.

What They Both Do

Both BlueColumn and Mem0 give AI agents persistent semantic memory. You store information, query it later with natural language, and get back relevant context. The core use case is identical.

BlueColumn

BlueColumn is a pure REST API. Three endpoints, no SDK required, works with any framework or language.

import requests

key = "bc_live_YOUR_KEY"
base = "https://xkjkwqbfvkswwdmbtndo.supabase.co/functions/v1"

# Store
requests.post(f"{base}/agent-remember",
  headers={"Authorization": f"Bearer {key}"},
  json={"text": "User is building a SaaS product", "title": "User context"})

# Query
answer = requests.post(f"{base}/agent-recall",
  headers={"Authorization": f"Bearer {key}"},
  json={"q": "what is the user building?"}).json()["answer"]

Strengths:

Zero framework dependencies — works with raw HTTP calls
Audio ingestion built in (Whisper transcription)
Auto-extracts summaries, action items, key topics on ingest
EU data residency available
Free tier: 60 min audio + 100 queries/month

Mem0

Mem0 is also a memory layer for AI agents, with a Python SDK and integrations for LangChain, AutoGen, and others.

from mem0 import Memory

m = Memory()
m.add("User is building a SaaS product", user_id="user123")
results = m.search("what is the user building?", user_id="user123")

Strengths:

Native Python SDK
Built-in user/agent/session scoping
Strong LangChain integration
Open source option available

Key Differences

Feature	BlueColumn	Mem0
API style	REST (any language)	SDK-first (Python/JS)
Audio ingestion	✅ Built in	❌ Text only
Auto metadata extraction	✅ Summary, topics, action items	❌
EU data residency	✅	Depends on plan
Open source	❌	✅ (self-host option)
Free tier	60 min + 100 queries	Limited
Framework coupling	None	SDK preferred

When to Use BlueColumn

You are building in any language (not just Python)
You need audio/meeting transcription built into memory
You want automatic metadata extraction (summaries, action items)
You need EU data residency
You want a simple REST API without SDK dependencies

When to Use Mem0

You are building exclusively in Python
You want a Python SDK with familiar patterns
You need self-hosted/open source option
You are deeply embedded in the LangChain ecosystem

Bottom Line

Both are solid. If you are building a Python-only LangChain agent, Mem0 feels native. If you are building in any other language, need audio ingestion, or want automatic metadata extraction, BlueColumn is the cleaner choice.

Try BlueColumn free at bluecolumn.ai — no credit card required.

Have you used either? What has your experience been? Drop a comment.

The AI Agent Memory Problem: Why Your Agent Keeps Forgetting

bluecolumn — Fri, 17 Apr 2026 16:20:18 +0000

You spent weeks building a smart AI agent. It reasons well, uses tools correctly, and gives great responses.

Then a user comes back the next day and your agent has no idea who they are.

This is the AI agent memory problem, and it is one of the biggest gaps between demo-quality agents and production-quality agents.

Why Agents Forget

Most AI agents are stateless by design. Each API call to an LLM is independent — the model has no memory of previous calls unless you explicitly pass that context in the prompt.

The common workarounds all have serious limitations:

Stuffing history into the prompt
Simple but expensive. Every token in your history costs money on every request. At scale, this becomes unsustainable. And when history exceeds the context window, older memories just disappear.

Saving to a database and retrieving manually
Requires building your own retrieval system. What do you retrieve? How do you rank results? How do you handle semantic similarity vs exact matches? This is a significant engineering problem.

Using a vector database directly
Pinecone, Weaviate, Qdrant — all great tools, but using them correctly requires embedding pipelines, chunking strategies, retrieval tuning, and ongoing maintenance. Most teams spend weeks getting this right.

What Good Agent Memory Looks Like

A proper memory layer for AI agents needs to do five things:

Persist across sessions — memory survives server restarts and new conversations
Semantic retrieval — find relevant memories based on meaning, not keywords
Automatic chunking — long documents get split intelligently
Synthesized answers — return useful context, not raw chunks
Simple API — developers should not need to understand vector math to use it

The Solution: A Dedicated Memory API

BlueColumn provides exactly this as a hosted API. Three endpoints handle everything:

Store a Memory

import requests

key = "bc_live_YOUR_KEY"
base = "https://xkjkwqbfvkswwdmbtndo.supabase.co/functions/v1"

# After a conversation, store what happened
response = requests.post(
    f"{base}/agent-remember",
    headers={"Authorization": f"Bearer {key}"},
    json={
        "text": "User Sarah is building a customer support agent for her e-commerce store. She sells handmade jewelry. Main pain point is handling return requests.",
        "title": "Sarah - Customer Profile"
    }
)

print(response.json()["summary"])     # Auto-generated summary
print(response.json()["key_topics"])  # ["customer support", "e-commerce", "returns"]

Recall at the Start of a New Session

# Next time Sarah messages, recall her context before responding
context = requests.post(
    f"{base}/agent-recall",
    headers={"Authorization": f"Bearer {key}"},
    json={"q": "What do I know about Sarah and her business?"}
).json()

print(context["answer"])
# "Sarah is building a customer support agent for her e-commerce jewelry store.
#  Her main focus is automating return request handling."

# Now inject this into your agent system prompt
system = f"You are a helpful assistant. Context: {context[answer]}"

Save Agent Observations

# Your agent can save its own notes mid-conversation
requests.post(
    f"{base}/agent-note",
    headers={"Authorization": f"Bearer {key}"},
    json={
        "text": "Sarah gets frustrated with technical jargon. Keep responses simple.",
        "tags": ["sarah", "communication-style"]
    }
)

Before and After

Before BlueColumn:

def chat(user_id: str, message: str) -> str:
    # No memory — every conversation starts fresh
    response = llm.complete(message)
    return response

After BlueColumn:

def chat(user_id: str, message: str) -> str:
    # Recall relevant context first
    memory = requests.post(f"{base}/agent-recall",
        headers={"Authorization": f"Bearer {key}"},
        json={"q": message}).json()["answer"]

    # Respond with context
    response = llm.complete(
        system=f"User context: {memory}",
        user=message
    )

    # Store the interaction
    requests.post(f"{base}/agent-note",
        headers={"Authorization": f"Bearer {key}"},
        json={"text": f"User asked: {message}. Agent said: {response[:200]}"})

    return response

Four lines of code. Your agent now remembers everything.

Real Use Cases

Customer support agents
Remember every past interaction, issue, and resolution. When a customer contacts again, the agent already knows their history.

Personal AI assistants
Store user preferences, ongoing projects, and decisions. The assistant gets smarter over time.

Coding agents
Remember architecture decisions, past bugs, and codebase context. No more re-explaining your tech stack.

Research agents
Accumulate knowledge from papers and articles. Query across everything stored.

Sales agents
Track prospect history, objections raised, and follow-up commitments.

Getting Started Free

BlueColumn has a free tier — 60 minutes of audio ingestion and 100 queries per month, no credit card required.

Sign up at bluecolumn.ai
Copy your API key from the dashboard
Add four lines of code to your agent

Your agent will never forget again.

Questions about implementation? Leave a comment below.

LangChain Memory Is Broken — Here's What to Use Instead

bluecolumn — Fri, 17 Apr 2026 16:19:44 +0000

If you have built anything with LangChain, you have probably run into the memory problem.

You set up ConversationBufferMemory or ConversationSummaryMemory, it works fine in development, and then in production it either runs out of context window, loses history between sessions, or just behaves unpredictably.

LangChain memory was designed for single-session conversations. It was never meant to be a persistent, scalable memory layer for production AI agents. Here is why it falls short and what to use instead.

The Problem With LangChain Memory

1. It dies with the session
ConversationBufferMemory stores history in RAM. When your server restarts or your user opens a new session, everything is gone. There is no persistence by default.

2. It stuffs everything into the context window
Every message gets added back to the prompt. At scale, this gets expensive fast and eventually hits token limits. Your agent starts forgetting older context or throwing errors.

3. It is tightly coupled to LangChain
If you want to use a different framework — AutoGen, CrewAI, a custom agent — you have to reimplement memory from scratch.

4. Vector store memory requires too much setup
VectorStoreRetrieverMemory is closer to what you actually want, but you still need to wire up embeddings, a vector database, chunking logic, and retrieval yourself.

What Production Agent Memory Actually Needs

Persistence across sessions
Semantic search (not just keyword matching)
Framework agnostic — works with anything
Simple API — not a 200-line setup
Scalable — works the same with 1 user or 10,000

BlueColumn: A Dedicated Memory API

BlueColumn is a memory infrastructure API built specifically for this problem. Three endpoints, any framework, persistent across sessions.

import requests

key = "bc_live_YOUR_KEY"
base = "https://xkjkwqbfvkswwdmbtndo.supabase.co/functions/v1"

# Store memory
requests.post(f"{base}/agent-remember",
  headers={"Authorization": f"Bearer {key}"},
  json={"text": "User is building a customer support bot for SaaS", "title": "User context"})

# Recall memory
r = requests.post(f"{base}/agent-recall",
  headers={"Authorization": f"Bearer {key}"},
  json={"q": "What is the user building?"})

print(r.json()["answer"])  # "The user is building a customer support bot for SaaS"

Replacing LangChain Memory With BlueColumn

Here is a direct replacement for ConversationSummaryMemory using BlueColumn:

Before (LangChain):

from langchain.memory import ConversationSummaryMemory
from langchain.llms import OpenAI

llm = OpenAI()
memory = ConversationSummaryMemory(llm=llm)

# Breaks between sessions, expensive, coupled to LangChain

After (BlueColumn):

import requests

key = "bc_live_YOUR_KEY"
base = "https://xkjkwqbfvkswwdmbtndo.supabase.co/functions/v1"

def remember(text: str, title: str = ""):
    return requests.post(f"{base}/agent-remember",
        headers={"Authorization": f"Bearer {key}"},
        json={"text": text, "title": title}).json()

def recall(query: str) -> str:
    return requests.post(f"{base}/agent-recall",
        headers={"Authorization": f"Bearer {key}"},
        json={"q": query}).json()["answer"]

# Works across sessions, any framework, scales automatically

Using BlueColumn With LangChain

You do not have to abandon LangChain — just replace its memory with BlueColumn:

from langchain.agents import initialize_agent, Tool
from langchain.llms import OpenAI
import requests

key = "bc_live_YOUR_KEY"
base = "https://xkjkwqbfvkswwdmbtndo.supabase.co/functions/v1"
headers = {"Authorization": f"Bearer {key}"}

def recall_memory(query: str) -> str:
    r = requests.post(f"{base}/agent-recall", headers=headers, json={"q": query})
    return r.json().get("answer", "No relevant memory found.")

def store_memory(text: str) -> str:
    r = requests.post(f"{base}/agent-remember", headers=headers, json={"text": text})
    return f"Stored. Session ID: {r.json().get(session_id, unknown)}"

memory_tools = [
    Tool(name="recall", func=recall_memory, description="Query persistent memory"),
    Tool(name="remember", func=store_memory, description="Store information in memory"),
]

llm = OpenAI(temperature=0)
agent = initialize_agent(memory_tools, llm, agent="zero-shot-react-description")

# Now your LangChain agent has persistent, cross-session memory
response = agent.run("What do you know about our user?")

Performance Comparison

Feature	LangChain Memory	BlueColumn
Persists across sessions	❌	✅
Framework agnostic	❌	✅
Semantic search	Partial	✅
Audio/doc ingestion	❌	✅
Scales to production	❌	✅
Setup time	Hours	5 minutes

Getting Started

Sign up free at bluecolumn.ai — no credit card required
Copy your bc_live_* API key from the dashboard
Replace your LangChain memory with the three-line BlueColumn API

Free tier: 60 minutes of audio ingestion and 100 queries per month.

Building something with persistent agent memory? Drop a comment — happy to help with the implementation.

How to Add Persistent Memory to Your AI Agent in 5 Minutes

bluecolumn — Fri, 17 Apr 2026 03:48:27 +0000

Your AI agent is stateless. Every session starts from zero — no memory of past conversations, decisions, or user preferences. This is the biggest limitation holding back truly useful AI agents.

In this post I will show you how to add persistent semantic memory to any AI agent in under 5 minutes using BlueColumn — a memory infrastructure API built specifically for this problem.

The Problem With Stateless Agents

Every time a user starts a new session with your agent, it has no idea who they are, what they care about, or what was discussed before. You end up with two bad options:

Stuff everything into the context window — expensive, hits limits fast, gets worse over time
Start from zero every session — frustrating user experience, feels dumb

What you actually need is a memory layer that persists between sessions, scales infinitely, and retrieves the right information at the right time. That is what BlueColumn does.

What BlueColumn Does

BlueColumn gives your agent three simple REST endpoints:

/agent-remember — ingest text, audio, or documents into semantic memory
/agent-recall — query memory with natural language, get an AI-synthesized answer back
/agent-note — store lightweight agent observations and preferences

Everything is backed by Pinecone vector storage and Voyage AI embeddings. You do not need to think about chunking, embedding models, or retrieval pipelines — BlueColumn handles all of it.

Setup

First, sign up at bluecolumn.ai and grab your free API key. You get 60 minutes of audio ingestion and 100 queries per month on the free tier — no credit card required.

Your key will look like: bc_live_XXXXXXXXXXXXXXXXXXXX

Step 1: Store Something in Memory

Let us say a user just told your agent something important:

import requests

key = "bc_live_YOUR_KEY"
base = "https://xkjkwqbfvkswwdmbtndo.supabase.co/functions/v1"

# Store user context
response = requests.post(
    f"{base}/agent-remember",
    headers={"Authorization": f"Bearer {key}"},
    json={
        "text": "User is building a customer support agent for an e-commerce company. They prefer concise responses and are using Python with LangChain.",
        "title": "User Profile - Session 1"
    }
)

data = response.json()
print(data["summary"])      # AI-generated summary
print(data["key_topics"])   # Extracted topics
print(data["session_id"])   # Reference ID for this memory

The response gives you a summary, key topics, and action items — automatically extracted by AI.

Step 2: Recall Memory Later

In a future session, before responding to the user, query their memory first:

# At the start of each session — recall relevant context
response = requests.post(
    f"{base}/agent-recall",
    headers={"Authorization": f"Bearer {key}"},
    json={"q": "What do I know about this user and their project?"}
)

data = response.json()
context = data["answer"]  # AI-synthesized answer from stored memories
sources = data["sources"] # Which memories were used

# Now inject context into your agent prompt
system_prompt = f"""You are a helpful assistant.

User context from memory:
{context}

Use this context to personalize your responses."""

The recall endpoint does not just return raw chunks — it synthesizes an actual answer from your stored memories using RAG. You get back something you can drop directly into a system prompt.

Step 3: Let the Agent Save Its Own Notes

Your agent can also save its own observations between sessions:

# Agent saves an observation after the session
requests.post(
    f"{base}/agent-note",
    headers={"Authorization": f"Bearer {key}"},
    json={
        "text": "User gets frustrated when responses are too long. Keep answers under 3 sentences when possible.",
        "tags": ["preference", "communication-style"]
    }
)

Next session, this preference is in memory and gets recalled automatically.

Putting It All Together

Here is a simple agent loop with BlueColumn memory:

import requests
from openai import OpenAI

key = "bc_live_YOUR_KEY"
base = "https://xkjkwqbfvkswwdmbtndo.supabase.co/functions/v1"
openai = OpenAI()

def chat_with_memory(user_message: str, user_id: str) -> str:
    # 1. Recall relevant memory
    recall = requests.post(
        f"{base}/agent-recall",
        headers={"Authorization": f"Bearer {key}"},
        json={"q": user_message}
    ).json()

    memory_context = recall.get("answer", "No prior context.")

    # 2. Build prompt with memory
    response = openai.chat.completions.create(
        model="gpt-4o-mini",
        messages=[
            {"role": "system", "content": f"You are a helpful assistant.\n\nMemory context:\n{memory_context}"},
            {"role": "user", "content": user_message}
        ]
    )

    answer = response.choices[0].message.content

    # 3. Store this interaction
    requests.post(
        f"{base}/agent-note",
        headers={"Authorization": f"Bearer {key}"},
        json={"text": f"User asked: {user_message}. Agent answered: {answer[:200]}"}
    )

    return answer

That is a complete memory-enabled agent in under 30 lines.

Node.js Version

const key = "bc_live_YOUR_KEY";
const base = "https://xkjkwqbfvkswwdmbtndo.supabase.co/functions/v1";

async function recallMemory(query) {
  const res = await fetch(`${base}/agent-recall`, {
    method: "POST",
    headers: { "Authorization": `Bearer ${key}`, "Content-Type": "application/json" },
    body: JSON.stringify({ q: query })
  });
  return res.json();
}

async function storeMemory(text, title) {
  const res = await fetch(`${base}/agent-remember`, {
    method: "POST",
    headers: { "Authorization": `Bearer ${key}`, "Content-Type": "application/json" },
    body: JSON.stringify({ text, title })
  });
  return res.json();
}

async function saveNote(text, tags = []) {
  const res = await fetch(`${base}/agent-note`, {
    method: "POST",
    headers: { "Authorization": `Bearer ${key}`, "Content-Type": "application/json" },
    body: JSON.stringify({ text, tags })
  });
  return res.json();
}

Common Gotchas

A few things that tripped me up when testing:

/agent-remember field is text not content
/agent-recall field is q not query
/agent-note field is text not note, minimum 5 characters

The error messages tell you exactly what is wrong, but knowing upfront saves time.

Pricing

BlueColumn has a generous free tier:

| Plan | Price | Audio | Queries |
|---|---|---|
|---|
| Free | $0 | 60 min/mo | 100/mo |
| Developer | $29/mo | 600 min | 2,000 |
| Builder | $79/mo | 2,000 min | 8,000 |
| Scale | $249/mo | 6,000 min | 20,000 |

Conclusion

Persistent memory is the difference between an AI agent that feels smart and one that feels like a toy. BlueColumn abstracts away all the complexity — vector storage, embeddings, chunking, retrieval — into three API calls.

If you are building an AI agent, give it memory. Your users will notice.

Have questions about the implementation? Drop them in the comments.