This example demonstrates an AI agent with persistent memory that uses Feast as both a feature store and a context memory layer through the Model Context Protocol (MCP). This demo uses Milvus as the vector-capable online store, but Feast supports multiple vector backends -- including Milvus, Elasticsearch, Qdrant, PGVector, and FAISS -- swappable via configuration.

Agents need more than just access to data -- they need to remember what happened in prior interactions. Feast's online store is entity-keyed, low-latency, governed, and supports both reads and writes, making it a natural fit for agent context and memory.

The agent has four tools. Feast is both the read path (context) and the write path (memory):

Memory is auto-saved after each agent turn (not as an LLM tool call). This follows the same pattern used by production frameworks -- see Memory as Infrastructure below.

The agent_memory feature view stores per-customer interaction state:

This gives agents persistent, governed, entity-keyed memory that survives across sessions, is versioned, and lives under the same RBAC as every other feature -- unlike an ad-hoc Redis cache or an in-process dict.

Production agent frameworks treat memory as infrastructure, not an LLM decision. The framework auto-saves state after each step - the LLM never needs to "decide" to persist:

This demo follows the same pattern: the agent's three read tools (recall_memory, lookup_customer, search_knowledge_base) are exposed to the LLM for reasoning, while memory persistence is handled by the framework after each turn via _auto_save_memory. This ensures consistent, reliable memory regardless of LLM behaviour - no risk of the LLM forgetting to save, double-saving, or writing inconsistent state.

Feast is a natural fit for this checkpoint layer because it already provides:

• Entity-keyed storage: memory is keyed by customer ID (or any entity)
• TTL management: memory auto-expires via declarative feature view TTL
• Schema enforcement: typed fields prevent corrupt memory writes
• RBAC and audit trails: memory reads/writes are governed like any other feature
• Offline queryability: agent memory can be analysed in batch pipelines

• Python 3.10+
• Feast with MCP and Milvus support
• OpenAI API key (for live tool-calling; demo mode works without it)

The script installs dependencies, generates sample data, starts the Feast server, runs the agent, and cleans up on exit.

This creates:

• 3 customer profiles with attributes like plan tier, spend, and satisfaction score
• 6 knowledge-base articles with 384-dimensional vector embeddings
• Empty agent memory scaffold (populated as the agent runs)

In a new terminal:

To run with a real LLM, set the API key and (optionally) the base URL:

Without an API key, the agent simulates the decision-making process with memory:

Scene 4 demonstrates memory continuity -- the agent recalls the SSO conversation from Scene 1 without the customer re-explaining.

With an API key, the LLM autonomously decides which tools to use:

Why a raw loop? This example builds the agent from scratch using the OpenAI tool-calling API and the MCP Python SDK to keep dependencies minimal and make every Feast call visible. All Feast interactions go through the MCP protocol -- the agent connects to Feast's MCP endpoint, discovers tools dynamically, and invokes them via session.call_tool(). In production, you would use a framework like LangChain/LangGraph, LlamaIndex, CrewAI, or AutoGen -- Feast's MCP endpoint lets any of them auto-discover the tools with zero custom wiring (see MCP Integration below).

The LLM sees the tool definitions (JSON Schema) and decides:

• Which tools to call (can call zero, one, or multiple per round)
• What arguments to pass (e.g., which customer ID to look up)
• When to stop (once it has enough information to answer)

All Feast calls go through MCP (session.call_tool()), not direct REST. Memory is saved automatically after each turn by the framework, not by the LLM. This mirrors how production frameworks handle persistence (see Memory as Infrastructure).

• customer_profile: Structured data (name, plan, spend, tickets, satisfaction)
• knowledge_base: Support articles with 384-dim vector embeddings (Milvus in this demo; swappable to Elasticsearch, Qdrant, PGVector, or FAISS)
• agent_memory: Per-customer interaction history (last topic, resolution, preferences, open issues)

The Feast Feature Server exposes all endpoints as MCP tools at http://localhost:6566/mcp. Any MCP-compatible framework can connect:

Building the same agent with a framework: The examples above show the Feast-specific part -- connecting to the MCP endpoint and getting the tools. Once you have the tools, building the agent follows each framework's standard patterns. The key difference from this demo's raw loop: frameworks handle the tool-calling loop, message threading, and (with LangGraph checkpointers or CrewAI memory=True) automatic state persistence natively. Feast's MCP endpoint means zero custom integration code -- the tools are discovered and callable immediately.

Adapting to your use case: The demo's system prompt, tool wrappers (lookup_customer, recall_memory), and feature views are all specific to customer support. For your own agent, you define your feature views in Feast (e.g., product_catalog, order_history, fraud_signals), run feast apply, and start the server. The same three generic MCP tools -- get_online_features, retrieve_online_documents, and write_to_online_store -- serve any domain. With a framework like LangChain or LlamaIndex, you don't even need custom tool wrappers -- the LLM calls the generic Feast tools directly with your feature view names and entities.

For production, Feast fits into a layered platform architecture:

This demo uses Milvus Lite (embedded). For production, swap to any supported vector-capable backend by updating feature_store.yaml:

• Milvus cluster: Deploy via the Milvus Operator and set host/port instead of path.
• Elasticsearch: Set online_store: type: elasticsearch with your cluster URL.
• Qdrant: Set online_store: type: qdrant with your Qdrant endpoint.
• PGVector: Set online_store: type: postgres with pgvector_enabled: true.
• FAISS: Set online_store: type: faiss for in-process vector search.