Talks &
conversations.

A search box gives people a small space to express very different needs. In a camera shop, someone might know the exact model they want. Someone else might know the features they need, or simply what they want to film. Those queries ask different things of a search system.

In this Redis webinar, I explored why search can be difficult to get right and how Redis Search supports retrieval as an application grows. The session introduced the base application for the AI tech talk series, with a focus on vector search, filtering, and the latency constraints that become more noticeable when an agent makes several retrieval calls in one turn.

This connects with a question I keep returning to in my teaching: how can a demo help someone prepare for the decisions they’ll face in production?

At AgentCon London, I spoke to an audience of approximately 50 people about reducing LLM calls with vector search. The preceding talk on MCP created a natural transition by mentioning Redis as a way to store state.

Building on that introduction, I showed how Redis vector search can support semantic caching to reduce repeated LLM calls, latency, and cost. Quite a few attendees were unaware that Redis supported vectors, making this a useful opportunity to broaden their understanding of what it can do.

I focused on the decisions that make semantic caching reliable in production. The common anti-patterns include trusting semantic similarity alone, caching every LLM response, overlooking user scoping, and neglecting cache invalidation. Finding a similar question is only one part of deciding whether an answer is safe and appropriate to reuse.

The audience asked thoughtful questions about measuring accuracy and cache effectiveness, invalidating answers when application state changes, and evaluating performance after deployment. One attendee appreciated seeing how a simple semantic-caching architecture could evolve with their use case, while someone building a chatbot recognised its potential to reduce costs.

I also attended a LiveKit workshop where an audience member asked about voice agents with cross-session memory. The facilitator had not explored that use case yet, so I suggested Redis Agent Memory as a potential integration for future LiveKit demos and offered to follow up. It could be an interesting opportunity to explore voice agents with memory.

I pointed developers to the Redis Discord community to continue the discussion, and several attendees said they would connect on LinkedIn. I am looking forward to continuing those conversations and exploring how Redis can support the use cases people shared.

At Python Glasgow, I spoke about building an AI travel agent that can remember useful context across interactions rather than treating every conversation as if it were the first.

Using travel planning as the example, I showed how persistent memory can create richer, more personalised agent experiences. A travel agent becomes much more useful when it can remember details such as a user’s preferences, budget, and accessibility needs across trips.

Building a reliable memory system from scratch becomes complicated quickly. Storing information is only one part of the problem: you also need to decide what to extract, deduplicate memories, scope them to the right user, separate short-term and long-term memory, manage TTLs and expiration, and retrieve the right memories when the agent needs them. This gave me an opportunity to show how Redis can provide much of that infrastructure, allowing developers to focus on the behaviour and experience of their agents rather than rebuilding the underlying memory layer.

The audience asked thoughtful questions, particularly about whether developers can configure TTLs for short-term memories and how AI agents interact with Redis Agent Memory Server in practice.

I also included a QR code for developers who wanted to continue the conversation in the Redis Discord community. It was a useful evening: a chance to introduce Redis as infrastructure for agent memory, hear the questions practitioners have, and build a stronger connection with the local Python community.

A WeAreDevelopers World Congress talk on why stronger models do not remove the need for better context systems around them.

My main argument was that as LLMs get better at reasoning and tool calling, the bottleneck shifts from whether the model can do something to whether we can get the right context to the model at the right time.

I focused on agent memory, traces, and the idea of a context engine: an abstraction layer between agents and the data they need to act, including structured data, unstructured data, APIs, state, history, memory, search, and caching.

My first time speaking at the Edinburgh Data Science and AI meet-up.

I spoke about semantic caching: the idea that LLM applications can reduce cost and latency by recognising when two differently worded questions are really asking the same thing. The simple version sounds easy, but production use brings real design choices: what to cache, how to scope responses to the right users, how to handle false positives, and when cached answers should expire.

The questions and interactions afterwards were excellent. I also enjoyed Stelios Christodoulou’s talk on the ethical, technical, and philosophical considerations of scraping web data in an AI world, especially his framing of a “considerate scraper’s code of conduct”: reuse in-memory copies where possible, respect licensing and attribution, and work with data providers through APIs and alternative sources where you can.

Massive thanks to Emily Takeva, JP Hwang, and David Wood for putting together an excellent event. First time attending this meet-up. Definitely not the last.

A London Java Community talk on building production-ready multi-agent systems with Spring AI and Redis.

I spoke about semantic caching, routing, vector search, and agent memory server, and I also demoed Raphael De Lio’s stock analysis agent app, which tied those ideas together in a practical Spring AI workflow.

There were roughly 50 people in attendance, with most staying through to the end, and the questions were excellent: from short-term versus long-term memory transfer to embedding model choice and why cross-encoders are not usually used in the first stage of vector retrieval. The organisers also asked for a follow-up workshop, which made it feel like a genuinely strong session for the London Java community.

A Devoxx UK conference talk on the complexity that appears when agent memory is split across many tools, databases, and retrieval paths.

The session made the case for a unified memory layer: one abstraction that can handle working memory, persistent knowledge, and agent data access without turning every new memory source into another bespoke tool call.

A Devoxx UK conference talk connecting human memory and practical AI agent design.

Raphael De Lio and I looked at how cognitive science can help frame the problem of agent memory, then tied that back to production concerns: what to store, how to retrieve it, and how our work at Redis led toward a production-ready agent memory server.

A Devoxx France conference talk connecting human memory to the practical challenges of building AI agents with memory.

Raphael De Lio and I looked at how cognitive science can help frame agent memory design, then connected that to production concerns like what to store, how to retrieve it well, and how our work at Redis led toward a production-ready agent memory server.

A first Redis Developer Advocate conference talk on why production AI agents need structured memory.

Raphael De Lio and I covered recurring memory patterns, short-term and long-term memory management, retrieval, decay, and how Redis Agent Memory Server helps teams move beyond stateless agent prototypes.