Gartner predicted in June 2025 that more than 40% of agentic AI projects would be canceled by the end of 2027. The reasons include escalating costs, unclear business value and inadequate risk controls.

For .NET teams building agents on Azure, the risks mentioned above often emerge during architecture and implementation: an agent receives too much access, retrieves information from the wrong source, executes an action without sufficient controls or reaches production without an operating owner.

Microsoft Agent Framework is the successor to Semantic Kernel and AutoGen. Its 1.0 release in April 2026 introduced stable APIs for building agents and multi-agent workflows.

A production agent needs engineering decisions in six areas:

Each area addresses a different operational risk. The following sections cover the decisions and Azure capabilities involved.

Microsoft's Agent Framework guidance sets a practical starting point: when a function can handle the task, write the function. Gartner analyst Anushree Verma makes a similar observation about the market, noting that many use cases currently described as agentic do not require an agent-based implementation.

Microsoft's comparison distinguishes open-ended or conversational tasks and autonomous tool use from well-defined steps with an explicit execution order, which are better suited to workflows.

Before choosing an agent, establish four things:

Microsoft's keyless connection guidance describes the authentication mechanism. DefaultAzureCredential from the Azure Identity library uses the developer's sign-in during local development and a managed identity when the application runs in Azure. This authentication flow removes the need to store an application secret in code or configuration.

The following example demonstrates keyless authentication for a direct Azure OpenAI chat-completion call. It does not create an agent, orchestrate tools or configure Foundry Agent Service.

using Azure.AI.OpenAI;
using Azure.Identity;
using OpenAI.Chat;

var endpoint = new Uri(
    Environment.GetEnvironmentVariable("AZURE_OPENAI_ENDPOINT")!);

AzureOpenAIClient client = new(
    endpoint,
    new DefaultAzureCredential());

ChatClient chat = client.GetChatClient("");

ChatCompletion reply = await chat.CompleteChatAsync(
    "Summarize the open support case.");

Role assignments determine the resources and operations available to the application. Microsoft documents the Cognitive Services OpenAI User role for chat completions and the Contributor role for Assistants scenarios. Assign the least privilege required and scope access to the specific resource or resource group.

Each hosted agent in Foundry receives a dedicated Microsoft Entra identity. Prompt agents also support an identity. Microsoft Entra Agent ID provides identity governance for agents and is generally available. Microsoft requires at least one sponsor for each agent identity. Audit trails and Conditional Access policies depend on these identity decisions. The article on securing enterprise AI agents covers these controls in more detail.

An agent's answers depend on the information retrieved for each request. The retrieval layer therefore affects answer quality and determines which data can enter the agent's context.

The case study describes two retrieval-augmented generation chatbots. Their source data included PDFs, Word documents, HTML pages, plain text, images, audio and video. The solution converted the content into vector embeddings stored in Azure AI Search. Hybrid search combined vector and keyword matching, while metadata tagging and filtering separated internal datasets from external ones.

Three implementation decisions help maintain those boundaries:

Agents that retrieve Microsoft 365 content also depend on the tenant's permission model. The article on preparing Microsoft 365 data for Copilot covers the access review and remediation work involved.

Prompt Shields in Microsoft Foundry address two types of attacks.

Coverage depends on the configured intervention points and supported integrations. Teams should verify which inputs and tool responses are actually scanned in their implementation.

Tool access needs equally careful limits. Every tool an agent can call creates an action surface. Start with three restrictions:

Foundry toolboxes group tools behind a managed endpoint with centralized authentication, governance and versioning. This gives teams a consistent way to review and manage the tools available across agents.

Foundry observability combines evaluation, monitoring and tracing. Agent tracing through OpenTelemetry captures model calls, tool invocations and agent decisions. It integrates with Application Insights and supports Microsoft Agent Framework. Production monitoring dashboards track token consumption, latency and error rates.

A production agent needs an operating model covering releases, people, incidents and model changes.

.NET teams often need additional engineering support when agents must integrate with legacy applications, existing Semantic Kernel implementations require migration, evaluation datasets are missing or no team has been assigned to operate the agent.

These gaps involve work across several systems. Integrating an agent with a legacy .NET application requires access to existing services and data, along with controls for the actions the agent can perform. Migration work requires an assessment of current framework usage and dependencies. Evaluation requires representative datasets and defined acceptance criteria. Production ownership requires monitoring, incident response and release procedures.

Gartner's press release identifies integration with legacy systems as one of the technical challenges that can disrupt agentic AI projects.

Teams addressing these requirements can hire .NET developers to support migration, integration and evaluation work. Softwarium's Azure Certified Engineers work with Azure OpenAI Service, Azure AI Search and Microsoft Entra identity.