IDE Agents with Redis and Azure AI Foundry - Architecture Plan

AI-Native Software Engineer · Paula Silva · linkedin.com/in/paulanunes · v1.0 · 2026-06-05

Companion to "GitHub Agents Platform with Redis and Azure AI Foundry". That document covers the GitHub-hosted cloud agents (coding agent, code review, CLI). This one covers the IDE agents: Agent Mode and the Agents window in Visual Studio Code, and the equivalent in Visual Studio and the GitHub Copilot app.

Executive Summary

The IDE agent runs on the developer's machine, inside the editor, operating on the open workspace, the terminal, and editor context. It is interactive and developer-in-the-loop, unlike the cloud coding agent that runs autonomously in a GitHub-hosted ephemeral environment. That single difference changes where Redis and Foundry plug in.

The short answers:

• Does the governance and economy model apply to IDE agents? Yes. The same primitives govern them: copilot-instructions.md, .instructions.md, .prompt.md, custom agents (.agent.md), MCP allowlists, content exclusion, and organization policy. The Agent Validation Gate still applies; token measurement uses the IDE context-window and BYOK token reporting.³⁹
• Can Redis be used with IDE agents? Not between the editor and the GitHub-managed Copilot backend (that path is GitHub's). Redis enters through two routes: a Custom Endpoint that points the IDE at your own AI Gateway, which fronts Foundry and an Azure Managed Redis semantic cache; or through MCP tools the agent calls that are themselves backed by Redis as a vector store and memory layer.¹⁵⁷
• Where does Foundry fit for the IDE? Two ways. Directly through BYOK: VS Code can use Azure provider models, locally running models through Foundry Local, and Azure AI Foundry tuned models through the AI Toolkit, all selectable in the model picker.¹⁴ Or behind a Custom Endpoint that targets a gateway in front of the Foundry Model Router.

Code completions are a separate path: they stay on GitHub Copilot's own infrastructure, remain included, and are not affected by BYOK or by the agent model choice.¹

Cloud coding agent versus IDE agent

The new Agents window in VS Code brings an agent-first surface to the editor, with multiple parallel sessions and the ability to remotely control longer-running sessions.²

System Context

System Context Diagram

Overview. The IDE agent sits on the developer's machine between the developer and the model and tool plane. It can reach models three ways: the GitHub-managed backend, a BYOK provider directly, or a BYOK Custom Endpoint that targets your own AI Gateway.

Key components. Inside the IDE: Agent Mode and the Agents window, the model picker, the local memory tool, and the file-based primitives. Outside: the local workspace, MCP servers, the GitHub-managed backend, BYOK providers, the AI Gateway, Azure AI Foundry, Azure Managed Redis, and organization policy with Entra ID.

Relationships. The agent operates on the local workspace and calls MCP tools. For inference it uses the picked model: default backend, a BYOK provider, or a Custom Endpoint to the gateway. The gateway fronts Foundry and Redis. MCP servers can also be backed by Redis and Foundry.

Design decisions. The Custom Endpoint is the clean enterprise integration point: it lets a team insert caching, routing and policy in front of the IDE without changing the developer experience. MCP is the second integration point, for retrieval and memory tools.

NFR considerations. Scalability: the gateway and Redis scale server-side, independent of the editor. Performance: Redis short-circuits repeated requests; local models cut latency further. Security: BYOK can run air-gapped; organization policy controls providers; content exclusion limits what leaves the machine. Reliability: the default backend remains a fallback. Maintainability: model choice is configuration, not code.

Trade-offs. BYOK direct to a provider is simplest but bypasses your gateway, so it has no shared cache or central policy. Routing through a Custom Endpoint adds a hop but regains caching, routing and governance.

Risks and mitigations. Risk: developers send sensitive code to an unapproved BYOK provider. Mitigation: the organization BYOK policy (off by default for the org until enabled) and content exclusion; prefer the Custom Endpoint to a governed gateway.¹

Deployment and Topology

Topology Diagram

Overview. Three model paths and one tool path. Path A is the default GitHub-managed backend. Path B is BYOK directly to a provider or a local model. Path C is the governed path: a Custom Endpoint to an API Management AI Gateway that fronts the Foundry Model Router and Azure Managed Redis. MCP tools, local or internal, are the tool path; internal MCP servers are backed by Redis and search.

Key components. On the machine: the editor, local MCP servers, local memory files, and optional local models through Foundry Local or Ollama. In Azure: the AI Gateway, the Model Router, Azure Managed Redis, internal MCP servers, Azure AI Search and Foundry IQ, and Entra ID with organization and Azure Policy.

Relationships. Completions always go to the GitHub backend. The agent's inference goes to whichever model the picker selects. The Custom Endpoint sends governed traffic through the gateway, which caches in Redis and routes through Foundry. MCP tools reach internal servers that use Redis and search.

Design decisions. Foundry Local and Ollama give an air-gapped or low-latency local option. The internal MCP servers are where Redis serves the IDE agent as a vector and memory store without changing the model path. The gateway centralizes semantic caching so every developer benefits, rather than each editor caching alone.⁸

NFR considerations. Scalability: server-side components scale independently of the number of editors. Performance: local models and the Redis cache both cut latency. Security: air-gapped BYOK and content exclusion; private networking for the Azure path. Reliability: three model paths provide natural failover. Maintainability: paths are selected by configuration and policy.

Trade-offs. Local models trade quality and capability for latency, privacy and zero per-token cost. The gateway path trades a network hop for caching and governance.

Risks and mitigations. Risk: inconsistent model choice across a team inflates cost. Mitigation: pin the model tier in custom agents, set the utility-task model for cheap operations like commit messages, and govern providers with policy.²

Data Flow

Data Flow Diagram (governed path with semantic cache)

Overview. A non-completion agent request follows the selected path. Only the Custom Endpoint path runs through the semantic cache and the Foundry Model Router. Code completions never enter this flow; they stay on the GitHub backend.

Key components and flow. The request, the path decision, the three model paths, and on the governed path the embedding, the Redis lookup, the hit decision, the router, the model, and the write-back. The IDE reports real token usage in the context window for BYOK models.²

Design decisions. Putting the cache and router behind the Custom Endpoint means the IDE experience is unchanged while the team gains caching, routing and policy. Semantic caching uses embeddings, so paraphrased prompts hit the same entry.⁸

NFR considerations. Performance: cache hits return fast and free. Security: the gateway enforces policy and the cache respects access controls. Reliability: a miss degrades to the model; an unreachable gateway falls back to default or BYOK direct. Maintainability: the cache and router evolve without touching editors.

Risks and mitigations. Risk: stale cache answers in an interactive session. Mitigation: tune the similarity threshold and TTL; do not cache user-specific final edits, only reusable sub-results.

Key Workflows

Sequence Diagram: an Agent Mode task with MCP and gateway

Overview. The interactive task: the agent loads local context and memory, grounds itself through a Redis-backed MCP tool, runs inference through the governed gateway with a cache short-circuit, proposes edits locally, and the developer reviews inline.

Design decisions and NFRs. Memory, instructions and MCP grounding happen before inference to cut tokens. The developer stays in the loop, which is the safety control for IDE agents. Performance benefits from both the MCP-side and gateway-side caches.

Risks and mitigations. Risk: the agent runs many tool and model calls in a tight loop. Mitigation: scoped context, reasoning-effort control in the model picker, and a per-task token budget from the validation gate.²

Memory, Governance and Economy for IDE agents

Memory. IDE Agent Mode primarily uses the local memory tool, which stores notes as local files in two scopes: a global scope whose first lines load into context at the start of every session, and a workspace scope that persists across conversations but applies only in that project. This is distinct from the GitHub-hosted Copilot Memory used by the cloud agent, code review and CLI. A Redis-backed MCP memory server is the option when you want shared, server-side agent memory in the IDE.⁶

Governance. Organization policy controls whether BYOK is allowed in VS Code (the "Bring Your Own Language Model Key in VS Code" policy), which models and providers are available, and editor preview features. Content exclusion limits what the agent can read. Custom agents, instructions and prompts are version-controlled in the repository and published only from the internal catalog. MCP servers are allowlisted per repository and workspace.¹³

Economy. The IDE adds levers the cloud agent does not have. BYOK shifts heavy workloads off GitHub AI Credits onto direct provider billing, which can be cheaper at volume. Local models through Foundry Local or Ollama cost nothing per token. The model picker exposes a reasoning-effort control to balance quality, latency and cost, and a separate utility-task model setting routes cheap operations like commit-message generation to a lightweight model. Completions stay free on the GitHub backend.²⁴

Phased Development

Phase 1: IDE MVP (default, no Azure infrastructure)

Approach. Ships immediately. Default Copilot models with Auto and the model picker, the file-based primitives, the local memory tool, local MCP tools, and governance through organization policy and content exclusion. Cost levers: pick a cheaper model per task, use the reasoning-effort control, set the utility-task model, and keep output terse.

Phase 2: IDE enterprise (Redis and Foundry)

Adds. BYOK with a Custom Endpoint pointing at an API Management AI Gateway that fronts the Foundry Model Router and an Azure Managed Redis semantic cache; internal MCP servers backed by Redis as a vector and memory store; Foundry Local for air-gapped or low-latency local inference. Air-gapped BYOK supports isolated environments.²

Migration path

1. Keep Phase 1 as the fallback.
2. Enable the organization BYOK policy for the teams that need it.
3. Stand up the AI Gateway, Foundry Model Router and Azure Managed Redis (reuse the Phase 2 Azure plane from the cloud-agent architecture).
4. Configure a Custom Endpoint in the IDE that points at the gateway; pin it in custom agents.
5. Stand up internal MCP servers backed by Redis for retrieval and shared memory.
6. Measure token usage with the IDE context-window reporting and the validation-gate budgets before broad rollout.

References

Paula Silva AI-Native Software Engineer, Microsoft linkedin.com/in/paulanunes