Microsoft Foundry Agent Service Moves Enterprise AI From Prompting to Production Controls

A corporate agent does not become trustworthy when it writes a better paragraph. It becomes trustworthy when an operator can identify the exact tool call that changed a record, revoke the identity that made it, replay the trace, and compare the deployed version with the one that passed evaluation. Microsoft’s Foundry Agent Service makes that operational boundary the product story: agents are being sold less as clever prompts and more as managed software systems.

The architecture behind the announcement

Question	What the source material establishes	What operators still must test
Product or policy change	Microsoft publishes a concrete architecture or obligation	Production behavior under the customer's data and permissions
Evidence	Vendor documentation and primary research	Independent replay, audit, and incident evidence

flowchart LR
  A[User request] --> B[Policy and identity]
  B --> C[Model or runtime]
  C --> D[Retrieval and tools]
  D --> E[Observable outcome]
  E --> F[Evaluation and review]
  F --> B

The agent endpoint is becoming an operating boundary

Microsoft describes Foundry agents as managed applications that can use models, instructions, tools, and data sources together. That is a different unit of purchase from an API call. The customer is buying a place to assemble a runnable behavior, then a set of services around it.

Foundry-specific review starts with an ownership map for the agent endpoint is becoming an operating boundary: name the deployed agent, its tool contracts, its identity, and the person who can disable it. Run the ordinary and degraded cases separately. That record turns a platform feature into evidence an incident team can use.

The useful owner is not always the person who wrote the prompt. It may be the application team, the security team, or the business process owner. Foundry becomes safer when those roles are explicit and a release cannot silently widen a tool contract without a new approval.

Why tracing matters when an agent changes a system

Tracing is valuable because a final answer hides the path that produced it. A trace can connect the prompt, model response, retrieval step, tool invocation, latency, and error. Without that chain, an incident reviewer is forced to infer causality from scattered application logs.

Foundry-specific review starts with an ownership map for why tracing matters when an agent changes a system: name the deployed agent, its tool contracts, its identity, and the person who can disable it. Run the ordinary and degraded cases separately. That record turns a platform feature into evidence an incident team can use.

Microsoft Foundry agent service overview is the primary source for this part of the article. This Microsoft documentation anchors the discussion in agent lifecycle and control-plane behavior; the article extends it into an operational test.

Foundry’s managed shape is really a deployment decision

The service abstraction compresses several engineering choices into a platform surface: session management, tool wiring, deployment, monitoring, and evaluation. Compression is useful for a small team, but it also means a platform default can become an invisible architectural decision.

Foundry-specific review starts with an ownership map for foundry’s managed shape is really a deployment decision: name the deployed agent, its tool contracts, its identity, and the person who can disable it. Run the ordinary and degraded cases separately. That record turns a platform feature into evidence an incident team can use.

Identity is more important than the system prompt

An agent identity should be narrower than the human identity that requested the task. Entra workload identities provide a useful comparison: credentials belong to a workload, can be scoped, and can be rotated without pretending that a model has the same authority as an employee.

Foundry-specific review starts with an ownership map for identity is more important than the system prompt: name the deployed agent, its tool contracts, its identity, and the person who can disable it. Run the ordinary and degraded cases separately. That record turns a platform feature into evidence an incident team can use.

Microsoft Foundry tracing is the primary source for this part of the article. This Microsoft documentation anchors the discussion in agent lifecycle and control-plane behavior; the article extends it into an operational test.

Evaluation has to include tools and state

A model can pass a text benchmark while failing the actual workflow. A purchasing agent must select the correct supplier, respect budget rules, handle an unavailable item, and stop before issuing an irreversible order. Evaluation therefore needs state transitions and side effects, not only answer quality.

Foundry-specific review starts with an ownership map for evaluation has to include tools and state: name the deployed agent, its tool contracts, its identity, and the person who can disable it. Run the ordinary and degraded cases separately. That record turns a platform feature into evidence an incident team can use.

The hidden cost of a convenient agent runtime

Convenience has a bill beyond tokens. Teams inherit retention choices, regional availability, telemetry costs, connector limits, throttling behavior, and the work required to map an abstraction onto existing change-management rules. Those costs appear after the first successful demo.

Foundry-specific review starts with an ownership map for the hidden cost of a convenient agent runtime: name the deployed agent, its tool contracts, its identity, and the person who can disable it. Run the ordinary and degraded cases separately. That record turns a platform feature into evidence an incident team can use.

Microsoft Foundry observability is the primary source for this part of the article. This Microsoft documentation anchors the discussion in agent lifecycle and control-plane behavior; the article extends it into an operational test.

How a finance workflow should be tested

Consider a finance assistant that reconciles invoices. A useful test does not ask whether it can summarize an invoice. It checks whether a duplicate is detected, whether a tax exception is escalated, whether a currency conversion is recorded, and whether the agent refuses to approve its own exception.

Foundry-specific review starts with an ownership map for how a finance workflow should be tested: name the deployed agent, its tool contracts, its identity, and the person who can disable it. Run the ordinary and degraded cases separately. That record turns a platform feature into evidence an incident team can use.

Why observability must survive model swaps

Model swaps make observability harder because the same agent name may route to a different model, prompt version, tool schema, or policy layer. The trace must carry those identifiers. Otherwise a regression looks like random model behavior instead of a controlled release change.

Foundry-specific review starts with an ownership map for why observability must survive model swaps: name the deployed agent, its tool contracts, its identity, and the person who can disable it. Run the ordinary and degraded cases separately. That record turns a platform feature into evidence an incident team can use.

Microsoft Foundry evaluation is the primary source for this part of the article. This Microsoft documentation anchors the discussion in agent lifecycle and control-plane behavior; the article extends it into an operational test.

The difference between a trace and an audit record

A trace records what the system did; an audit record also records why the action was allowed, which policy evaluated it, who approved it, and what evidence was retained. Enterprises should not confuse a beautifully rendered trace waterfall with a complete compliance record.

Foundry-specific review starts with an ownership map for the difference between a trace and an audit record: name the deployed agent, its tool contracts, its identity, and the person who can disable it. Run the ordinary and degraded cases separately. That record turns a platform feature into evidence an incident team can use.

What Microsoft’s abstraction leaves to customers

Microsoft’s managed surface does not remove application responsibility. The customer still defines the tools, data boundaries, escalation rules, acceptable error rates, and rollback behavior. A platform can expose a control; it cannot decide whether a payroll write is reversible in a particular company.

Foundry-specific review starts with an ownership map for what microsoft’s abstraction leaves to customers: name the deployed agent, its tool contracts, its identity, and the person who can disable it. Run the ordinary and degraded cases separately. That record turns a platform feature into evidence an incident team can use.

Microsoft Foundry safety evaluation is the primary source for this part of the article. This Microsoft documentation anchors the discussion in agent lifecycle and control-plane behavior; the article extends it into an operational test.

A practical promotion path from prototype to production

A sensible promotion path begins with read-only retrieval, moves to draft outputs, then allows reversible actions, and only later permits durable writes. Each stage should have a separate identity, test set, approval owner, and incident playbook rather than one global switch.

Foundry-specific review starts with an ownership map for a practical promotion path from prototype to production: name the deployed agent, its tool contracts, its identity, and the person who can disable it. Run the ordinary and degraded cases separately. That record turns a platform feature into evidence an incident team can use.

Where vendor-managed control helps

Platform controls help most when they are close to execution. A policy that sees the proposed tool arguments before the call can stop a dangerous action. A policy that only scans the final prose may miss that the agent already sent an email or changed a ticket.

Foundry-specific review starts with an ownership map for where vendor-managed control helps: name the deployed agent, its tool contracts, its identity, and the person who can disable it. Run the ordinary and degraded cases separately. That record turns a platform feature into evidence an incident team can use.

Microsoft Entra workload identities is the primary source for this part of the article. This Microsoft documentation anchors the discussion in agent lifecycle and control-plane behavior; the article extends it into an operational test.

The failure modes that dashboards miss

Dashboards miss failures that are distributed across time. A correct tool call followed by a stale cache, a retry, and a second call can produce an incorrect business result even when each event looks normal alone. Workflow-level assertions are needed to detect the sequence.

Foundry-specific review starts with an ownership map for the failure modes that dashboards miss: name the deployed agent, its tool contracts, its identity, and the person who can disable it. Run the ordinary and degraded cases separately. That record turns a platform feature into evidence an incident team can use.

The buyer questions behind the service

Buyers should ask whether traces export in an open format, whether tool permissions are separable, how model changes are announced, and whether evaluation results are tied to immutable versions. The answers reveal whether Foundry is an operational foundation or only a polished prototype layer.

Foundry-specific review starts with an ownership map for the buyer questions behind the service: name the deployed agent, its tool contracts, its identity, and the person who can disable it. Run the ordinary and degraded cases separately. That record turns a platform feature into evidence an incident team can use.

OpenTelemetry GenAI conventions is the primary source for this part of the article. This Microsoft documentation anchors the discussion in agent lifecycle and control-plane behavior; the article extends it into an operational test.

What independent evidence should look like

Independent evidence would include replayable traces, versioned test cases, false-positive and false-negative rates, and a record of blocked actions. Vendor documentation can explain capabilities, but it cannot by itself establish how a particular enterprise deployment behaves under pressure.

Foundry-specific review starts with an ownership map for what independent evidence should look like: name the deployed agent, its tool contracts, its identity, and the person who can disable it. Run the ordinary and degraded cases separately. That record turns a platform feature into evidence an incident team can use.

The production agent is a software supply chain

An agent is assembled from model weights, prompts, tools, connectors, identities, policies, data, and runtime versions. Foundry makes that assembly easier to manage. It also makes the supply chain more visible: every part needs ownership, change control, and a reason to remain enabled.

Foundry-specific review starts with an ownership map for the production agent is a software supply chain: name the deployed agent, its tool contracts, its identity, and the person who can disable it. Run the ordinary and degraded cases separately. That record turns a platform feature into evidence an incident team can use.

NIST AI RMF is the primary source for this part of the article. This Microsoft documentation anchors the discussion in agent lifecycle and control-plane behavior; the article extends it into an operational test.

Sources readers can inspect

The article separates announced capabilities from independently verified outcomes. These primary sources provide the product descriptions, legal text, technical documentation, standards, and security material used in the analysis:

The next signal for Foundry will be whether traces, evaluations, and identity controls remain useful during a failed tool call and a model replacement, not merely during a successful demo.