Agentic RAG implementation.
An agentic retrieval pattern where the agent itself decides when and how to retrieve, built to learn the difference between plain RAG and agent-driven retrieval.
the problem
Standard RAG retrieves on every query whether it helps or not. Agentic RAG flips that: the agent decides whether retrieval is needed, chooses the right source, and can iterate on queries. Wanted to build the pattern end to end rather than just read about it.
the approach
Followed Cole Medin's agentic RAG architecture, using Postgres with pgvector as the vector store and n8n to orchestrate the agent's tool calls. The retrieval step was wired as a tool the agent could invoke rather than a pre-baked step in the pipeline. Kept the scope tight: the goal was to feel the difference between 'retrieve always' and 'retrieve when useful' in practice, not to productionize anything.
the outcome
Built, tested, shelved. The learning held: retrieval decisions belong inside the agent loop, not outside it. That pattern has since shown up in almost every LLM system I've built after.
the lessons
Agentic RAG is less about retrieval quality and more about giving the agent room to decide when it actually needs context. The retrieval becomes a tool like any other, and the tradeoff is latency against answer quality, tunable per use case.
stack
- PostgreSQL (pgvector) ·
- n8n ·
- Anthropic Claude