Note: Since a few folks have asked, the picture with Satya is real, not AI. I was fortunate enough to grab a selfie with him while he was exploring the venue.

Introduction

I spent the week at Microsoft Build 2026 in San Francisco. Build is always a good signal for where Microsoft is pushing developers, Azure, and AI next, but this year felt especially focused on agents moving from demos into real applications.

My main role at the event was delivering a 15-minute lightning talk on building faster and smarter agents with Azure Managed Redis and Foundry. I also spent time at the Azure Redis booth as a Redis Expert, talking with developers, architects, partners, and Microsoft field teams about Redis, agent memory, semantic caching, vector search, and migration paths to Azure Managed Redis.

The common thread across the week was simple: AI agents are becoming more real, but the architecture around them still matters a lot. Models are only one part of the system. Once agents need to remember, retrieve context, reduce repeated work, and respond quickly, the data layer becomes critical.

What I presented

My lightning talk was called Faster and Smarter Agents with Azure Managed Redis and Foundry.

The core idea was:

• Foundry orchestrates. Redis remembers.

• Foundry is where the agent workflow comes together. Redis provides the fast memory layer that helps the agent avoid starting from zero on every turn.

The talk focused on three patterns:

1. Semantic caching

2. Vector search for RAG

3. Persistent agent memory

All three are about the same larger problem: stateless agents are expensive, slow, and forgetful. If every turn re-fetches context, re-calls the model, and re-pays for tokens, the experience gets worse as usage grows.

Semantic caching

The first pattern was semantic caching.

Instead of caching only exact prompt matches, semantic caching lets an application reuse prior responses when a new request means the same thing as a previous one. That matters because users rarely ask the same question in the exact same words.

For agent workloads, this can reduce repeated model calls, lower token spend, and improve response time. It is not about replacing the model. It is about avoiding unnecessary model calls when the answer has already been generated and can be safely reused.

Takeaway: Once AI applications see repeated or similar requests, semantic caching becomes a practical way to improve both cost and latency.

Vector search for RAG

The second pattern was vector search for retrieval-augmented generation.

Agents need grounded context. Without retrieval, the model is more likely to guess or answer from incomplete information. With vector search, the agent can retrieve relevant facts, documents, or prior context before generating a response.

The important part is not just storing embeddings. It is combining vector search with metadata filters and text search so the application can retrieve the right information quickly and with enough control.

Takeaway: RAG is only useful if retrieval is fast, relevant, and operationally simple enough to live in the request path.

Persistent agent memory

The third pattern was persistent memory.

A useful agent needs more than a single prompt window. It needs short-term memory for the current conversation and long-term memory for things that should persist across sessions, like user preferences, learned facts, and important context.

This is where Redis fits naturally. It can serve as a fast memory layer for active session state while also supporting searchable long-term memory patterns. In the talk, I showed how Azure Managed Redis can be used alongside Microsoft Agent Framework and Foundry to make that memory available to the agent when it needs it.

Takeaway: Agent memory should be designed intentionally. Short-term state and long-term memory solve different problems, and both matter once agents move beyond demos.

Conversations on the floor

Some of the best conversations happened at the Azure Redis booth.

A lot of people are past the “can we build an AI demo?” phase. The better questions were about what happens after the demo works:

• Where should agent memory live?

• How do we keep latency low as usage grows?

• How do we avoid paying for the same model work over and over?

• How do we retrieve the right context without adding too much operational complexity?

• How do we modernize existing Redis usage as Azure Cache for Redis moves toward retirement?

Those questions are a good sign. They mean teams are thinking about AI applications as systems, not just model calls.

Scott Hanselman

David Fowler

Microsoft Build takeaways

The biggest theme from Build was that agents are becoming a normal part of the application architecture conversation. That changes what matters.

1. Latency matters because agents often sit directly in the user experience.

2. Cost matters because repeated model calls can become expensive quickly.

3. Memory matters because stateless agents feel limited fast.

4. Retrieval matters because grounded answers are better than confident guesses.

5. Operations matter because the architecture has to survive real traffic, not just a conference demo.

Final thoughts

Build 2026 reinforced something I keep seeing across AI conversations: the hard part is no longer just getting a model to respond. The harder part is building the system around the model so it is fast, useful, grounded, and cost-effective.

That is where Redis becomes interesting for agent architectures. It is not trying to be the agent framework or the model. It is the memory layer that helps the rest of the system work better.

For me, the event was a strong mix of presenting, booth conversations, and technical validation. The lightning talk gave me a chance to show the architecture clearly, and the booth conversations confirmed that these are the exact problems teams are starting to run into as they move from AI prototypes toward production applications.