Correct Way to Provide Context to Your AI Agents
If you have spent any time building AI agents, you have probably run into this moment: you tell your agent something important, it responds perfectly, and then one message later it acts like the conversation never happened. Blank slate. No memory. Total amnesia.
This is not a quirk. It is how large language models work by design. Every call to the model is stateless. Without explicit history being passed back each time, the model starts fresh on every turn.
Context Providers are how the Microsoft Agent Framework solves this — and they do a lot more than just memory.
What Is a Context Provider?
A Context Provider is a class that wraps around every LLM call your agent makes. It gets two hooks: one before the call and one after.
Before the call fires, the provider can inject anything into the conversation — previous messages, today's menu, user preferences, business rules, tool definitions. The LLM sees all of it before generating a response.
After the call fires, the provider can extract information, save state, log the interaction, or update a database. Silently, in the background, without the user ever knowing.
This two-hook pattern is the entire API. Once it clicks, you start seeing applications everywhere.
The Memory Question
Here is something that surprises most developers new to the framework. In recent version, the framework automatically injects an InMemoryHistoryProvider even when you pass an empty context_providers list. History is always there by default.
The real question is not whether a provider exists. It is whether you reuse the same session across turns. History lives inside the AgentSession object. Fresh session every turn means no memory. Same session reused across turns means full memory. That is the mechanic.
This is actually the right mental model for production too. Memory in a real application is almost always a session management question. Do you retrieve the user's existing session? Or do you start a new one?
What I Built and Showed in the Video
The video walks through few progressive demos, each one building on the last.
The first demo goes deeper and builds a custom provider from scratch. The UserNameProvider detects when a user mentions their name in after_run, stores it in session state, and then injects a personalised instruction in before_run on every subsequent turn. The agent starts addressing users by name without any changes to its system prompt. The provider does all the work invisibly.
The third demo is my favorite because it shows the real power of the abstraction. The same agent, the same instructions, the same session ID — but the provider swaps from InMemoryHistoryProvider to a database-backed one. History now survives process restarts. A brand new session object loads the previous conversation seamlessly using the session ID. One line changed. The agent never knew.
Why This Matters
Context providers separate two things that most developers accidentally mix: what the agent is, and what it knows.
The system prompt defines what the agent is — its personality, its purpose, its boundaries. Those things are static and belong there.
Context providers define what the agent knows right now — the user's name, today's inventory, the current conversation, the relevant documents from your knowledge base. Those things are dynamic and should never be hardcoded.
Once you build this way, your agents become dramatically easier to maintain. Update the menu? Change the provider's data source. Add a new user preference? Add a new provider. Move from development to production storage? Swap the history provider. The agent itself never changes.
Watch the Full Video
All demos are in the video with live code, real output, and the kind of iteration that makes the concepts stick. If you are building with Microsoft Agent Framework or planning to, this is the foundation you need.
If you found this useful, share it with someone building agents. And drop a comment if you have questions — I read every one.
Comments
Post a Comment