An internal assistant that summarizes a support ticket is relatively easy to demonstrate. An agent that reads the ticket, checks the customer record, proposes a refund and updates the case is a different engineering problem. It has crossed from generating language into performing actions against business systems. Microsoft Foundry provides ways to host agents, connect tools and use models, but the architecture still needs clear decisions about identity, state, authorization, data access and failure. A production design begins with those boundaries instead of starting with the most impressive model response.<\/p>\n
The word agent<\/em> can describe several arrangements. A prompt agent follows configuration-based instructions and uses available tools. A code-based hosted agent can implement custom orchestration and business rules. An application may also own its own orchestration and call Foundry model services directly. None is inherently the most advanced choice. The right option depends on whether the workflow must be auditable, whether tool calls require custom approval, whether long-running steps survive failures, and which runtime operations the team wants to manage.<\/p>\n At the center of a Foundry solution is a model invocation, not a complete business process. A model can interpret an instruction, generate a response or select a proposed tool call. The surrounding agent runtime decides how that request reaches the model, which tools may be offered, how tool outputs enter context and what happens between turns. The client application owns its own concerns: user authentication, business entitlements, request limits, user experience and records of high-impact actions. Confusing these layers leads to systems where a persuasive sentence from the model receives the same authority as an authenticated application command.<\/p>\n Foundry projects group model deployments, agent definitions and connections used by applications. In a managed prompt-agent approach, the platform operates more of the agent behavior from its configuration; in a hosted-agent approach, the organization brings executable code while Foundry manages important runtime responsibilities. Teams should determine whether their logic needs customized state transitions, domain-specific validation or orchestration that would be difficult to express as a single configurable prompt. Keeping that distinction explicit also improves portability if product interfaces or SDK versions change.<\/p>\n A useful design document includes at least three views: the data-flow diagram, the permission map and the failure-state diagram. A diagram showing client \u2192 agent \u2192 CRM service is not enough. Who grants the agent access? Does the call use the end user’s delegated identity or a shared application identity? Which record identifiers can be supplied by the model, and which are independently validated? What remains in memory after the conversation? The architecture is only as strong as its answers to questions that are invisible in a basic chat transcript.<\/p>\n Managed prompt agents suit workflows that can be described with instructions, supported tools and comparatively straightforward interactions. They reduce the custom infrastructure an organization must build. Hosted agents are a stronger fit when the system needs explicit code-level workflow logic, reusable application components, control over execution pathways or framework-specific behavior. Hosted infrastructure can handle scaling and session lifecycle, yet hosting does not make a poorly designed business process trustworthy. The organization still owns instructions, integration contracts, tests and incident response.<\/p>\n Hosting and protocol choice should be separate architecture decisions. A team might expose a hosted agent through an appropriate invocation protocol while maintaining its own user-facing application, or it may interact with a managed agent through Foundry APIs. The protocol establishes how requests and responses cross the boundary; it does not determine whether a user is authorized to perform the underlying business action. Using the same authentication token to access the agent and all downstream tools can accidentally expand privilege well beyond the original request.<\/p>\n For aspiring architects, the Microsoft AB-100<\/a> pathway provides adjacent context about agentic-first solution design. The essential skill is not naming every product component; it is identifying which part of the architecture should remain deterministic. Calculating a refund limit, verifying a consent flag or posting a financial transaction should use ordinary application logic and explicit permission checks. A generative model can help interpret a request or suggest a plan, but it should not invent its own authority to bypass those checks.<\/p>\n When an agent connects to a database, document index or API, tool definitions become part of its effective capability. A tool labeled \u201clook up account\u201d may seem harmless until its parameters let the model enumerate every customer. A function labeled \u201cupdate case\u201d may quietly permit changes to priority, owner, refund value and private notes. Tool descriptions should be accurate, parameters narrowly typed and server-side validation mandatory. Never let an argument produced by a model become an unchecked query, file path or resource identifier.<\/p>\n Model Context Protocol (MCP) can standardize integration with remote tools, but a compatible server is not automatically a trusted server. Connections need approved endpoints, scoped credentials, audit trails and clear data-sharing rules. Sensitive services should be separated into read-only discovery tools and explicit state-changing actions. A business workflow may permit an agent to draft a refund recommendation automatically while requiring human confirmation to issue the payment. The permission system must enforce that separation independently of the model’s promise to behave.<\/p>\nSeparate the model, agent logic and application boundary<\/h3>\n
Choose prompt agents or hosted agents for a reason<\/h3>\n
Tool connections are capability grants<\/h3>\n