<![CDATA[Proxperity]]>https://blog.proxperity.aihttps://substackcdn.com/image/fetch/$s_!4PKo!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fecc4bf4f-539c-4b8c-af4e-780243c75d8b_460x460.jpegProxperityhttps://blog.proxperity.aiSubstackTue, 29 Sep 2026 19:44:36 GMT<![CDATA[Agent Frameworks 101: What Turns an AI Model Into a Colleague]]>https://blog.proxperity.ai/p/agent-frameworks-101-what-turns-anhttps://blog.proxperity.ai/p/agent-frameworks-101-what-turns-anFri, 04 Sep 2026 04:10:14 GMT

Welcome to Friday 101, the weekly series where I break down one part of the AI agent stack in plain language.

Most people have now asked an AI a question and received a useful answer. Far fewer have asked an AI to carry out a task and had it completed. The distance between those two experiences is where most of the engineering effort in AI currently sits, and closing it has little to do with making the underlying models more capable.

Thanks for reading Proxperity! Subscribe for free to receive new posts and support my work.

The scale is already substantial. On Microsoft’s July 29, 2026 earnings call, Satya Nadella reported that GitHub Copilot has 50 million users, that GitHub has 225 million users, and that one in three pull requests on GitHub now involves an agent. A pull request is a proposed change to a piece of software, submitted for a colleague to review before it takes effect. On the largest software platform in the world, a third of those proposals now have an agent somewhere in their history.

What an agent framework is

A language model, considered on its own, receives text and returns text. It holds no memory of previous conversations, has no access to your systems, and cannot take an action. An agent framework is the software layer built around that model to supply what it lacks: memory that persists between sessions, tools that reach real systems, rules governing which actions require human approval, and a record of what took place. Constructing an agent consists largely of building that layer. A framework provides it so that individual teams do not each rebuild it.

This distinction is often lost in discussions that focus on model selection. Models are increasingly interchangeable and can be substituted through configuration. The surrounding layer is where engineering effort accumulates and where meaningful differences between systems emerge.

Frameworks also address coordination between agents. Microsoft Agent Framework documents five arrangements, ranging from agents running in sequence to a manager agent that directs specialists as work develops. The names are less important than the observation that the simpler arrangements are sufficient for most systems.

Microsoft Agent Framework

Microsoft Agent Framework is Microsoft’s open source toolkit for this work. It was released as a preview on October 1, 2025 and reached version 1.0 on April 2, 2026, which Microsoft describes as the production-ready release, with stable interfaces and a commitment to long-term support. It is distributed under the MIT license.

The version number carries practical significance beyond engineering teams. A preview invites experimentation and feedback, and its interfaces may still change. A 1.0 release with a support commitment is something an organisation can plan against. Both have their place, and the distinction is worth tracking on any platform an organisation intends to depend upon.

Version 1.0 also resolved a division within Microsoft’s own tooling. Two separate toolkits had existed, Semantic Kernel for enterprise development and AutoGen from Microsoft Research for multi-agent work, and teams had to choose between them. Agent Framework brings the two together, and Microsoft’s documentation describes it as the direct successor to both, developed by the same teams. Organisations with existing Semantic Kernel systems have time to plan: Microsoft committed to supporting it for at least a year after the new framework left preview, placing the floor around April 2027.

GitHub Copilot in practice

Where Agent Framework is the toolkit, GitHub Copilot demonstrates what these systems become at scale. It now spans three distinct levels of independence, from suggestions offered while a developer types, through supervised editing across multiple files, to a cloud agent that accepts an assigned task and works independently in a temporary isolated environment before returning a draft for review. That capability became generally available on September 25, 2025.

The consistent principle across all three levels is that the agent proposes rather than publishes. The review step that already governed human contributions becomes the control on machine contributions as well, which is the most portable idea in this article and applies well outside software development.

GitHub has also positioned itself deliberately as neutral ground. At its Universe conference on October 28, 2025, the company announced Agent HQ, stating that agents “shouldn’t be bolted on. They should work the way you already work.” By February 4, 2026, agents from Anthropic and OpenAI were running inside GitHub in public preview. A platform that accommodates competing agents is asserting that durable value lies in governance, review and workflow rather than in ownership of the agent itself.

An agent built on the framework

To test these ideas against something real, I built TWIN on Microsoft Agent Framework.

The motivation was narrow. Colleagues kept asking me variations of one question: which skills to develop, what becomes of their role as AI absorbs part of it, whether they are secure. My answers were informed guesses, and the answers available from a chatbot were generic. I wanted something that could examine one specific career, give a grounded read, and then stay with it.

So TWIN manages a career rather than advising on one. It applies a published assessment method across five dimensions, keeps a notebook where evidence accumulates between assessments, and evaluates new roles against that profile overnight, whether or not I am looking. It has no access to workplace chat, which was a deliberate limit rather than an oversight.

The part I regard as most important is the loop back to human mentors. An AI coach is useful for structure, preparation and follow-through, and unsuited to being the final word on a career. TWIN prepares for conversations with real mentors and records what came out of them, so that human judgment enters the same record and shapes what the agent does next. The agent maintains continuity. People supply the judgment.

That loop is not hypothetical for me. A good deal of my own development, and the direction my career has taken, came out of conversations with a few career coaches I have worked with over the years. They also reviewed the research document and the TWIN framework, and their feedback improved both. They do things in a coaching conversation that the agent cannot, and encoding some of those skills into TWIN is the next thing I am building.

The build lesson was not the one I expected. Of the five coordination arrangements the framework documents, TWIN uses none. It is a single agent with tools, and what resembles a team is that same agent running on a schedule against different tasks. The component I would not omit is the middleware pipeline that sits in front of every tool call, because that is where the approval checkpoint lives: anything that changes something halts, shows exactly what it intends to do, and waits. Coordination proved straightforward. Governance was the substantial work, and the framework supplied the place to put it.

The framework is not tied to one model host. It will call a model running in Microsoft Foundry, one running locally, or the runtime behind an existing GitHub Copilot subscription. That last route is the practical one for most people: anyone on a Copilot plancan put a subscription they already pay for behind an agent of their own, and use it day to day.

Where the agent itself runs was a separate decision. Mine runs on my own machine because it holds my career history, encrypted, with only the model call leaving the laptop, and the same checkpoint that gates its actions also rate limits them and writes a tamper-evident log. For anything operated on behalf of other people I would deploy it as a hosted agent in Foundry, for the isolation and identity management that come with it.

TWIN is free to install and use. A few friends and I use it, and the assessment methodology is public at https://twin.coach/methodology, which is the part I would most like to see challenged.

What to do next

For those who do not write software, the most instructive exercise is to watch an agent work on a real task and pay attention to the review step rather than the generation step. That is where the practical character of the technology becomes apparent.

For those leading teams, three questions are worth asking: where an agent’s output enters human review, what can be reconstructed afterwards about what it did and what it cost, and which capabilities under consideration are generally available rather than in preview.

For those building, the sensible course is to begin more simply than seems necessary and to rely on what the framework already provides. The coordination patterns are a menu rather than a target.

Next Friday: agent memory, and why an agent that remembers the wrong things is less useful than one that remembers nothing.

The Friday 101 series is part of Proxperity.ai, where I build and write about practical AI agents. Subscribe to get every explainer by email.

A note on this article: I wrote this in a personal capacity and it reflects my own views, not an official Microsoft communication. All details are drawn from public documentation and official materials as of the publication date. If anything becomes outdated as the platform evolves, tell me in the comments and I will keep it corrected.

Sources:

  • https://www.microsoft.com/en-us/investor/events/fy-2026/earnings-fy-2026-q4

  • https://learn.microsoft.com/en-us/agent-framework/overview/

  • https://azure.microsoft.com/en-us/blog/introducing-microsoft-agent-framework/

  • https://devblogs.microsoft.com/agent-framework/microsoft-agent-framework-version-1-0/

  • https://devblogs.microsoft.com/agent-framework/semantic-kernel-and-microsoft-agent-framework/

  • https://learn.microsoft.com/en-us/agent-framework/workflows/orchestrations/

  • https://learn.microsoft.com/en-us/agent-framework/agents/middleware

  • https://learn.microsoft.com/en-us/agent-framework/agents/providers/github-copilot

  • https://docs.github.com/en/copilot/how-tos/copilot-sdk/integrations/microsoft-agent-framework

  • https://github.blog/changelog/2025-09-25-copilot-coding-agent-is-now-generally-available/

  • https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent

  • https://github.blog/news-insights/company-news/welcome-home-agents/

  • https://github.blog/news-insights/company-news/pick-your-agent-use-claude-and-codex-on-agent-hq/

  • https://twin.coach/methodology

Thanks for reading Proxperity! Subscribe for free to receive new posts and support my work.

]]><![CDATA[Microsoft AI Foundry 101: The AI Infrastructure of This Era]]>https://blog.proxperity.ai/p/microsoft-ai-foundry-101-the-ai-infrastructurehttps://blog.proxperity.ai/p/microsoft-ai-foundry-101-the-ai-infrastructureSat, 01 Aug 2026 17:34:08 GMT

Every era of computing has had an infrastructure layer that quietly carried everything built on top of it. The PC era had the operating system. The internet era had the web server and the database. The cloud era had virtualized compute and storage. The AI era needs something new: a layer that lets organizations pick models, ground them in their own data, turn them into agents, and run all of it with enterprise security and governance.

Subscribe now

Share

Subscribe now

Microsoft’s answer is Azure AI Foundry, now called Microsoft Foundry. This article is a plain-language introduction for people who keep hearing the name and want to understand what it actually is, why it matters, and what the evidence says about where it is headed.

Thanks for reading Ravi's Substack! Subscribe for free to receive new posts and support my work.

What is it, in one paragraph

Foundry is Microsoft’s unified platform for building AI applications and agents. Microsoft describes it as “the enterprise AI platform to build, ground, and govern AI apps and agents at scale.” Instead of stitching together a model provider here, a vector database there, and a monitoring tool somewhere else, Foundry puts model access, agent building, knowledge grounding, evaluation, and governance behind a single platform with one management plane. It launched as Azure AI Foundry at Microsoft Ignite in November 2024, evolving out of Azure AI Studio, and was renamed Microsoft Foundry at Ignite 2025.

The building blocks

You can think of Foundry as six pieces that snap together.

Foundry Models. A catalog of more than 11,000 models, including frontier models from OpenAI and Anthropic, plus Meta, Mistral, xAI, Cohere, DeepSeek, Black Forest Labs, Microsoft’s own Phi and MAI families, and thousands of open-source models from Hugging Face. Since Anthropic’s Claude arrived in November 2025, both Claude and GPT frontier models have run side by side on the same platform, and Claude in Foundry reached general availability in June 2026. A built-in Model Router can even select the best model for each request automatically, balancing quality against cost.

Foundry Agent Service. A managed service for building and running AI agents, meaning applications that use a model to reason about a request, call tools, access data, and take multi-step actions. It reached general availability at Build 2025 with support for over 1,400 enterprise data connectors, and now supports multi-agent workflows, persistent memory, and open protocols such as MCP and A2A, so agents can interoperate across vendors and even across clouds. Agents can be published straight into Microsoft Teams and Microsoft 365 Copilot.

Foundry IQ. The knowledge layer. It turns enterprise data in places like SharePoint, Azure Blob Storage, and OneLake into reusable, permission-aware knowledge bases that any agent can query. Retrieval respects the access controls your organization already has, which is the difference between a demo and something a bank can deploy.

Foundry Observability. Tooling to evaluate, trace, and monitor AI systems: quality and safety evaluators, red teaming before release, and OpenTelemetry-based tracing in production. This is the part most homegrown AI stacks skip, and the part enterprises need most.

Foundry Control Plane. A single place for security, governance, and oversight of agents, anchored by Microsoft Entra Agent ID, which gives every agent its own managed identity. If agents are going to act on behalf of your company, they need the same identity discipline as employees.

Foundry Local. The same stack running on devices and at the edge, including offline and air-gapped scenarios. Microsoft reported that Foundry Local reached 560 million devices within six months of launch.

A tour of the portal: Discover, Build, Operate

Article content
Image generated with MAI Image 2.5 Pro, one of the Microsoft AI models available in the Foundry catalog.

The components above describe what Foundry is made of. The portal itself is organized around what you do with it, in three phases that mirror the lifecycle of any AI application: Discover, Build, and Operate.

Discover is where model selection stops being guesswork. You can browse the catalog by provider, from Azure OpenAI and Anthropic to Microsoft, Meta, Mistral, and DeepSeek, explore prebuilt services for speech, language, translation, and content understanding, and compare collections such as models sold directly by Azure, Foundry Labs research models, and Foundry Local for on-device use. The standout feature is the model leaderboard. It ranks models across four dimensions: a quality index covering reasoning, coding, math, and knowledge, safety measured by attack success rates where lower is better, throughput in tokens per second, and benchmark cost. Microsoft’s guidance is practical: start with the scenario leaderboard that matches your use case, open the detailed benchmarking results for a shortlist, then deploy, try the model in the playground, or evaluate it on your own data. Being able to weigh a frontier model against a cheaper alternative with published quality, safety, and cost numbers, side by side and before writing any code, is worth a lot of engineering hours.

Build is the workspace where a project comes together: agents, model deployments, fine-tuning, tools, connected services, knowledge, memory, data, evaluations, and guardrails all live in one place. The significance is less any single feature and more the adjacency. Evaluations and guardrails sit next to the agent you are building, not in a separate product you bolt on later.

Operate is the control plane view for everything running in production: active agents, agent success rates, run volume over time, token usage, estimated cost, alerts, compliance posture, and quota, filterable by subscription and project. It even embeds AI assistance for questions like analyzing performance trends or spotting anomalies in agent metrics. This is the unglamorous phase where most AI initiatives historically stall, and having day-two operations built into the same platform that shipped the agent is a large part of the infrastructure argument this article is making.

More than models: context is the real engineering problem

Here is a lesson the industry has learned the hard way: the model is rarely the reason an AI project fails. What separates a demo from a production system is context, meaning the enterprise knowledge, permissions, memory, and tools you supply to the model. Microsoft has leaned into this idea explicitly. Asha Sharma, President of CoreAI Product, put it simply at Ignite 2025: “The more context an agent has, the more grounded, productive, and reliable it’s likely to be.”

This discipline now has a name, context engineering, and Microsoft has built products around it. Foundry IQ is described on its own product page as “a context engineering platform” for Microsoft’s intelligence layer. Rather than treating retrieval-augmented generation as a one-time lookup, its agentic retrieval engine plans queries, searches multiple sources in parallel, and iterates on the results. The outcomes are measurable: at the Foundry IQ general availability announcement in June 2026, Microsoft reported that knowledge bases improved recall by up to 54 percent compared with single-shot RAG, and that retrieval enhancements lifted answer quality benchmarks by up to 20 percent.

Context also spans more than documents. Work IQ brings signals from how people work in Microsoft 365, Fabric IQ brings business data and ontologies, and Foundry IQ brings organizational knowledge, together forming what Microsoft calls its intelligence layer. Add agent memory, which reached production at Build 2026 with procedural memory that Microsoft says delivers 7 to 14 point absolute gains in task success rates, and you can see the pattern: the durable engineering work in AI is happening around the model, not inside it.

The overlooked layer: sandboxes for agent code

Agents do more than answer questions. They write code, execute it, work with files, and act on live systems. The moment an agent runs code it generated itself, or code shaped by content it read somewhere, you are executing untrusted code, and untrusted code demands hard isolation. Microsoft’s own security benchmark says it plainly: use a sandboxed execution environment to isolate function and plugin runtimes, and design agent systems with the expectation that some attacks will succeed.

The service that answers this on Azure is worth knowing even though it sits outside Foundry: Azure Container Apps dynamic sessions. Dynamic sessions provide sandboxes that are fully isolated by a Hyper-V boundary and designed specifically for running untrusted code, drawn from pools of prewarmed environments so new sessions are allocated in milliseconds. It is a general Azure capability, generally available since late 2024, with official integrations for frameworks such as LangChain, LlamaIndex, and Semantic Kernel, so you can use it in your own applications directly.

This layer is still evolving fast: at Build 2026 Microsoft introduced Azure Container Apps Sandboxes, now in preview, a new resource type that gives agents persistent, isolated workspaces with suspend and resume, state snapshots, and controlled network egress. Where dynamic sessions are ephemeral and pool-managed, Sandboxes are stateful and developer-controlled, a sign that sandboxed compute is becoming a first-class primitive for the agent era.

The tight integration with Foundry is where it gets interesting. When an agent built on Foundry Agent Service uses the code interpreter tool, that Python code runs in exactly this kind of Microsoft-managed sandbox: Hyper-V isolated, blocked from outbound network requests, with a separate session per conversation. The same philosophy now extends to the agents themselves. Hosted agents in Foundry Agent Service run in per-session, VM-isolated sandboxes, each with dedicated compute, memory, and a persistent filesystem. Microsoft’s engineering team described the alternative, multiple customers sharing an instance where an agent writes files and touches credentials, as “a security and isolation nightmare.” Sandboxing is not a nice-to-have in the agent era. It is a load-bearing part of the infrastructure.

Bring your own code: Microsoft Agent Framework

Foundry is the platform, but developers also need an open way to write agents in code. That is Microsoft Agent Framework, an open source SDK and runtime that merges two earlier Microsoft projects, AutoGen from Microsoft Research and Semantic Kernel, into a single programming model. It was announced in October 2025 and reached its production-ready 1.0 release in April 2026 under an MIT license, with stable support for .NET and Python and Go in preview.

The framework gives you the pieces production agents actually need: a graph-based workflow engine with checkpointing for multi-agent orchestration, pluggable memory, middleware, built-in OpenTelemetry observability, and native support for open protocols such as MCP and A2A. It is deliberately not locked to one model provider, with connectors for Foundry, Azure OpenAI, OpenAI, Anthropic, Amazon Bedrock, Google Gemini, and local models through Ollama.

Its relationship with Foundry completes the story: build and test your agent locally with the framework, then deploy it to Foundry’s hosted agents with a few lines of code, where it inherits the sandboxed runtime, identity, and observability described above. Local open source flexibility on one end, governed enterprise infrastructure on the other, with the same code in between.

My own career coach agent, Twin, runs on this framework. More on that in a future post.

Why “infrastructure of the era” is not just a slogan

Bold framing deserves evidence, so here are the numbers, all from Microsoft’s own earnings calls, investor materials, and official blogs.

Adoption has compounded quarter after quarter. At Build in May 2025, Microsoft cited more than 70,000 organizations using Foundry. By October 2025 that figure was 80,000. On the fiscal year 2026 fourth quarter earnings call in July 2026, Satya stated: “We now have 100,000 Foundry customers, and revenue more than doubled year-over-year.” On the same call he noted that nearly 90 percent of the Fortune 500 ground their agents in enterprise context using Foundry, Fabric, and Work IQ.

Usage is growing faster than adoption. Microsoft reported over 500 trillion tokens processed through Foundry APIs in fiscal 2025, up seven times year over year. By July 2026, the number of Foundry customers running at a one trillion token annualized rate had increased four times year over year. In January 2026, Microsoft disclosed that more than 1,500 customers were already using both Anthropic and OpenAI models on the platform, which shows the multi-model bet is being validated by real customer behavior.

The underlying platform is scaling with it. On that July 2026 call, Satya also announced that Azure’s annual revenue surpassed 100 billion dollars for the first time, up 41 percent, with AI demand as the primary driver. Foundry sits at the center of that motion.

Independent recognition backs this up. In December 2025, Microsoft announced it was named a Leader in the Gartner Magic Quadrant for AI Application Development Platforms, positioned furthest for completeness of vision.

What this means if you are just getting started

If you are a developer, the entry point is simple: create a Foundry project, pick a model from the catalog, and you get a single endpoint and SDK that works across models, so you can swap models later without rewriting your application. From there you can attach tools and knowledge, evaluate before shipping, and publish an agent to Teams or your own app.

If you are a technology leader, the more important idea is optionality. Model rankings change every few months. A platform that treats models as interchangeable components, keeps your data grounding and governance constant, and lets you route work to whichever model is best today is a hedge against betting on the wrong horse.

The AI era will be defined less by any single model and more by the infrastructure that turns models into dependable systems. The evidence above suggests Foundry has become one of the strongest candidates for that role. Understanding it now is a good investment, whichever platform you ultimately choose.

A note on this article: I wrote this in a personal capacity and it reflects my own views, not an official Microsoft communication. All details are drawn from Microsoft’s public documentation, blogs, and investor materials as of July 2026. If anything becomes outdated as the platform evolves, tell me in the comments and I will keep it corrected.

Sources

Thanks for reading Ravi's Substack! Subscribe for free to receive new posts and support my work.

]]>