GitHub Agents Platform with Redis and Azure AI Foundry - Architecture Plan

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

Executive Summary

This document applies a full architectural assessment to an enterprise platform where GitHub Copilot agents (the cloud coding agent, Copilot code review, and Copilot CLI) operate as governed, cost-controlled collaborators, with Azure AI Foundry as the model-routing and evaluation plane and Azure Managed Redis as the cache, vector, and memory layer.

The short answers to the three questions that drive this design:

• Does the token-economy and governance model apply to GitHub agents? Yes, fully. GitHub Copilot agents are configured by the same file-based primitives (copilot-instructions.md, AGENTS.md, .agent.md, .prompt.md, skills, hooks, MCP), pass the same Agent Validation Gate, and are governed by the same internal catalog and control plane.
• Can Redis be used with them? Yes, but not inside the GitHub-hosted ephemeral agent runtime. Redis is the cache, vector, and memory layer for the model-serving plane that the agents and any custom AI apps call through. Azure Managed Redis provides three patterns: semantic caching, a vector knowledge store for grounded retrieval, and a memory layer for state and personalization.⁴⁵
• Where does Foundry fit? Azure AI Foundry is the model plane: Model Router for runtime model selection across cost and quality modes, Foundry Agent Service for hosted agents and tools, Foundry Evaluations for the validation gate, and Foundry IQ as the retrieval plane. Governance is enforced with Azure Policy.³¹

The design is delivered in two phases: a Phase 1 minimum viable platform that is GitHub-only and ships on day one with zero Azure infrastructure, and a Phase 2 target architecture that adds the Redis serving layer and the Foundry model and evaluation plane, with a clear migration path between them.

System Context

System Context Diagram

Overview. The platform sits between developers and the GitHub flow on one side, and the Azure model and data plane on the other. Developers interact only with GitHub Copilot agents; the agents reach the model plane through a governed serving layer.

Key components. Developers, catalog maintainers and enterprise admins are the actors. The system boundary contains the Copilot agents, the internal catalog and control plane, and the model and serving plane. External systems are GitHub Enterprise Cloud, Azure AI Foundry, Azure Managed Redis, the model providers reached through Agent HQ, MCP servers, Microsoft Entra ID for identity, and Azure Monitor for telemetry.

Relationships. Agents read and write GitHub primitives (issues, pull requests, Actions) and call the serving plane for inference. The serving plane routes through Foundry and consults Redis. Foundry reaches the model providers. The control plane constrains which agents and models developers can use.

Design decisions. Developers never call models directly; every inference flows through a governed plane so routing, caching and policy are centralized. Identity is centralized in Entra ID. Telemetry is centralized in Azure Monitor.

NFR considerations. Scalability: the serving plane scales independently of the agent runtime. Performance: Redis sits in front of the model for low-latency reuse. Security: identity and policy are external to the agents. Reliability: Foundry Model Router provides failover across the approved model set.³ Maintainability: agents are file-based artifacts in the catalog.

Trade-offs. Centralizing the serving plane adds a network hop and an operational surface, in exchange for governance, cost control and observability.

Risks and mitigations. Risk: the serving plane becomes a single point of failure. Mitigation: Model Router failover, Redis high availability, and a Phase 1 fallback path that uses GitHub Copilot directly when the Azure plane is unavailable.

Architecture Overview

The architecture follows three patterns. First, governed agents: every Copilot primitive is a versioned, budgeted artifact published only to an internal catalog and enforced by the Agent HQ control plane. Second, the two-loop serving model from the Azure Managed Redis reference architecture: a continuous build loop that curates a prompt-and-response catalog and refreshes vector knowledge, and a real-time serve loop that answers from Redis at speed and falls through to the model on a miss.⁴ Third, policy-as-code governance: routing tiers, model allowlists and deployment policy live in AGENTS.md, the control plane, and Azure Policy.

The GitHub Copilot coding agent itself runs in a secure, ephemeral development environment powered by GitHub Actions, where it clones the repository, explores the codebase with retrieval augmented generation over GitHub code search, runs tests and linters, and pushes commits to a draft pull request.⁸⁹ That ephemeral environment is GitHub-hosted (or self-hosted via Actions Runner Controller for private infrastructure), so Redis and Foundry are not inside it; they sit in the model and serving plane that the agent and any companion AI applications consume.¹⁰

Component Architecture

Component Diagram

Overview. The platform has three component groups: governance and catalog, the agent runtime, and the model and serving plane.

Key components. Governance holds the internal catalog, the validation gate, the control plane allowlist, and Azure Policy. The runtime holds the coding agent, code review, the CLI, and Copilot Memory. The serving plane holds routing, cache, vector retrieval, and evaluation.

Relationships. The catalog feeds validated artifacts to the runtime; the gate feeds the catalog and uses Foundry Evaluations. The control plane constrains the runtime. Agents write and read Copilot Memory. The runtime calls routing, which consults cache and vector retrieval. Azure Policy governs what routing can deploy.

Design decisions. Routing, cache and retrieval are separate components so each can be measured and scaled independently. The validation gate is a first-class component, not an afterthought, because token budgets and quality bars are set there.

NFR considerations. Scalability: cache and vector components scale horizontally. Performance: cache short-circuits the model. Security: the control plane and Azure Policy enforce least privilege at runtime and deploy time. Reliability: routing has failover; memory is verified just in time. Maintainability: each component is independently versioned.

Trade-offs. More components means more moving parts and more telemetry to watch, in exchange for measurability and independent scaling.

Risks and mitigations. Risk: cache staleness returns wrong answers. Mitigation: similarity-threshold tuning, TTL, and eviction policies on Redis; never cache user-specific final decisions.

Deployment Architecture

Deployment Diagram

Overview. Two deployment domains: GitHub Enterprise Cloud hosts the agent runtime; an Azure landing zone hosts the model and serving plane behind private networking.

Key components. On GitHub: repositories, Actions, the ephemeral coding-agent environment, the GitHub MCP server, branch protections with CodeQL and secret scanning, and optional self-hosted ARC runners. On Azure: a virtual network with Application Gateway and Web Application Firewall, private-endpoint, Foundry-integration and agent-egress subnets; the Foundry project with Model Router, Agent Service, Evaluations and IQ; the dependencies Cosmos DB, Azure AI Search, Storage, Key Vault, Azure Managed Redis and optional API Management; plus Entra ID, Azure Monitor and Azure Policy.

Relationships. The coding agent runs in the ephemeral GitHub Actions environment, reaches tools through the GitHub MCP server, and egresses to Azure through the firewall, gateway and AI Gateway into the Model Router. The Model Router calls the Agent Service, which uses Cosmos DB, Search, Storage and Key Vault. The AI Gateway and serving apps consult Azure Managed Redis. Evaluations gate the router. Azure Policy governs deployments.¹²

Design decisions. The Foundry Agent Service dependencies (Cosmos DB for conversation state, AI Search, Storage) are deployed inside the subscription for control, matching the baseline reference.¹ Azure Managed Redis is the serving-speed layer. API Management as an AI Gateway is optional but lets semantic caching live at the gateway rather than in each app.⁷ The coding-agent runtime stays GitHub-hosted by default; ARC self-hosted runners are the option when agents must reach private infrastructure.¹⁰

NFR considerations. Scalability: App Service and Foundry span availability zones; Redis scales in-memory. Performance: private endpoints reduce latency; Redis serves sub-second. Security: all PaaS reached via private endpoints, egress through Azure Firewall, secrets in Key Vault, identity via Entra ID, deployment governed by Azure Policy. Reliability: zone-redundant services and Model Router failover. Maintainability: infrastructure as code in the landing zone.

Trade-offs. Private networking and a landing zone add deployment complexity and cost, in exchange for enterprise security and compliance posture.

Risks and mitigations. Risk: the ephemeral agent cannot reach internal dependencies. Mitigation: ARC self-hosted runners with copilot-setup-steps.yml.¹⁰ Risk: egress data exposure. Mitigation: Azure Firewall egress control and content exclusion on the agent.

Data Flow

Data Flow Diagram

Overview. Data moves through two coupled loops. The build loop continuously curates a catalog of prompts and approved responses and refreshes the vector knowledge. The serve loop answers in real time from Redis and falls through to the model only on a cache miss.⁴

Key components. Build loop: content sources, retrieval, agents, model, the evaluation quality gate, and the curated catalog. Serve loop: the incoming query, embedding, the Redis semantic-cache lookup, the hit decision, routing, the model, the write-back to Redis, and the response. Telemetry captures tokens and credits.

Relationships. The build loop populates the catalog, which seeds the cache. The serve loop embeds the query, checks the cache, returns on a hit, and on a miss routes to a model, then writes the new pair back. Every response emits token and credit telemetry.

Design decisions. Semantic caching uses embeddings, not exact-string keys, so paraphrased queries hit the same entry; the cache is checked before any expensive generation.⁷⁵ A quality gate sits between the model and the catalog so only approved responses are reused. Cache only the deterministic, reusable layer; final user-specific decisions stay fresh.

NFR considerations. Scalability: the serve loop handles many concurrent queries from in-memory Redis. Performance: cache hits return up to an order of magnitude faster than regeneration.⁶ Security: cached content respects data-access and privacy controls and eviction policies. Reliability: a cache miss degrades gracefully to the model. Maintainability: the build and serve loops are decoupled, so either can change independently.

Trade-offs. A semantic cache can return a near-miss answer if the similarity threshold is too loose; tuning the threshold trades recall against precision.

Risks and mitigations. Risk: stale or poisoned cache entries. Mitigation: TTL, eviction policies, the quality gate on writes, and the similarity threshold. Risk: sensitive data in the cache. Mitigation: scope, encryption and retention controls on Azure Managed Redis.

Key Workflows

Sequence Diagram: assign an issue to the coding agent

Overview. The critical workflow is assigning a GitHub issue to the coding agent and following it to a merged pull request, with the cache short-circuit and the code-review step shown.

Key components. The developer, GitHub, the coding agent, Copilot Memory, the Redis semantic cache, the Foundry Model Router, the model, and Copilot code review.

Relationships and flow. The agent boots an ephemeral environment, retrieves context with RAG and Memory, checks the cache, and either returns a cached result or routes to a model and writes back. It pushes to a draft pull request, updates Memory, triggers code review (which consumes Actions minutes), and waits for human approval before merge.⁸⁹¹²

Design decisions. Memory and cache are consulted before the model to cut tokens. Code review runs after the draft PR. Human approval gates the merge and any CI/CD.⁹

NFR considerations. Performance: cache and memory cut latency and tokens on repeated subtasks. Security: branch protections and human approval remain in force. Reliability: a cache miss degrades to the model. Maintainability: the flow is observable through session logs and telemetry.

Trade-offs. Adding cache and memory checks adds a small per-step lookup cost, justified when the reuse rate is high.

Risks and mitigations. Risk: the agent acts on a stale memory. Mitigation: just-in-time citation verification discards memories whose code citations no longer hold.¹¹

Additional Diagrams

Agent task state diagram

Overview. The lifecycle of a single agent task, including the re-scope path when a task fails or exceeds its token budget.

Design decisions and NFRs. A budget-exceeded transition makes cost a first-class failure mode, not a silent overrun; this supports the maintainability and cost-control goals. The re-scope loop preserves reliability by giving a failed task a defined recovery path rather than leaving it stuck.

Risks and mitigations. Risk: tasks loop indefinitely between Implementing and Failed. Mitigation: a retry cap and escalation to a human owner.

Governance and catalog data model (ERD)

Overview. The data model behind the internal catalog and the validation gate, linking artifacts to versions, golden tasks, budget measurements and model tiers, plus the memory facts and cache entries they generate.

Design decisions and NFRs. Tying budget measurements to versions and golden tasks makes the gate auditable and supports re-validation when a model or rate changes, which serves maintainability and governance.

Security architecture (zones and controls)

Overview. Security is layered across a public zone, a GitHub trust zone and an Azure trust zone.

Key controls and NFRs. GitHub zone: content exclusion, agent and model allowlist, CodeQL, secret scanning, branch protections, human approval. Azure zone: Web Application Firewall, private endpoints, Azure Firewall egress, Entra ID and managed identities, Azure Policy, Key Vault. Security NFR: defense in depth, least privilege, no secret exposure to the agent, deploy-time policy. Reliability NFR: the controls do not block the Phase 1 fallback path.

Risks and mitigations. Risk: a misconfigured allowlist lets an unapproved model process prompts. Mitigation: the Foundry Model Router model subset acts as a hard allowlist and fallback set.³

Phased Development

Phase 1: Initial Implementation (MVP, GitHub-only)

Overview and approach. Phase 1 ships on day one with no Azure infrastructure. It uses GitHub Copilot agents configured by repository files, Auto model selection for routing, Copilot Memory for the warm tier, the internal catalog and the validation gate for governance, and human approval for safety. This is the Monday-morning platform: every cost lever (output control, scoped context, Auto routing, budgets, content exclusion, memory) is available with config alone.

What it delivers. Governed agents, token budgets, an internal catalog, and the full cost-control playbook. It does not yet have a semantic cache, runtime model routing across providers with cost modes, or a dedicated evaluation and retrieval plane.

Phase 2: Target Architecture (Redis and Foundry)

The target architecture is the full Deployment Diagram above: it adds Azure Managed Redis as the semantic cache, vector and memory layer; Azure AI Foundry Model Router for runtime model selection with Balanced, Cost and Quality modes and failover; Foundry Evaluations as the validation-gate engine; Foundry IQ and Azure AI Search as the retrieval plane; optional API Management as an AI Gateway; and private networking with Azure Policy governance.

What it adds. Sub-second reuse and large token savings on repetitive workloads through the semantic cache, provider-level routing with cost modes, a formal evaluation plane, and enterprise networking and policy.

Migration path (Phase 1 to Phase 2)

1. Keep Phase 1 running. The GitHub-only platform remains the fallback path.
2. Stand up the Azure landing zone: virtual network, private endpoints, Entra ID, Key Vault, Azure Monitor, Azure Policy.
3. Deploy Foundry (account, project, Agent Service) and its dependencies (Cosmos DB, Azure AI Search, Storage).
4. Deploy Azure Managed Redis; start with semantic caching on one high-reuse surface (internal question-answer or enablement), measure hit rate, then add vector and memory patterns.
5. Introduce the Foundry Model Router with a two-model subset minimum; benchmark against the Phase 1 baseline with Foundry Evaluations before shifting traffic.
6. Add API Management as an AI Gateway only if you want semantic caching centralized rather than per application.
7. Reserve provisioned throughput only after the sustained load pattern and the cache hit rate are measured.

Diagram assets (draw.io and official icons)

A draw.io version of the target deployment architecture ships alongside this document as github-agents-target-architecture.drawio, ready to open in diagrams.net. To render it with the official Microsoft and Azure icons rather than the labeled tiles:

• Download the official set from the Azure Architecture Center, the authoritative source. Microsoft permits use of these icons in architecture diagrams, and the rules are: do not crop, flip, rotate or distort them, and include the product name near each icon.¹³
• Or load a one-click diagrams.net library of the official Azure icons and swap each tile for the matching icon.¹⁴

GitHub platform marks follow the GitHub brand guidelines; represent GitHub, Issues, Pull Requests and Actions with the official GitHub logo and Octicons per those guidelines.

References

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