Building an enterprise AI agent is less about finding a clever prompt and more about assembling a governed runtime around a model. The system needs identity, tools, grounding data, deployment boundaries, evaluation, observability, versioning, and ownership. Microsoft Foundry provides managed agent capabilities across those layers, but architecture still determines whether the result is maintainable and safe.<\/p>\n
The current AB-100<\/a> scope makes that enterprise perspective explicit. Candidates are expected to design agentic-first and multi-agent solutions, select Foundry capabilities, manage lifecycle and testing, monitor performance, and address security, governance, data residency, access control, and prompt manipulation. Those are not separate checklist items; they are the properties that distinguish a production agent from an isolated prototype.<\/p>\n A useful design approach is to treat the agent as a product boundary. The model is one dependency inside that boundary. The rest of the system decides what context the model sees, what actions it can request, which identity is used, what evidence is logged, and how a new version reaches users.<\/p>\n Start with the task the agent owns and the decisions it is allowed to make. \u201cEnterprise assistant\u201d is too broad to produce clear permissions or reliable evaluation. \u201cInvestigate a support incident and prepare a remediation proposal\u201d is much easier to design because inputs, tools, output expectations, and escalation points can be defined.<\/p>\n A bounded capability also makes data minimization possible. A sales-operations agent may need account, opportunity, and product data but not payroll records. A service agent may need case history but not every file in a collaboration site. Scope the knowledge and tool surface around the job instead of connecting the agent to everything because the platform can.<\/p>\n Ownership should be named at design time. A production agent needs a team responsible for configuration, access reviews, quality thresholds, incident response, model or tool changes, and retirement. Without ownership, the agent can become a persistent privileged application whose original business purpose is no longer clear.<\/p>\n Write a short service charter for each production agent. It should name the supported scenarios, unsupported scenarios, business owner, technical owner, data classifications, permitted actions, dependencies, and escalation path. This becomes a practical reference when a new tool, source, or channel is proposed and helps prevent gradual scope expansion from turning one agent into an ungovernable general-purpose system.<\/p>\n Foundry supports different ways to build agents, from prompt-based managed agents to hosted code-based agents. The right choice depends on how much control the scenario needs. A prompt agent is attractive when the behavior can be expressed through instructions and managed tools. A hosted agent fits custom orchestration, proprietary libraries, specialized protocols, or logic that cannot be represented cleanly in a declarative configuration.<\/p>\n Do not equate more code with more enterprise readiness. A custom framework gives flexibility, but it also creates responsibility for dependency management, testing, deployment, and runtime behavior. Conversely, a managed prompt agent can be easier to operate but may not expose the exact control needed for a complex process. The architecture decision should be driven by requirements rather than by a preference for low-code or pro-code development.<\/p>\n Model choice is similarly contextual. Different models can offer different combinations of reasoning quality, latency, cost, modality, context capacity, and regional availability. Keep the rest of the system sufficiently decoupled that changing the model does not require rebuilding every integration.<\/p>\n Define model-selection policy rather than letting every developer choose independently. A lower-cost model may handle classification and extraction while a stronger model is reserved for complex synthesis. Routing should be tested for both quality and economics, and regulated workloads should also consider region, data-processing terms, and whether the selected deployment satisfies organizational policy.<\/p>\n Tools are how an agent moves from language to action. Foundry can work with built-in tools and custom capabilities exposed through functions, OpenAPI descriptions, MCP servers, and other integrations. The design question is not simply whether a tool can be connected. It is whether the tool exposes a sufficiently narrow, auditable operation for the agent\u2019s purpose.<\/p>\n Prefer a small tool contract such as \u201ccreate a draft service ticket\u201d over a general endpoint that can execute arbitrary administrative operations. Validate every parameter on the server side. The model can suggest a value, but the receiving service should still enforce data type, range, authorization, resource ownership, and business policy. This follows the same principle as application security controls<\/a>: untrusted input should not become privileged execution merely because it originated inside the application.<\/p>\n Tool collections also need lifecycle management. A changed API schema or tool description can alter agent behavior even when the prompt is unchanged. Version tool definitions, test compatibility, and promote changes through controlled environments. Tool observability should reveal not only whether a call failed but also what operation was requested and which authorization context was used.<\/p>\n Before connecting any knowledge source, decide whether the agent needs retrieval, a transactional tool, or both. Policies and manuals are often suitable for search-based grounding. Current account balances, entitlements, inventory levels, and workflow status are usually better retrieved from the system of record through a controlled API. Mixing those patterns indiscriminately can create stale answers that appear authoritative.<\/p>\n Metadata is part of the grounding design. Effective dates, business unit, geography, product, confidentiality, and document status can all improve retrieval and prevent the model from mixing incompatible sources. A technically excellent search index can still produce bad agent behavior if the content does not carry the attributes needed to determine which facts apply.<\/p>\n A useful enterprise pattern is to manage tools as a catalog of capabilities rather than as arbitrary endpoints exposed directly to prompts. Each capability should have an owner, purpose, input schema, output schema, authentication method, data classification, allowed operations, and failure behavior. That metadata makes tool selection easier to review and makes it possible to disable one risky capability without redesigning the whole agent. It also separates the model\u2019s decision to request an action from the platform\u2019s responsibility to authorize and execute it.<\/p>\n Contract design matters because models are probabilistic while business APIs are not. Prefer narrow functions with constrained parameters over generic \u201cexecute\u201d interfaces, validate every argument after model generation, and normalize tool responses before returning them to the agent. If a tool can create, update, and delete the same resource, consider exposing separate capabilities so permissions and approval rules can be attached to the exact action rather than to one broad connector.<\/p>\n Enterprise agents often need proprietary knowledge that the base model does not contain or cannot treat as current. Retrieval can provide policy documents, product facts, case history, manuals, contracts, or structured records at runtime. The grounding architecture should identify authoritative sources and preserve enough provenance that the user can understand where an answer came from.<\/p>\n Grounding quality depends on more than search relevance. Source accuracy, freshness, permissions, chunking, metadata, duplicate control, and indexing strategy can all affect the context delivered to the model. If outdated policy and current policy are both retrieved without clear dates, the language model may synthesize a confident but operationally wrong answer.<\/p>\n Authorization must travel with retrieval. Connecting an agent to a rich enterprise index does not mean every user should see every indexed record. The system should enforce the user\u2019s effective access or deliberately use a service scope appropriate to the business process. Sensitive grounding content should also follow retention and privacy expectations such as those discussed in secure handling of PII in AI systems<\/a>.<\/p>\n A production agent participates in an identity chain. A human or application starts the interaction, the agent runtime acts under a workload identity or delegated context, and downstream tools authenticate separately. Those boundaries should remain visible so policy can distinguish what the user requested from what the agent itself is authorized to perform.<\/p>\n Where possible, use managed identities, role-based access control, scoped connections, and network isolation instead of static secrets embedded in configuration. Separate development and production identities. A developer should not need production credentials merely to test a prompt, and a test agent should not inherit production access because its tool configuration was copied wholesale.<\/p>\n The concepts behind Microsoft identity and access administration<\/a> become practical agent controls: authenticate workloads, assign least privilege, review access, protect privileged operations, and remove permissions when the agent is retired. Identity is what allows the platform to enforce policy even when model behavior is probabilistic.<\/p>\n Agent security needs to assume that some input will be malicious or misleading. Users, websites, documents, retrieved records, and tool outputs can contain instructions that attempt to redirect the model. The system should maintain a distinction between trusted system policy and untrusted content instead of expecting the model to infer which text deserves authority.<\/p>\n Defense is layered. Limit tools and data. Validate arguments. Filter content where appropriate. Prevent secrets from entering the prompt context. Use allowlists for sensitive targets. Require approval for high-impact actions. Monitor suspicious tool sequences. The existing discussion of AI security risks<\/a> is relevant because agents add an execution channel to familiar model-manipulation problems.<\/p>\n Network controls matter as well. A compromised agent should not have unrestricted reach simply because it runs inside an approved project. Private connectivity and explicit outbound destinations can reduce the blast radius of a malicious tool request or configuration error.<\/p>\n Enterprise readiness also requires capacity and failure planning. Decide what happens when the preferred model is throttled, a tool is unavailable, retrieval is slow, or a dependent service returns partial data. Some agents can degrade to a read-only or informational mode. Others should stop because operating with incomplete evidence would be unsafe. These fallback choices belong in architecture, not in an emergency prompt edit.<\/p>\n Separate service-level objectives for the user experience from the internal components that contribute to them. A five-second target for a support response may allocate time differently across retrieval, model inference, and tools than a background research task. Tracing those budgets makes it possible to optimize the slowest stage without sacrificing quality elsewhere.<\/p>\n Agent evaluation should measure the behavior that matters for the business task. A support agent may need correct classification, complete evidence, appropriate tool selection, accurate summarization, and policy compliance. A procurement agent may need accurate requirement extraction, supplier comparison, and mandatory approval routing. A single generic \u201chelpfulness\u201d score is not enough.<\/p>\n Create representative test datasets before deployment and keep them after release. Include normal cases, edge cases, ambiguous instructions, stale or conflicting grounding data, missing tools, and adversarial inputs. Set thresholds that can block a release when task quality or safety degrades. The operational approach associated with AI-300<\/a> is useful here because evaluation becomes a repeatable quality gate rather than an occasional manual review.<\/p>\n Agent-specific evaluation should also inspect trajectory. The final answer can be correct even when the agent took a risky path to get there. Evaluate whether it chose appropriate tools, passed correct arguments, avoided unnecessary calls, respected stop conditions, and escalated when required.<\/p>\n Foundry observability can capture traces and integrate operational telemetry so teams can examine model calls, tools, latency, failures, and evaluations. Use that capability to reconstruct a run end to end. When a user reports a bad outcome, operators should be able to identify which prompt version, model, grounding source, tool result, and decision path produced it.<\/p>\n Track system metrics such as latency, token usage, run success, tool errors, and retry frequency, but connect them to business outcomes. An agent that responds quickly but sends half of its cases to human escalation may not be delivering value. Likewise, a model upgrade that improves a benchmark slightly but doubles cost may not justify promotion.<\/p>\n Telemetry needs its own security and retention rules. Traces can contain prompts, retrieved passages, tool arguments, user identifiers, and business data. Treat observability data as an enterprise data set, not harmless debugging text.<\/p>\n Environment strategy matters because an agent can be safe in development and unsafe in production simply due to different connections. Test environments should use representative schemas and policies without requiring unrestricted production data. Promotion should verify that the production identity, network rules, search sources, tool endpoints, and model deployments match the assumptions validated earlier.<\/p>\n Retirement is part of lifecycle management too. Disable published endpoints, revoke identities and tool connections, remove scheduled evaluations, archive required audit evidence, and document the replacement path. An obsolete agent with live credentials is still an application attack surface even if users no longer know where to find it.<\/p>\n Prompts, models, toolboxes, retrieval configuration, code, policy, and environment variables can all change behavior. Version them together sufficiently to reproduce a production run. Use development and test environments, automated checks where possible, explicit release approval, staged exposure, and a rollback path.<\/p>\n Source control and infrastructure automation can help make changes reviewable. The practices behind Git-based change history<\/a> are especially useful when prompt and configuration updates need peer review rather than silent editing in production. Store secrets and environment-specific values outside the versioned artifact.<\/p>\nDefine the agent around a bounded business capability<\/h3>\n
Choose the agent implementation model deliberately<\/h3>\n
Treat tools as a governed capability layer<\/h3>\n
Ground the agent in authoritative enterprise data<\/h3>\n
Use identity as a control plane, not an afterthought<\/h3>\n
Build security around the full prompt-to-tool path<\/h3>\n
Make evaluation part of the development lifecycle<\/h3>\n
Instrument traces, metrics, and business outcomes<\/h3>\n
Version, promote, and retire agents like enterprise software<\/h3>\n