Service selection is one of the most important AI-103 skills because Microsoft Foundry is not a single feature. It is a platform that brings together models, agent capabilities, retrieval, multimodal processing, evaluation, observability, identity and deployment options. The difficult part is rarely finding a service that can perform a task. The difficult part is choosing the smallest set of capabilities that fits the workload without creating unnecessary cost, latency or operational complexity.<\/p>\n
The current Azure AI Apps and Agents Developer Associate path reflects that shift. The older AI-102<\/a> exam represented the previous Azure AI engineering generation, while AI-103 emphasizes Microsoft Foundry, generative applications and agents much more directly. Candidates following the Microsoft AI certifications<\/a> path should therefore think in terms of architecture decisions rather than memorizing isolated product names.<\/p>\n A strong service decision begins with the workload. Is the application generating or transforming language? Does it need grounded answers from private data? Is the task visual, audio or document-heavy? Does the system need to choose tools dynamically? Does it need to maintain a conversation over time? Does it operate in a regulated environment where private networking and auditability are mandatory?<\/p>\n These questions reduce the temptation to start with a fashionable capability and work backward. A bounded summarization task may need only a model call and deterministic validation. A knowledge assistant may need retrieval and an index. A workflow that must search several systems, choose actions and adapt to intermediate results may justify an agent. A document-processing pipeline may rely more heavily on Content Understanding and structured extraction than on an autonomous agent.<\/p>\n AI-103 rewards the ability to separate requirements that sound similar. \u201cUse company data\u201d could mean adding a document to the prompt, querying a search index, connecting an agent to a knowledge source or running a dedicated extraction pipeline. The correct choice depends on data volume, freshness, structure and how the result will be consumed.<\/p>\n Foundry exposes many model options, including larger reasoning models, smaller language models and multimodal models. A larger model may improve difficult reasoning or tool selection, but it can also increase latency and cost. A smaller model may be more appropriate for classification, extraction or high-volume routing when the task is narrow and well specified.<\/p>\n Model selection should consider the modalities required, context size, latency target, cost profile, supported regions and safety needs. A system that analyzes screenshots needs visual capability. A voice interaction needs an audio path. A structured extraction task may benefit more from consistent JSON output than from maximum conversational fluency.<\/p>\n The architecture can also use different models for different steps. A strong model may plan while a smaller model handles repetitive transformations. The tradeoff is orchestration complexity. Model routing is valuable when it produces a measurable benefit, not merely because multiple models are available.<\/p>\n Retrieval-augmented generation is appropriate when the model needs information that is not safely available from its training knowledge: internal policies, current product data, customer records, technical manuals or frequently changing material. Azure AI Search can provide vector, semantic and hybrid retrieval over indexed content and is a common grounding layer for Foundry applications.<\/p>\n Retrieval is not automatically required for every long document. If the application processes one short file at a time, placing the relevant content directly into context can be simpler. Retrieval becomes more valuable as the corpus grows, freshness matters or the application must repeatedly locate a small amount of evidence from a large collection.<\/p>\n The retrieval design is itself a service-selection problem. Teams decide how content is ingested, chunked, enriched, embedded and indexed, and whether the application uses a classic single-query pattern or a more agentic retrieval flow. The right choice balances relevance, latency, operational cost and security.<\/p>\n A deterministic workflow is preferable when the stages are known. If a request must always be validated, looked up, transformed and stored in that order, ordinary application logic can control the sequence and call models only where interpretation is needed.<\/p>\n Foundry Agent Service becomes more compelling when the model must decide what to do next. An agent can maintain conversation state, select tools, use retrieval, call APIs and adapt after seeing the result of an action. That flexibility is useful for open-ended support, research and operational tasks, but it introduces more possible failure paths.<\/p>\n The service decision therefore includes governance. Agents need clear instructions, limited tool sets, identity boundaries, approval rules and monitoring. A workflow that can be implemented deterministically should not be made agentic solely because agents are available.<\/p>\n AI-103 includes visual, language, speech and information-extraction workloads. A visual question-answering task may use a multimodal model directly. A large document pipeline may need OCR, layout recognition and structured extraction. A voice assistant may combine speech-to-text, language reasoning and text-to-speech. These are different architectures even though all are \u201cAI applications.\u201d<\/p>\n The output format matters too. Human-facing descriptions allow natural language. Downstream systems often require structured fields with predictable schemas. If the extracted data feeds an approval workflow or database, reliability of structure can matter more than conversational richness.<\/p>\n Good service selection keeps specialized preprocessing where it adds value and uses a general model where interpretation is genuinely required. This reduces cost and makes failures easier to isolate.<\/p>\n Enterprise AI frequently depends on identity, network isolation and private access to data. Managed identities and Microsoft Entra ID can remove the need to embed long-lived secrets. Azure RBAC controls which resources a project or agent can access. Private networking can keep data and agent traffic away from public paths.<\/p>\n These requirements influence architecture early. If an agent must reach private Azure AI Search, Storage or Cosmos DB, the networking model has to support those connections. If an application acts on behalf of a user, the design must distinguish application identity from delegated user authorization. If tools can modify production systems, permissions should be narrower than for read-only retrieval.<\/p>\n The security decision is not an add-on after the model works. It is part of choosing which Foundry and Azure capabilities can safely support the workload.<\/p>\n A prototype can appear successful after a handful of manual tests. Production systems need quotas, scaling, rate-limit handling, cost controls, tracing, evaluation and deployment discipline. Foundry’s observability features and Application Insights integration can expose latency, token usage, tool behavior and evaluation results.<\/p>\n CI\/CD also matters. Models, prompts, agent definitions and application code change over time. A production design should make those changes reviewable and testable rather than relying on manual portal edits that cannot be reproduced.<\/p>\nStart with the job the application must perform<\/h2>\n
Choose the model by task rather than by prestige<\/h2>\n
Use retrieval when the answer depends on changing or private knowledge<\/h2>\n
Choose an agent when the sequence of actions is not fixed<\/h2>\n
Match multimodal services to the media type and output<\/h2>\n
Security requirements can determine the service before features do<\/h2>\n
Operational requirements separate prototypes from production<\/h2>\n