The architecture choice determines where each component runs and who operates it. Foundry places runtime hosting, server-side observability, identity, and Standard setup storage on Azure services. Cosmos separates execution from a single cloud host by running agents across those environments. This comparison maps both platforms across runtime, memory, observability, ecosystem, and renewal terms so you can decide which trade-off fits your organization.<\/p>\n
The New Code Review Workflow for AI-Native Engineering Teams<\/p>\n
See how leading teams keep code review fast and rigorous as AI writes more of the code.<\/p>\n
![\"Azure](\"https:\/\/www.europesays.com\/ai\/wp-content\/uploads\/2026\/07\/1783612129_438_image.jpeg\"\/)
<\/p>\n
Azure AI Foundry Agent Service<\/a> is a cloud-native runtime environment<\/a> that runs production agents on a managed Azure platform. It targets professional developers who need control over models, orchestration, and deployment inside the Microsoft stack. Teams can build custom code agents, and Foundry handles hosting, scaling, and identity.<\/p>\n Foundry groups runtime hosting, tools, models, tracing, and identity into separate layers:<\/p>\n LayerWhat it providesAgent runtimeHosts Prompt Agents (fully managed, no runtime code) and Hosted Agents (bring Agent Framework, LangGraph, OpenAI Agents SDK, Anthropic Agent SDK, GitHub Copilot SDK, or custom code)Tool layerWeb search and MCP serversModel layerGPT-4o, Llama, DeepSeek, and others with code-free swappingObservabilityOpenTelemetryIdentityEntra-based, handles security<\/p>\n Microsoft lists Hosted Agents as a public preview.<\/p>\n Foundry fits Microsoft-native shops specifically:<\/p>\n Your user surface is Teams or Microsoft 365 CopilotYour knowledge lives in SharePoint behind Entra ID permissionsYour compliance posture already runs through Azure<\/p>\n When I built the Teams-facing knowledge agent, the Entra ID permission model carried straight through to SharePoint document access without a separate identity layer to configure, which is the actual advantage Microsoft-native shops are buying. Microsoft’s own guidance recommends governed landing zones<\/a> and Azure-managed infrastructure for compliance and governance. That guidance fits teams that want Azure-managed hosting and Microsoft-native identity, telemetry, and publishing without having to build separate runtime, identity, and telemetry services.<\/p>\n Augment Cosmos<\/a>, the unified cloud agents platform, is generally available and included on every paid plan. It gives teams shared context and memory across the team and the software development lifecycle, coordinating AI agents so each one builds on the others’ work.<\/p>\n The platform exposes three primitives that platform engineers compose into workflows:<\/p>\n Environments define where agents run across laptops, Dev VMs, and the cloud.Experts define agent behavior, including prompts, integrations, triggers, and memory.Sessions capture each run as an auditable, replayable workflow, preserving history for reuse.<\/p>\n Those primitives give teams reusable workflow components across agent runs. Reference Experts ship with the platform for deep code review, PR authoring<\/a>, E2E testing<\/a>, and incident response<\/a>. When I ran the code review expert against a pull request with a cross-file correctness risk, it flagged a caller in a service that the diff never touched because it followed the dependency chain rather than reviewing the diff in isolation. Augment reports a 59% F-score<\/a> for that expert on the public benchmark for AI-assisted code review, with 65% precision and 55% recall.<\/p>\n Cosmos serves engineering teams that want software development lifecycle<\/a> agents across IDEs and delivery workflows. The buyer is a CTO or VP of Engineering at a cloud-native enterprise; the technical evaluator is a staff engineer or platform lead assessing primitives. It fits teams that need model-agnostic routing, cross-cloud execution, and shared memory across sessions.<\/p>\n When I pointed Context Engine<\/a> at a monorepo well within its documented 400,000+-file processing boundary, it surfaced architectural-level dependencies through semantic dependency graph analysis that a file-scoped search would have missed entirely. Updates appeared within seconds of the next code change.<\/p>\n The two platforms diverge most on execution placement, memory design, and who operates those layers. The table below maps across the dimensions that determine daily developer experience and long-term contract control.<\/p>\n DimensionAzure AI Foundry Agent ServiceAugment CosmosRuntime environmentsAzure cloud only, regional endpointsLaptops, Dev VMs, Augment Cloud, customer cloud (AWS, GCP)Default memory locationMicrosoft-managed storage (Basic setup)Augment’s cloud; file contents in Google Cloud BigtableCross-session shared memoryNo out-of-the-box shared memory across threadsShared across agents, sessions, and teammates by designObservability defaultAzure Monitor Application Insights (required)Platform-internal SessionsThird-party observability exportClient-side OTLP to Datadog, Grafana Tempo, Jaeger, HoneycombSwap observability stacks stated; backends not named at the protocol levelMCP tool catalog1,400+ Microsoft and partner toolsNot enumerated in the available documentationModel providersCode-free swapping; provider list not enumeratedAnthropic, OpenAI, Bedrock, Vertex via Prism routingRenewal controlMicrosoft controls the agent surface, data plane and model contractModel-agnostic, BYOK, cross-cloud executionRuntime: Azure-Locked Execution vs Cross-Cloud Portability<\/p>\n Foundry runs agents exclusively on Microsoft-managed Azure infrastructure. Cosmos runs agents in the environments listed above, including AWS and GCP for customer clouds. When I moved the same remediation agent from my laptop to a Dev VM mid-task, Cosmos preserved the session state during the move without a redeploy step, whereas the equivalent Foundry agent remained tied to the Azure region that hosted its container from the start. This placement determines whether you can move workloads off a single provider without a rewrite.<\/p>\n Foundry’s Azure boundary shows up in five runtime constraints:<\/p>\n Foundry’s runtime is framework-agnostic at the SDK level: agents built with Microsoft Agent Framework, GitHub Copilot SDK, LangGraph, or other SDKs deploy through Foundry’s SDK path<\/a>.The managed runtime itself, though, runs only on Azure.Hosted agents<\/a> require images in Azure Container Registry, and agent identity is tightly coupled with platform-managed execution.No documented option runs the Foundry managed runtime outside Azure.Even in the standard setup<\/a>, BYO resources remain Azure services and are not portable to other clouds.<\/p>\n Those constraints limit Foundry’s portability to the framework layer and keep managed runtime hosting on Azure. The Cosmos Agent Runtime provides parallel agent coordination across workspaces and manages scheduling and isolation as agents run on laptops, Dev-VMs, and cloud environments. The platform is IDE-agnostic. Augment notes that the customer-cloud option is still in development. Cross-environment execution comes from the runtime design.<\/p>\n Memory: Per-Thread Isolation vs Shared Compounding Context<\/p>\n Foundry has no out-of-the-box shared memory across threads<\/a>. Cosmos shares memory across agents, sessions, and teammates by architecture. That design determines whether later sessions can reuse context across teammates.<\/p>\n Foundry offers four documented storage and memory modes.<\/p>\n Foundry modeWhat it meansBasic setupKeeps agent data in Microsoft-managed storage with Microsoft-managed keysStandard setupMoves data to your own Azure Storage, Cosmos DB, and AI Search with full ownership and control and customer-managed keysBYO Cosmos DBDeploys three to five containers per project. Each project requires a minimum of 1,000 RU\/s and uses the enterprise memory databaseManaged long-term memoryMicrosoft offers preview memory for cross-session continuity and licenses it as part of the Azure subscription<\/p>\n That split improves Azure-side control in the Standard setup without changing the Azure-only boundary. Cosmos agents operate on a shared virtual filesystem<\/a>, with system-wide and private memory for patterns, conventions, and corrections across sessions and teammates. Session history and the shared virtual filesystem store patterns, conventions, and corrections for subsequent agent sessions, so semantic codebase analysis can surface conventions, dependencies, and prior implementation patterns for engineers ramping up on an unfamiliar service.<\/p>\n One caveat affects both platforms. Cosmos documentation confirms agent execution portability. It does not confirm whether teams can export the Bigtable-backed memory plane or host it in customer infrastructure. That memory store is hosted in Augment’s Google Cloud and is structurally similar to Foundry’s Basic setup. Teams evaluating Cosmos as a data-control alternative should confirm memory-plane residency directly, because the Your Cloud option covers where agents execute, not where shared memory persists.<\/p>\n Cosmos supports encoding team standards into shared memory, so agents can use corrections and patterns from earlier sessions as team context in later runs. When I onboarded Cosmos to a service I hadn’t worked with before, the shared filesystem surfaced prior implementation patterns and naming conventions from teammates’ earlier sessions, rather than starting from a blank context window.<\/p>\n Observability: Azure Monitor by Default vs Platform-Native Sessions<\/p>\n Foundry uses tracing built on OpenTelemetry<\/a> and integrates it with Azure Monitor Application Insights. When I attached Application Insights to a running agent, tool calls and token consumption appeared in the same dashboards our platform team already used for other Azure services, which reduced the setup to configuring a single connection string rather than standing up a separate observability stack. Cosmos captures observability<\/a> as a property of Sessions. Telemetry follows different paths on each platform.<\/p>\n Foundry’s observability path breaks into three pieces.<\/p>\n Foundry observability pathWhat it captures or requiresCaptured telemetryUser inputs, agent outputs, tool usage, token consumption, latency, and agent decisionsSetup requirementRequires attaching an Application Insights resource and configuring APPLICATION_INSIGHTS_CONNECTION_STRINGClient-side exportCan export to any OTLP backend such as Datadog, Grafana Tempo, Jaeger, or HoneycombDefault and server-side routeRoutes exclusively through Application Insights, and Foundry keeps evaluations turned on by default with consumption billing<\/p>\n That export path applies only to client-side instrumentation and requires explicit SDK configuration. Cosmos frames observability as structurally built-in through Sessions:<\/p>\n The platform audit trail is part of the platform itself.Session-scoped traces connect LLM calls, tool invocations, decisions, and outputs.Each run produces one auditable, replayable record because Sessions captures LLM calls, tool invocations, decisions, and outputs.Teams can swap observability stacks in incident-response workflows.<\/p>\n Cosmos documentation does not specify OTLP emissions or named backend integrations at the protocol level, so it states stack independence only at the workflow level.<\/p>\n Ecosystem: Microsoft Depth vs Model and Cloud Breadth<\/p>\n Foundry documents 1,400+ Logic Apps-derived tools and Microsoft 365 publishing. Cosmos documents four execution targets and routing across Anthropic, OpenAI, Bedrock, and Vertex. Your existing stack determines which breadth matters.<\/p>\n Foundry’s tool catalog contains 1,400+ tools<\/a> from Microsoft and partners derived from Azure Logic Apps connectors, with named integrations for SAP, Salesforce, and Dynamics 365. Select Frontier organizations can use M365 MCP servers on Outlook, Teams, Word, OneDrive, SharePoint, and Dataverse. Developers can publish to Teams and Copilot<\/a> through the Foundry publishing flow. One documented caveat: teams report that after they published to Teams<\/a> agents with knowledge sources attached, those agents failed; the issue had no resolution through late December 2025.<\/p>\n Cosmos supports Anthropic, OpenAI, Bedrock, and Vertex via Prism routing, with GitHub, GitLab, and Bitbucket for version control, and AWS, Azure, GCP, and Docker for cloud services. When I connected Cosmos to a GitLab-hosted monorepo alongside a GitHub-hosted services repo, both flowed through the same Environments and Experts, with no separate integration work on my end. Cosmos documentation does not enumerate an MCP catalog size or named business integrations, so Foundry has the documented connector count and named business integrations that Cosmos documentation does not provide. That gap matters most for teams whose workflows already run through SAP, Salesforce, or Dynamics 365; those integrations exist in Foundry today and would require custom tool development on Cosmos.<\/p>\n Ownership: The Renewal Question That Defines the Choice<\/p>\n At renewal, compare who controls the user-facing agent surface, where data persists, which model contract governs requests, and how much migration work a provider change would require. Foundry concentrates those points inside Microsoft services. Cosmos separates model selection through model-agnostic routing and supports cross-cloud execution.<\/p>\n Foundry’s lock-in operates across three layers:<\/p>\n Control plane lock-in extends to the identity and telemetry layers: Foundry integrates tightly with Azure Active Directory and Azure Monitor, so moving to another cloud means replacing Azure-specific integrations<\/a>.Data lock-in follows because embeddings, fine-tuning datasets, and prompt libraries may fall outside the scope of standard portability clauses.Model and API lock-in<\/a> complete the set. Microsoft’s model lifecycle is unilateral: at Retired, inference requests return a 410 Gone response, and Microsoft has already deprecated the Foundry Agent Service (classic), with March 31, 2027<\/a>, as its retirement date.<\/p>\n Those layers turn renewal risk into migration work. Foundry does not support switching an existing agent’s model as an in-place operation.<\/p>\n Cost spans multiple billing meters in the contract-control question. Charges span Foundry pricing meters<\/a>, including model tokens, Foundry Tools, Foundry IQ, and connectors, each with its own renewal terms. Gartner calls this a GenAI blind spot: single-vendor dependency can affect future negotiating power<\/a> over pricing and terms.<\/p>\n Cosmos is built for model routing<\/a> and BYOK<\/a> across Anthropic, OpenAI, Bedrock, Vertex, and open-source models. When I ran the same implementation task through Prism with two different model contracts configured, routing selected between them by task fit rather than defaulting to whichever provider was listed first, which is the behavior that actually matters at renewal: the agent strategy does not sit on top of one lab’s roadmap or pricing. The limit remains the memory plane: Cosmos avoids model-contract lock-in, but its memory-plane residency is undocumented, so the ownership case is documented in the runtime and model layers and is unproven on the memory plane.<\/p>\n Renewal bargaining power weakens when embeddings, prompt libraries, observability, and model contracts are consolidated within a single provider’s schemas and billing terms.<\/p>\n Choose based on where your users live, where your bargaining power matters, and whether cross-cloud is a mandate or a hypothetical. The decision splits once you weigh those three factors.<\/p>\n Choose the Azure AI Foundry Agent Service if you needChoose Augment Cosmos if you needTeams or Microsoft 365 Copilot as the primary agent surface, where a Foundry publishing flow configures Entra ID, Azure Bot Service, and manifest filesA multi-cloud mandate, where interoperability claims deserve scrutiny before wholesale Azure adoptionEntra ID-gated knowledge access, where permission-aware RAG from SharePoint is native rather than custom-builtPricing negotiation power, where model-agnostic routing keeps model selection outside one provider’s roadmapProduction infrastructure using Azure-managed session isolation, capacity management, Entra ID, and Azure Monitor as default componentsShared memory across agents and teammates by designA single-cloud strategy where migration is unlikely, which Martin Fowler’s framework names as a valid Accepted Lock-inCross-cloud execution across laptops, Dev VMs, and multiple providers under one platform<\/p>\n If those conditions define your deployment surface, Foundry’s Microsoft-native integration is the advantage. Cosmos fits when portability and model-choice control matter more than Microsoft-native publishing. When I ran Auggie CLI on a repeatable multi-file remediation task, it planned the steps, executed terminal commands with my approval at each step, and carried the task context forward throughout the run instead of losing it between commands.<\/p>\n![\"Augment](\"https:\/\/www.europesays.com\/ai\/wp-content\/uploads\/2026\/07\/1783612130_139_image.jpeg\"\/)
<\/p>\n