Next2Know – Data.AI

Executive Summary

• The claim to ignore: “Pick the best agent framework.” That question is now too small. Frameworks still matter, but the real decision has moved to the runtime that hosts, permits, observes, and governs the agent.
• The real shift: Agents are moving from hand-written loops to managed substrate: hosted execution, tool permissioning, state, observability, workflows, skills, and model/tool endpoints that behave like platform services.
• The historical mirror: This is the container transition replayed for agents. The craft did not disappear; it moved up a level, from hand-managing the loop to deciding the platform boundary and blast radius.
• The leadership move: Treat the agent runtime as an architecture decision, not a library import. Ask what the agent is allowed to do, whose identity it uses, where state lives, how tools are governed, and who can prove what happened.
• Why it matters to you: The agentic era will not reward the team with the cleverest loop. It will reward the team that governs the runtime best.

The Agent Runtime Stopped Being a Library

For the first wave of enterprise agents, “build an agent” usually meant “write a loop.”

Call the model. Read the response. Decide whether to call a tool. Feed the result back. Repeat until the work is done. Every framework packaged that loop differently, but the core pattern was the same: orchestration lived inside application code, and the developer owned almost every hard part around it.

That era is ending.

The agent runtime is becoming a platform: the place where execution, tools, identity, state, telemetry, workflows, and policy come together. Microsoft Foundry Agent Service now describes an Agent Runtime that hosts and scales prompt agents and hosted agents, manages conversations, tool calls, and lifecycle, and gives agents access to tools, observability, identity, RBAC, content filters, and virtual network isolation. Microsoft Agent Framework now describes three broad capability families: agents, a harness, and workflows. Toolboxes in Foundry move tool authentication and user delegation out of agent code and into a governed platform boundary.

Read those as individual features and they sound incremental. Read them together and the pattern is obvious: the loop became substrate.

Four platform primitives changed the question

Four primitives, one runtime: capability, permission, execution, and coordination wrapped in identity, observability, and policy.

The new agent stack is not just a richer SDK. It is a stack of runtime primitives.

1. Capability becomes packageable. Agent Skills turn domain expertise into portable packages of instructions, resources, and scripts. The important shift is distribution. A skill can be authored once, versioned centrally, and discovered by agents when needed instead of being copied into every application. MCP-based skill discovery is still an evolving area, and Microsoft labels parts of that API as experimental, but the direction is clear: capability wants to be discoverable infrastructure.

2. Permission moves out of the prompt. Toolboxes in Foundry address the problem every serious agent hits: once an agent acts, whose identity is it acting with? A prompt saying “only do safe things” is documentation, not a control. A toolbox can own the auth pattern, isolate user tokens, handle consent, govern tools, and expose a versioned MCP endpoint to the agent. The agent code no longer has to carry every header, broker, scope, and retry path.

3. Execution gets a managed home. Foundry hosted agents are generally available as a managed runtime for code-based agents built with Agent Framework, LangGraph, OpenAI Agents SDK, Anthropic Agent SDK, GitHub Copilot SDK, or custom code. Foundry runs them with a managed endpoint, scaling, identity, and observability. That matters because the boundary around an agent is no longer just the app process; it is a platform boundary.

4. Orchestration becomes explicit. Agent Framework workflows give developers graph-based workflows for multi-step execution, type-safe routing, checkpointing, and human-in-the-loop support. The harness adds a batteries-included agentic pipeline: planning, history persistence, context compaction, approvals, memory, skills, web search where available, and telemetry. That is not just code convenience. It is the beginning of orchestration as an artifact a team can inspect, test, and govern.

Together, these primitives move the question from “How do we write the loop?” to “Where should the loop live, and who owns the controls around it?”

The container moment for agents

Software has been through this before.

A decade ago, shipping software meant hand-managing machines: processes, dependencies, ports, runtime configuration, deployment scripts, and failure recovery. Containers and orchestration did not eliminate engineering; they absorbed the undifferentiated plumbing into substrate. The work moved up a layer, from running processes by hand to designing platforms, policies, deployment boundaries, and blast radius.

Agents are making the same jump, compressed into months.

When the loop becomes substrate, hand-writing orchestration stops being a badge of sophistication and starts becoming a maintenance liability. The scarce skill is no longer knowing how to make a model call a tool. It is knowing where the trust boundary lives.

That boundary determines:

• what the agent is allowed to do;
• whose identity reaches the downstream system;
• how tools are discovered and approved;
• where state and memory persist;
• which events can wake the agent up;
• how cost is controlled;
• how the organization reconstructs what happened after the fact.

That is not a demo question. It is an architecture review.

A concrete before and after

Consider a mid-size lender building an agent for loan-servicing questions and small actions: checking status, updating a mailing address, starting a hardship-review intake.

Before, the team writes an agent loop, wires in two APIs, and puts the safety rule in the system prompt: “Do not modify records without explicit confirmation.” The demo works. The security review does not. The prompt is not an authorization model. There is no clean proof of which user delegated which action, what tool was called, which record changed, or why the agent thought the action was allowed.

After, the team treats the agent runtime as the control surface. A toolbox exposes only the approved servicing actions and owns the user-delegation flow. The hosted runtime gives the agent a managed endpoint, identity, telemetry, and network boundary. A workflow defines when the agent must ask for human approval. A reusable skill packages the lender’s hardship-policy guidance so three different agents use the same playbook. Observability captures the trace.

Same business goal. Very different system.

The dangerous verbs now have names, scopes, approvals, and logs. The trust boundary moved from a sentence in a prompt to a runtime-enforced control.

The honest challenges

A runtime is not magic. It is a platform choice, and platform choices have gravity.

Lock-in risk is real. Standardizing on a runtime creates dependency. That is not automatically bad; every serious platform decision creates dependency. The mitigation is to keep domain logic portable, favor open frameworks where possible, and use standard protocols such as MCP where they make sense.

Maturity is uneven. Hosted agents and toolboxes are generally available in Foundry. Some surrounding capabilities, such as resilient task support, are private preview. Agent Framework’s MCP-based skill discovery is available in .NET but explicitly experimental. Do not treat every primitive as equally mature. Check GA versus preview before putting a regulated workflow on it.

Governed is not automatic. Toolboxes, hosted runtimes, gateways, workflows, and observability enable control. They do not design your authorization model for you. A team can still attach too many tools, over-broaden permissions, skip approval gates, or let traces collect dust.

Framework skill still matters. The runtime does not replace engineering judgment. It changes where judgment is applied: less time rebuilding plumbing, more time deciding the right boundary, ownership model, failure mode, and escalation path.

What to do Monday

1. Stop reviewing agents as demos. Add a runtime section to every agent design review: execution, identity, tool boundary, state, observability, approvals, and cost.
2. Move one prompt-level rule into a runtime control. Pick one production or near-production agent and replace “please don’t” with scoped tools, approval gates, or a gateway policy.
3. Inventory dangerous verbs. List the actions each agent can take: write, delete, email, approve, deploy, spend, expose, or escalate. Those verbs belong behind runtime controls.
4. Separate model choice from runtime choice. A model is the reasoning engine. The runtime is the operating system around it. Do not let one decision silently determine the other.
5. Protect portability deliberately. Keep business logic, skills, telemetry, and tool contracts as portable as possible. Runtime gravity is manageable only when exit paths exist.

FAQ

Is this just a framework version bump?
No. A framework helps you write the loop. A runtime operates the loop: execution, identity, tools, state, workflows, telemetry, and governance as platform services. When those arrive together, the unit of work changes from code to platform configuration plus controls.

Does this mean teams should throw away existing agent code?
Usually not. This is a migration path, not a teardown. Keep the agent logic that works, then move the risky parts down into the runtime: tool auth, identity, approval, observability, state, and recovery.

Is standardizing on one runtime a lock-in trap?
It can be. Manage it the way mature teams manage container platforms: consciously. Keep business logic portable, use open frameworks where useful, and avoid burying governance assumptions inside one-off code paths.

Which Microsoft pieces map to this?
Foundry Agent Service provides managed prompt and hosted agent runtime, tools, identity, observability, and publishing surfaces. Agent Framework provides agents, a harness, and graph-based workflows. Toolboxes in Foundry govern tool access and user delegation. APIM can sit in front of MCP servers as a gateway for rate limiting, logging, and network policy.

Is this only for large enterprises?
No. Smaller teams may benefit first because they cannot afford to rebuild identity, tool auth, retries, traces, and orchestration for every agent. A managed runtime lets a small team spend its time on the business logic instead of plumbing.

The takeaway

The most important shift in agent engineering is not a smarter model or a prettier framework API. It is that the runtime became a platform.

That is a promotion, not a loss. As the platform absorbs the loop, the human work moves up: deciding what an agent may do, where its trust boundary lives, how it is observed, and who is accountable when it acts.

The agentic era will not reward whoever writes the cleverest loop. It will reward whoever governs the runtime best.

Go deeper

1. Microsoft Foundry Agent Service overview — managed platform for prompt agents and hosted agents, runtime, tools, identity, observability, and publishing. https://learn.microsoft.com/en-us/azure/foundry/agents/overview
2. Microsoft Agent Framework overview — agents, harness, workflows, state management, tools, MCP, and orchestration. https://learn.microsoft.com/en-us/agent-framework/overview/
3. Toolboxes in Foundry — governed tool access, user delegation, auth isolation, and MCP endpoints for tools. https://devblogs.microsoft.com/foundry/building-agents-that-act-on-your-behalf-with-toolboxes-in-foundry/
4. Agent Framework Harness — batteries-included agent scaffolding: planning, memory, compaction, approvals, skills, and telemetry. https://devblogs.microsoft.com/agent-framework/the-microsoft-agent-framework-harness-is-now-released/