Arindam1729

When people talk about “knowledge for agents,” it almost always collapses into RAG. But knowledge can, and should—be treated as a first-class runtime tool, not just a context filler.

In most implementations, knowledge lives in a vector database. Agents query it through a search_knowledge tool, often hybrid (keyword + semantic) with re-ranking. That’s essentially “Agentic RAG,” and it works well enough for a lot of use cases.

But once you think of knowledge as runtime-accessible memory, other patterns open up:

1. Dynamic Instructions Most serious agent use cases can’t just dump all instructions into the system prompt. Take a Text2SQL agent: it needs table schemas, column names, data types, and common query templates. You don’t bake all that into the core prompt—you store it and let the agent query the relevant slice when needed.

That’s dynamic instructions: system prompt as RAM, knowledge base as disk. Core logic in RAM, path-specific instructions pulled from disk at runtime.

2. Adaptive Learning Still experimental, but worth considering. The agent monitors its own conversations, flags successes/failures, and updates the knowledge base in the background. If it repeatedly fails on a domain-specific question, it can either suggest new entries or prompt a human admin to add them. Over time, the knowledge base evolves in response to real usage.

This is harder than it sounds (classification, trust, governance), but if solved, it gives agents a feedback-driven memory loop instead of a static RAG pipeline.

Bonus idea: pair the knowledge base with a scratchpad. Let the agent run iterative, multi-step searches over knowledge, not just one-shot retrieval. That’s where “deep research” style behaviors start to emerge.

I would love to know if you have tried dynamic instructions or adaptive learning?

When we first started building with LLMs, the gap was obvious: they could reason well in the moment, but forgot everything as soon as the conversation moved on.

You could tell an agent, “I don’t like coffee,” and three steps later it would suggest espresso again. It wasn’t broken logic, it was missing memory.

Over the past few years, people have tried a bunch of ways to fix it:

1. Prompt stuffing / fine-tuning – Keep prepending history. Works for short chats, but tokens and cost explode fast.

2. Vector databases (RAG) – Store embeddings in Pinecone/Weaviate. Recall is semantic, but retrieval is noisy and loses structure.

3. Graph databases – Build entity-relationship graphs. Great for reasoning, but hard to scale and maintain.

4. Hybrid systems – Mix vectors, graphs, key-value, and relational DBs. Flexible but complex.

And then there’s the twist: Relational databases! Yes, the tech that’s been running banks and social media for decades is looking like one of the most practical ways to give AI persistent memory.

Instead of exotic stores, you can:

- Keep short-term vs long-term memory in SQL tables

- Store entities, rules, and preferences as structured records

- Promote important facts into permanent memory

- Use joins and indexes for retrieval

This is the approach we’ve been working on at Gibson. We built an open-source project called Memori (https://memori.gibsonai.com/), a multi-agent memory engine that gives your AI agents human-like memory.

It’s kind of ironic, after all the hype around vectors and graphs, one of the best answers to AI memory might be the tech we’ve trusted for 50+ years.

I would love to know your thoughts about our approach!

Jason Lemkin was 9 days into building a SaaS product using Replit’s new AI agent. It had rewritten core pages, improved UX, and shipped fast. He called it a “$1M product.”

Then he added a code freeze.

The agent ignored it and deleted the entire production database.

Why?

1. No environment separation. Dev, staging, and prod looked identical to the agent.

2. No human in the loop. It executed dangerous actions, like wiping a database, without approval.

3. No evaluator agent. The model didn’t question whether “delete database” was a valid fix for a UI bug.

This wasn’t a model bug. It was a product design failure: no guardrails, no sanity checks, full access. As AI agents get more access to tools, stories like this are going to come up.

What are your thoughts on this?