Implement generative AI and agentic solutions
One Foundry project is the front door; the domain climbs three layers from it
This is the largest domain on the AI-103 exam, and everything in it is built on a single Microsoft Foundry project. Whatever your code reaches, from model deployments and connections to agents and evaluations, sits behind that one project endpoint, and you construct an AIProjectClient plus the OpenAI-compatible client it hands back from that single value and a credential. From that one project the work climbs three layers: the Application layer, where your own code drives the model; the Agent layer, where reusable capability is frozen into a hosted, versioned agent; and the Operations layer, where you tune what already runs. Keeping that ladder in mind dodges the domain's most common trap, which is reaching for a heavier construct than the job needs, such as a second agent, a declarative workflow, or fine-tuning, when a lighter option on the same project already meets the requirement.
The domain unfolds in three steps: build the application, promote it to an agent, operate it
The Application layer comes first: Build Generative Applications with Microsoft Foundry wires the SDK to the project endpoint and walks the decisions your own code owns, from which call surface to use through pinning an output contract, attaching tools, grounding answers, and evaluating them. The Agent layer comes next: Build Agents with Foundry Agent Service freezes a model, its instructions, and its tools into an immutable version that the platform hosts and runs for you, with stored conversations and service-executed tools replacing your own call loop, so you reach for it when you want reusable, roll-back-able capability instead of bespoke code. The Operations layer comes last: Optimize and Operationalize Generative AI Systems keeps a working solution fast, cheap, grounded, and observable by measuring with evaluators and traces, attributing a failure to one stage, and moving a single lever. Read the three in that order, because each layer assumes the one beneath it already exists.
When two answers both work, pick the lightest construct on the project and measure before you change it
Restraint is the default the exam rewards across all three layers. Start with a single agent holding several tools and split into more only at a real security, ownership, or maintainability boundary; prefer the prompt before fine-tuning and retrieval before a redesign; let the platform execute its built-in tools rather than re-implement them in your process; and push any decision that must be identical on every run, such as an eligibility check or a numeric threshold, into code instead of the model. The second half of the instinct is discipline about change: never move a lever on a system you have not measured. Attribute the failure to one stage with evaluators and traces first, then change exactly one thing and re-run the same dataset, so the before-and-after numbers stay comparable.
The three layers of a Foundry generative solution, and which subtopic owns each
| Layer | What you decide here | What the platform does for you | Drill into |
|---|---|---|---|
| Application | Call surface, output contract, tools, grounding, and evaluation for code you drive yourself | Hosts model deployments behind one project endpoint and serves the call surfaces | Build Generative Applications with Microsoft Foundry |
| Agent | Model, instructions, and tools frozen into a version; built-in versus custom tools; when to split into more agents | Hosts the versioned agent, stores conversation history, and executes its built-in tools | Build Agents with Foundry Agent Service |
| Operations | What to measure, which stage failed, and the single lever to move: prompt, inference settings, caching, or judge calibration | Runs evaluators, records distributed traces, and serves caching and model router | Optimize and Operationalize Generative AI Systems |