AI project
AI Sales & Support Agent
An agent that remembers what matters, and knows where to keep it.
A sales and support agent built to operate in real-world environments rather than as a demo. Most of the engineering went into the memory architecture: what the agent should remember, for how long, and where that information lives.
- Role
- Design & development
- Stack
- FastAPIGemini 2.5PostgreSQL + pgvectorRedisMem0.NET
Architecture
- FastAPI async backend orchestrating the agent loop and tool calls.
- Gemini 2.5 for reasoning and decision-making.
- PostgreSQL with pgvector for conversation history, structured data and vector search.
- Redis for working memory, caching and session state.
- Mem0 for persistent user memory and preferences.
- Integration with an existing .NET business platform.
Three memory layers
- Working memory (Redis): what the agent is doing right now. Active context, current intent and temporary state, kept fast and ephemeral. Older turns roll up into summaries.
- Knowledge memory (documents + vector search): what the agent knows. Product docs, FAQs and policies, retrieved through semantic search and RAG.
- User memory (Mem0): what the agent remembers about the user. Preferences, recurring needs and communication style, so conversations continue instead of restarting.
Lessons learned
- Vector search alone isn't enough. Retrieval needs structured filtering and ranking or relevant facts get buried in noise.
- Memory isn't a single database. Retention, retrieval pattern and latency needs differ per type.
- Context windows are expensive. Summarising old conversations and promoting the summaries into working memory cuts token usage while keeping continuity.
- Reliability matters as much as intelligence. Every component has a fallback and a graceful degradation path.
- Built the retry logic, backoff, memory and orchestration from scratch first, then moved to LangGraph with a clear understanding of what it solves.