In this video, Cole Medin draws a sharp line between two kinds of AI agents. On one side are personal agents (second brains) built on the Karpathy LLM wiki: a coding agent like Claude Code, Hermes, or OpenClaw running locally, managing interconnected markdown documents with index files, tagging, categorization, and entities. On the other side are production agents you ship to other people, where the markdown-driven wiki simply does not scale. Medin argues that once you have many users, live data, access control, and cost pressure, you must switch to a database with a context layer on top. He demos that architecture (a context retriever plus agent memory) using Redis and the preview product Redis Iris, driven by a Pydantic AI agent. Medin discloses he is working with Redis on this video.
Medin opens by noting that everyone is currently hyper-fixated on personal agents. You typically run a coding agent like Claude Code, Hermes, or OpenClaw on your machine to manage a set of interconnected markdown documents that form your knowledge base, often a Karpathy LLM wiki with index documents, tagging, categorization, and entities that you build up over time. He uses his own every single day and says these agents are extremely powerful. But there is a line: personal agents do not scale, and specifically the moment you want to ship an agent to other people, the locally running LLM wiki setup cannot be used and the architecture has to look totally different. He says he has covered personal agents a lot lately and wants to cover the other side of the coin.
Everything for a personal agent is markdown driven, whether you build it yourself or use something off the shelf like Hermes. The reason is that markdown is the simplest and most flexible option. It is easy to build up your knowledge base over time through conversations with your second brain, and the power is keeping everything on your own system so it is as accessible and fast as possible. At this stage you do not care about governance, access control, traceability, or auditability, the concerns that production systems require.
That changes as soon as other people use your agent. With many users at once and live data, you must care about access control and retrieval at scale, and markdown stops cutting it. There is a reason databases exist: managing everything with markdown documents means organization, search, and even just creating and managing all the files will never scale. Second brains are also expensive. They generally use a coding agent SDK like Claude or Codex tied to a personal subscription, which is not allowed in production, and having the agent read entire markdown documents cannot be optimized enough to scale retrieval and cost.
Shipping an agent for others has to look different while keeping the same benefits of a second brain: user memories and information organized so the agent can retrieve well. Medin stresses this production setup is actually far more common than personal agents. People are fixated on personal agents for good reason (they apply to everyone's job and personal life), but almost anything providing real business value is an agent shipped as part of a platform to a production environment with other people logging in.
So you use a database to scale rather than a Hermes or Claude Code markdown wiki. The database needs to store and expose two things to the agent: a context retriever and agent memory. Together they act as a wrapper over the database, the context layer for the agent. The context retriever gives the agent access to business data and tells it the format and what it can query; the agent memory holds the short-term and long-term memory for customers so the agent builds up intelligence about each user over time.
For the demo, Medin uses Redis, calling it the best platform to show both business context and user memory in one place because it recently released Redis Iris (in preview), a wrapper over Redis that gives agents better access. He openly discloses that he is working with Redis on this video: they reached out, he had been looking for a database platform to use for exactly this example, and he says he has been impressed by their context retriever and agent memory. He reiterates the ideas apply to any production system; Redis just gives the best current explanation.
The example dataset is a key-value store of mock data for an e-commerce store, chosen because every e-commerce store should have both an analytics agent and a customer-facing support agent. The data (customers, orders, products, shipments) is stored as flexible, unstructured key-value pairs in Redis.
Medin builds the agent with Pydantic AI, still his recommendation for production agents. He explains that coding agent SDKs like the Claude Agent SDK or Codex SDK, though popular, are slower and more token heavy because they are made for longer agentic coding tasks, so for anything shipped to production he prefers Pydantic AI. The agent has access to the Context Retriever MCP and tools for agent memory, all in the same Redis database via Redis Iris.
In the demo he identifies himself as customer Jordan Rivera (customer 1004) and asks, "Why is my order late, and can you handle it the way I asked last time?" This is a loaded request: it needs memory to know what "last time" meant and needs to search business data for that customer's orders. His CLI lists every tool the agent called: it searched memories for order-handling preferences, got customer info, found the orders, and used them to get the shipment. Notably, the answer required a lot of context but cost under a thousand tokens.
The context retriever provides the structure that unstructured Redis key-value data lacks, which Medin compares to the metadata in a Karpathy LLM wiki: you tell the agent the ways it can search and filter so it can access things efficiently. When you set up a retriever service, it documents and establishes structure for the agent and even auto-generates an MCP server, building the intelligence of your data into tools for filtering and text search so the agent can search the database at scale regardless of record count.
In the Redis dashboard, setting up a new service (his is "North Peak support") exposes an MCP endpoint. You first define your entities (customer, product, and so on), another tie back to the Karpathy wiki, mapping roughly one-to-one to the tables in the underlying Redis database and specifying a schema (types, relationships) like a knowledge graph. Once entities are defined, it automatically generates all the MCP tools based on how you access the data: essentially a tool for each attribute (filter a customer by city or email) plus full text search on text fields like descriptions. Medin calls auto-generated tools his favorite part of the platform.
Attaching the MCP server is straightforward: Medin says he literally gave the documentation to his Claude Code and told it to connect and authenticate the Context Retriever MCP, and it one-shot the whole thing. He then shows analytics queries. Asking "show me every delayed order with its product and total" returns five delayed orders via a single MCP tool call to filter orders by status, instead of reading an index document, chasing markdown files, or figuring out a schema. Asking "do we have any support tickets mentioning a refund" triggers a text search, again a single MCP call, returning five matching tickets. The takeaway: whatever the agent needs in the database, there is an MCP tool for it, and if one is missing you adjust the entities and types to surface it.
Agent memory covers both short-term and long-term memory for all interactions. Medin's favorite part is that Redis Iris stores short-term memory for every conversation and runs a background process that extracts the key information and promotes it to long-term memory. This mirrors a common personal-agent technique of extracting key findings into a promoted memory.md file always given to the agent. Long-term memories use vectors and semantic search (more traditional RAG), so each user can have millions of memories and the system still pulls the most important ones for the next conversation.
In the dashboard, agent memory is created as a service like the context retriever, except it is an API endpoint, not an MCP server. Medin used Claude Code to build the memory tools into his Pydantic AI agent. The memory folder holds session (short-term) memory and long-term memory, where each entry has a vector (for the agent to search, not human readable) and a text version. One long-term entry reads "user prefers reshipments over refunds for delayed orders," the golden nugget extracted from the earlier Jordan Rivera conversation.
To prove recall, Medin starts a new session, states a preference ("whenever an order is delayed, always reship it expedited instead of refunding me"), then in a brand-new conversation asks about his preferences and the agent instantly pulls the memory, confirming "you strongly prefer reshipments over refunds." He notes the ideas apply to any infrastructure, but building it yourself means maintaining the extraction process, the search tooling, and deletion; Redis Iris handles the entire memory management layer for you while keeping full control and visibility since everything lives in your own Redis database.
He closes by reaffirming both lanes. You do not need this for personal agents: an LLM wiki with Hermes, Claude Code, or Obsidian is ideal to keep things simple and flexible. But as soon as you go to production with other people using your agent, the database-plus-context-layer architecture is what you need. Medin says he will keep making content on both lanes because both are important.
Medin's core argument is that the Karpathy LLM wiki is genuinely great, just not for the job of shipping an agent to other people. The markdown second brain wins on simplicity and flexibility for personal use, but production demands a database, access control, scalable retrieval, and cost discipline. His answer is a context layer over the database made of two parts: a context retriever that gives the agent structured, MCP-tool access to business data, and an agent memory that stores and promotes user memories with vector search. Using Redis and Redis Iris with a Pydantic AI agent, he shows the payoff in a working demo where the agent answers a memory-and-data query in under a thousand tokens. The parting lesson is to match the architecture to the audience: keep the LLM wiki for yourself, and reach for the database context layer the moment other people log in.