One Knowledge Base, Many Agent Personalities

I kept running into the same problem every time I shipped a second AI agent.

The first agent was fine. It answered questions over a document set and everyone was happy. Then someone asked for a sales-flavored version, and then an engineering-flavored version, and suddenly I was staring at three retrieval stacks that all needed the same documents, the same embeddings, and the same updates.

That is how knowledge bases rot. Not all at once. One agent gets updated docs, the others do not, and three weeks later your sales agent is confidently citing a pricing page that stopped existing.

So I built the opposite shape as a Telnyx code example: one shared retrieval layer, many personalities on top.

The code example is here:

https://github.com/team-telnyx/telnyx-code-examples/tree/main/rag-corpus-shared-across-agents

The Shape

Two actor types on Telnyx Edge Compute.

CorpusAgent is the knowledge base. One actor instance per corpus. It takes documents from a Cloud Storage bucket or a direct upload, chunks them, embeds them with Telnyx Inference, and stores the vectors in its own durable SQL:

chunks(id, doc, ord, text, embedding)

Every row remembers which document it came from. That single decision is what makes citations possible later.

PersonaAgent is the voice. One durable actor per persona — support, sales, engineer in the sample. Each one has a different system prompt and, this is the part I like, its own conversation history. Two people can have two separate conversations with the "sales agent" and the actor keeps those threads apart, durably.

The Demo Moment

The sample's demo knowledge base is real Telnyx platform documentation, so the demo is Telnyx answering questions about Telnyx.

You type:

How do I deploy an edge function?

The support agent answers with a numbered walkthrough. Switch the dropdown to the sales engineer, ask again, and you get the same facts wrapped in outcomes. The solutions engineer gets you exact command names with no marketing.

Same sources. Identical similarity scores. Three voices.

That is the whole pitch in one screen: retrieval is a shared service, personality is a thin layer on top, and the facts never drift between agents.

The Honesty Beat

There is a second demo moment I show right after. Change the corpus id to a name with no documents and ask anyway.

The agent says, plainly, that it found no matching documents.

No improvisation, no confident nonsense. If you have ever watched a RAG demo die because the model invented an answer to a question the corpus never covered, you know why I show this on purpose.

Why It Holds Up

Three reasons this shape survives past the demo.

One retrieval layer to maintain. Improve chunking or swap the embedding model in one place and every persona gets smarter at once.

Facts cannot drift. The corpus actor is the only source of truth. Personas differ in voice, never in facts.

It is all platform primitives. The vector store is per-actor SQLite. Embeddings and chat run through the pre-authenticated TELNYX binding. Documents arrive through a Cloud Storage bucket binding. The deployed function holds zero API keys, because the platform authenticates the bindings.

Try It

git clone https://github.com/team-telnyx/telnyx-code-examples.git
cd telnyx-code-examples/rag-corpus-shared-across-agents
npm install
npm run local:dev

Seed the docs, ask the same question as all three personas, then push one persona with follow-ups and watch it keep its own thread while reading the same knowledge base as everyone else.

When your corpus outgrows in-actor ranking, the search swaps to Telnyx's managed bucket similarity search and nothing about the personas changes. That is the part I would bet on: the retrieval layer is a service, and services get better without anyone rewriting their agents.