Microsoft AI-103 Developing AI Apps and Agents on Azure Deep Dive: Generative AI and agents — From Fundamentals to Exam Scenarios

 

Generative AI and agentic solutions form the largest AI-103 skill area in the current Microsoft blueprint, measured at 30–35% as of April 16, 2026. The domain covers more than prompting a language model. It includes model deployment and consumption, retrieval-augmented generation, tool-augmented workflows, multistep reasoning, evaluation, application integration, agents with retrieval and memory, function calling, multi-agent orchestration, safeguards, approval controls, monitoring, error analysis, observability, and hybrid designs that mix models with deterministic rules.

The most useful way to study this domain is to stop thinking of “generative AI” and “agents” as product labels. Treat them as different levels of application control. A generative application asks a model to produce or transform content. A tool-augmented application lets the model interact with deterministic capabilities. An agent adds dynamic planning or tool selection. A multi-agent system distributes responsibilities across specialized actors. Every step toward more autonomy creates additional power and additional failure modes.

Agent design becomes easier to reason about when you separate agent behavior from the platform around it. The AI-103 complete guide shows where this topic sits in the blueprint, while the Azure AI solution planning guide connects it to identity, retrieval, deployment, safety, and operations.

Begin with the simplest generative pattern

A basic generative application sends instructions and input to a model and receives generated content. That pattern can already solve useful tasks: summarization, rewriting, classification, extraction into a schema, translation, drafting, and natural-language explanation.

The engineering challenge is to define the task narrowly enough that quality can be measured. “Be helpful” is not a testable requirement. “Summarize the incident report in five bullets, include root cause and customer impact, and do not introduce facts that are not present” is much easier to evaluate.

Use structured output when downstream software expects a predictable shape. A model response that merely looks like JSON is not the same as a validated schema. The application should check required fields, types, allowed values, and missing data. If the model cannot produce a valid result, the system should know how to retry, ask for clarification, or fail safely.

This is a recurring AI-103 principle: natural-language flexibility is useful, but deterministic validation should protect interfaces and business rules.

Prompt engineering is behavior design, not security design

Prompts can define role, task, tone, constraints, examples, output format, and the context the model should use. They are important, but they are not a secure policy boundary.

A strong prompt tells the model what information is relevant and how to respond. A secure application independently controls what data the model can access and what actions can occur. If a model must not reveal payroll information, prevent the retrieval or tool layer from exposing payroll data to unauthorized users. If a model must not approve a high-value transaction, enforce the approval rule in the workflow or backend service.

This distinction is easy to test in scenarios. When an option proposes solving an authorization problem only by adding an instruction, ask whether the model still technically has access to the forbidden data or action. If it does, the control is weak.

Prompt design should also anticipate ambiguity. Define what the model should do when information is missing. Ask it to use supplied evidence rather than inventing facts. Specify when a tool is appropriate. Keep instructions aligned with tool capabilities so that the model is not encouraged to promise actions it cannot perform.

Model parameters change behavior but do not fix bad architecture

Generation settings influence variability, length, and sampling behavior. They can be useful for tuning a task, but they are often overused as a remedy for problems that originate elsewhere.

If a grounded assistant answers from the wrong document, inspect retrieval before adjusting generation randomness. If a tool call fails authorization, changing temperature is irrelevant. If output violates a schema, stronger structured-output enforcement and validation may matter more than prompt wording. If a model is too slow, context size, tool count, orchestration, or model selection may be more important than a single parameter.

For exam preparation, classify every failure by layer before proposing a fix. This habit protects you from attractive but unrelated options.

Retrieval-augmented generation changes the source of truth

A model’s pretrained knowledge is not enough when answers must reflect private, current, or controlled information. RAG retrieves relevant content and adds it to the model context.

The architecture has two major phases. During ingestion, source content is extracted, cleaned, chunked, enriched, embedded where appropriate, and indexed with useful metadata. During query time, the application interprets the request, retrieves relevant evidence, may rerank or filter it, builds grounded context, and asks the model to respond from that context.

Both phases can fail. Poor extraction loses useful structure. Oversized chunks reduce precision. Tiny chunks lose context. Missing metadata prevents filtering. Stale ingestion produces outdated answers. Weak retrieval returns irrelevant content. Excessive top-k can bury the useful evidence in noise.

Evaluate retrieval independently from generation. Record which evidence was retrieved. A fluent final answer can hide a weak retrieval layer until the application encounters a harder question.

Hybrid retrieval is about combining signals

Vector search captures semantic similarity. Lexical search can match exact terms, identifiers, and phrasing. Semantic ranking can improve ordering. Metadata filters constrain scope. Hybrid retrieval combines signals so that the system does not depend on one notion of relevance.

The best method depends on the content and question. A support system with product codes may need exact matches. A policy assistant may benefit from semantic similarity. A multi-department knowledge base may require strict metadata filtering before any semantic ranking occurs.

The exam-relevant reasoning is not “hybrid is always better.” It is understanding why a requirement favors a retrieval strategy and what quality signal you would monitor.

Tool use turns generation into action

A model becomes more useful when it can call deterministic tools: search, calculators, databases, APIs, code, or business systems. Tool use also increases risk because the model can now influence external state.

A well-designed tool has a narrow purpose and a clear schema. “Get order status” is better than “manage orders.” “Submit refund request” is safer and easier to govern than a generic “execute account action” tool. Separate read operations from write operations when possible.

Descriptions matter because the model uses them to decide which tool fits the request. If two tools have overlapping descriptions, selection becomes unstable. Parameters matter because a valid tool name with invalid arguments still fails. Validation belongs outside the model as well as in the prompt.

The downstream service remains responsible for authorization. The fact that an agent chose a tool does not prove that the requested action is permitted.

Function calling should be treated as an interface contract

When a model returns a structured request to invoke a function, the application should treat that request the way it would treat input from any external component. Validate fields. Check ranges and formats. Confirm the user’s authorization. Apply business rules. Handle idempotency for actions that could be retried. Log the request and result.

Suppose an agent creates shipping labels. A function schema may require order ID, address, and service level. The model can propose values, but the application should confirm that the order exists, the user can modify it, the address is valid, and the service level is allowed. If creating a label has cost or irreversible consequences, an approval or confirmation step may be appropriate.

This layered approach appears repeatedly in AI-103 scenarios because it combines agent behavior with ordinary secure software engineering.

An agent adds dynamic decision-making

An agent is useful when the application cannot know the exact sequence of steps in advance. The user might ask, “Why did my deployment fail and what should I do?” The agent may need to inspect logs, retrieve a runbook, query resource state, compare errors, and then propose a next step. Different failures require different tool sequences.

The agent needs a role, goal, instructions, tools, knowledge, memory strategy, and stopping conditions. It also needs constraints. Which actions can it take automatically? Which require approval? What data can it access? How many steps may it execute? What should happen if a tool fails?

A common mistake is to create an agent for a process that is already deterministic. If the business process is always “validate request, obtain manager approval, call API, send confirmation,” a workflow is easier to test and govern. A model may help interpret the request, but it does not need to control the whole sequence.

Agent memory is a data-design decision

Memory can improve continuity, but it introduces privacy, correctness, and lifecycle questions. Not every piece of conversation should become durable state.

Separate short-term conversation context from persistent user or business memory. Decide what is stored, for how long, and who can access it. Be careful with assumptions. A preference inferred in one conversation may be wrong later. Sensitive data may not be appropriate for persistence.

For exam scenarios, ask whether the requirement truly needs memory or whether retrieval from an authoritative system is better. Persistent memory should not become a substitute for current source-of-truth data.

Grounding and tools solve different problems

Retrieval provides evidence. Tools perform operations or obtain structured data. These mechanisms can coexist, but they should not be confused.

If the question is “What does the current refund policy say?”, retrieval from policy content is appropriate. If the question is “What is the customer’s current order status?”, a tool that queries the live order system may be better. If the user asks “Can I return this order and start the return?”, the agent may retrieve policy, query order details, reason about eligibility, and then invoke a return tool with confirmation.

This sequence illustrates why agentic scenarios often span multiple blueprint skills. The agent is only the orchestrator. Reliable behavior depends on retrieval quality, tool design, identity, business rules, and monitoring.

Autonomous and semiautonomous are not the same

The current blueprint explicitly includes autonomous or semiautonomous workflows with safeguards and approval controls. The key question is how much decision authority the system receives.

A semiautonomous agent may gather evidence, recommend an action, and wait for approval. This is appropriate when consequences are significant or policy requires human accountability. An autonomous workflow may be acceptable for low-risk, reversible, well-bounded actions with strong validation and monitoring.

Risk is not determined only by technical complexity. Sending a harmless internal notification may be low risk even if several tools are involved. Deleting customer data may be high risk even if the API call is simple.

In exam questions, look for words such as approve, high value, regulated, irreversible, sensitive, or audit. They usually signal that the control boundary matters as much as the model capability.

Multi-agent systems should have real specialization

Multiple agents can be useful when responsibilities are meaningfully different: one agent gathers data, another analyzes compliance, another plans a response. But splitting a task across agents merely because “multi-agent” sounds advanced adds latency, cost, coordination failures, and more traces to interpret.

Define why each agent exists. Give it non-overlapping responsibilities and tools. Decide how work is routed and how results are shared. Prevent circular delegation. Limit maximum steps. Establish a final authority for completion.

Use multi-agent design when specialization, isolation, or independent reasoning creates a clear benefit. Otherwise, a single agent with well-designed tools may be easier to operate.

Hybrid systems combine models with rules

One of the most robust patterns is to use models for ambiguous language tasks and deterministic code for rules.

Consider insurance claim intake. A model can summarize a narrative, extract candidate entities, and classify the type of incident. Deterministic validation checks required fields. A rules engine evaluates policy thresholds. Retrieval supplies coverage language. A human approves exceptional cases. The model is valuable, but it is not responsible for every decision.

The current blueprint explicitly includes orchestration of multiple models, flows, or hybrid LLM-and-rules engines. Study this as an architecture principle: choose the best mechanism for each responsibility.

Evaluation should be designed for the application type

A generic accuracy score is rarely enough. Define metrics that match the behavior.

For summarization, evaluate factual consistency, coverage, clarity, and format. For RAG, add retrieval relevance, groundedness, citation or evidence correctness, and refusal behavior. For a tool-using agent, add tool-selection accuracy, argument correctness, completion rate, unsafe-action rate, and approval compliance. For multi-agent workflows, add routing quality and unnecessary-step count.

Use representative test cases, including failures. Test missing data, ambiguous requests, adversarial wording, tool timeouts, permission errors, unsafe requests, and conflicting evidence. A system that performs well only on clean examples is not ready.

Keep evaluation data separate from prompts or examples used during development when possible. Otherwise you risk tuning to a small familiar set.

Error analysis is more useful than aggregate scores

If overall quality falls from 90% to 82%, the number tells you that something changed but not what to fix. Error analysis groups failures by mechanism.

For RAG: wrong document, missing document, bad chunk, stale data, filter error, poor reranking, unsupported answer. For agents: wrong tool, correct tool with wrong parameters, unauthorized action, repeated loop, premature stop, lost context, tool failure. For generation: factual error, format error, over-refusal, unsafe output, incomplete answer.

Categorization turns evaluation into engineering work. It also creates targeted exam study. If you repeatedly misclassify authorization failures as prompt problems, you have identified a reasoning weakness.

Observability should expose the whole run

Agentic systems are chains of decisions. A final response alone is not enough to diagnose them.

Trace model calls, retrieval queries, retrieved evidence, tool selection, tool arguments, tool responses, safety signals, token use, latency, retries, and approvals. Correlate these events so that one user request can be reconstructed.

Watch both quality and operations. A system can be logically correct but too slow or expensive. It can be fast and cheap but unsafe. It can generate strong answers while retrieval freshness silently degrades.

The blueprint’s emphasis on tracing, token analytics, safety signals, and latency breakdowns reflects this production reality.

Scenario: support agent with retrieval and tools

A customer asks why a subscription feature is unavailable and whether their account can be upgraded.

The agent should retrieve current product documentation or policy for the explanation. It may call an account tool to inspect the customer’s plan. If an upgrade is allowed, it can call another tool to create an upgrade request. If purchase has financial implications, the application may require confirmation.

A weak design gives the agent a generic “manage account” tool with broad permissions. A stronger design separates read-only account lookup from upgrade request creation, validates parameters, and logs the side effect.

If the explanation is wrong, inspect retrieval. If the plan information is wrong, inspect the account tool. If the tool cannot run, inspect identity and authorization. If the agent chooses the wrong tool, inspect descriptions and routing. The scenario becomes manageable once failures are mapped to layers.

Scenario: operations agent

An operations team wants an agent to help diagnose failed deployments. It can read logs, query resource health, retrieve internal runbooks, and propose remediation. It must not make production changes automatically.

This is a strong semiautonomous pattern. Give the agent read-only tools. Retrieval supplies runbooks. The model synthesizes evidence and proposes steps. A human engineer executes or separately approves any state-changing action.

Monitoring should record which logs were queried, which runbook content was retrieved, what reasoning path led to the recommendation, and whether the recommendation was accepted. Evaluation should include known incidents and cases with insufficient evidence.

The critical design insight is that the agent can be powerful without owning the final production authority.

Scenario: multi-agent research workflow

A company wants a system that receives a complex product question, gathers technical documentation, checks compliance requirements, and produces a final recommendation.

One design could use a single agent with retrieval and several tools. Another could use specialized research and compliance agents coordinated by an orchestrator.

Choose multi-agent only if separation provides value—for example, independent policy constraints, distinct tools, or different evaluation criteria. Otherwise, multiple agents may add overhead without improving reliability.

If multi-agent is selected, define routing, shared context, maximum turns, failure propagation, and final synthesis. The system also needs controls to prevent one agent from bypassing another agent’s policy boundary.

Common exam traps in generative and agentic scenarios

The first trap is using a model to enforce a deterministic policy. The second is using prompt changes to solve a retrieval or authorization problem. The third is choosing an agent when a workflow is sufficient. The fourth is assuming a tool call is authorized merely because the agent generated it. The fifth is adding multi-agent complexity without a requirement. The sixth is ignoring evaluation and observability because the prototype works.

Another trap is equating memory with authoritative data. If an account balance or policy status changes, retrieve the current value from the system of record rather than trusting conversation memory.

Finally, avoid assuming that the most capable model is always the correct answer. Cost, latency, modality, and task complexity matter.

A compact decision framework

When deciding how to implement an AI-103 generative scenario, ask:

1. Is the task primarily generation, retrieval, reasoning, or action?
2. Does the application need authoritative external evidence?
3. Is the sequence known, or must the system choose steps dynamically?
4. Are there side effects?
5. Which side effects require confirmation or approval?
6. What identity is used for every data and tool call?
7. Which behaviors require deterministic validation?
8. How will quality and safety be measured?
9. Which traces are needed to diagnose a failure?
10. Can a simpler architecture satisfy the requirements?

This framework is more durable than memorizing individual service screens.

Study priorities for this domain

Spend the most time on patterns that connect several objectives: RAG with evaluation, agents with tools and approval, and production monitoring. Build at least one example of each. Then vary the constraints.

For RAG, change the documents, filters, or freshness requirements. For agents, change tool permissions and approval thresholds. For monitoring, create a failure and locate it in traces. The goal is to learn causality.

Once you begin mixed scenarios, use the AI-103 practice-test strategy to classify each wrong answer by the layer you misunderstood. That turns question practice into evidence about which mental model needs repair.

The core idea: controlled flexibility

Generative AI is valuable because it handles language and ambiguity. Agents are valuable because they can adapt a plan and select tools. Those strengths also create uncertainty. AI-103 therefore tests whether you can add enough deterministic structure around the probabilistic components to make the system useful and governable.

Good architecture uses the model where interpretation and generation add value, retrieval where authoritative evidence is needed, tools where deterministic operations are required, identity and policy where access must be enforced, approvals where consequences justify human control, and observability everywhere the system can fail.

If you can look at an agentic scenario and identify those boundaries before choosing a product, you have understood the most important lesson in the domain. The exam is not asking whether agents are impressive. It is asking whether you can engineer them responsibly.

Design tool schemas to make the correct action easier than the wrong one

Tool schemas are often treated as a developer detail, yet they have a major effect on agent reliability. A schema is the contract between probabilistic language understanding and deterministic execution. Poorly designed schemas force the model to infer too much. Strong schemas narrow the space of valid actions.

Suppose a travel-support agent can change a booking. A weak tool accepts a free-form instruction such as action_text. The model must encode the whole business decision into prose, and the backend must reinterpret it. A stronger set of tools separates operations: retrieve booking, calculate change options, select an allowed option, and submit a change request. Each operation exposes only the fields required for that step.

Prefer enumerated values when the business domain has a fixed set. Prefer explicit dates, identifiers, and numeric fields over natural-language descriptions when the downstream system needs structured data. Make optional parameters truly optional and document when they should be omitted. Avoid ambiguous names such as type, value, or data when ticket_priority, refund_amount, or shipping_method communicates intent more clearly.

Tool descriptions should explain both capability and boundary. “Search the employee handbook” tells the model what the tool does. “Use only for published HR policy; do not use it for live payroll balances” helps prevent overlap with another tool. If multiple tools sound interchangeable, the model may choose inconsistently even when both schemas are technically correct.

For side-effecting tools, add preconditions in deterministic code. The agent may supply an account ID and refund amount, but the service should confirm that the account exists, the user has authority, the amount is within policy, and the request has not already been processed. If approval is required, represent approval as a separate state or token that the model cannot fabricate.

Idempotency matters whenever retries can create duplicates. An agent that does not receive a response from a tool may retry. If the first call actually succeeded, a second call could create a duplicate order or ticket. A stable request identifier or backend idempotency mechanism prevents a transient network problem from becoming a business incident.

For exam preparation, take familiar APIs and redesign them as agent tools. Ask how you would reduce permissions, clarify schemas, separate reads from writes, and prove that a retry is safe. This turns “function calling” from a feature into an engineering discipline.

Conversation state, context windows, and memory are separate concepts

Agent discussions often use the word memory loosely. AI-103 scenarios become easier when you separate three different things.

Conversation state is the information needed to continue the current interaction: the user’s recent request, prior clarifications, tool results, or the current workflow step. Model context is the subset of information actually sent to the model in a given call. Persistent memory is information intentionally stored beyond the immediate interaction and retrieved later.

These layers have different limits and risks. The complete conversation may be too large or too sensitive to send on every turn. The application may summarize earlier state, retrieve only relevant records, or keep deterministic workflow state outside the model context. Persistent memory may need retention rules and user controls. A model context window is not a database and should not be treated as one.

A common design error is to keep appending conversation history until context becomes expensive, noisy, or contradictory. Better systems decide what information remains authoritative. Current account status should come from the account system. Policy should come from retrieval. The conversation can preserve what the user is trying to accomplish, but it should not override newer source-of-truth data.

This distinction also helps with privacy. A temporary troubleshooting session may include logs or sensitive identifiers that should not become long-lived user memory. Planning should state what persists, why it persists, and how it is protected.

Agent loops need explicit limits and recovery behavior

An agent that can plan dynamically can also get stuck. It may repeat the same failing tool call, alternate between two agents, retrieve increasingly irrelevant information, or continue searching after enough evidence already exists. Production design needs loop controls.

Set limits appropriate to the task: maximum model turns, maximum tool calls, time budget, token budget, or maximum retries for a particular failure. A limit is not merely a cost control. It is a safety and reliability mechanism that gives the application a known exit path.

Define recovery behavior. After a tool fails once, retry may be sensible for a transient timeout. After a permission error, repeated retries are usually pointless; the system should report the authorization problem or escalate. If retrieval repeatedly returns weak evidence, the agent might ask the user for clarification rather than continue querying with slightly different terms.

Design stop conditions positively as well. An agent should know what constitutes completion. A research task might require evidence from two approved sources and a final structured recommendation. A support task may end when the issue is classified and an approved next action is presented. Clear completion criteria reduce wandering behavior.

During hands-on study, deliberately create a failing tool and watch the agent respond. Then improve the failure policy. This exercise teaches more about real agent reliability than a happy-path demo.

Security testing for agents should include hostile inputs

Agents combine natural language, external content, tools, and often retrieved documents. That creates attack paths beyond ordinary prompt wording. A retrieved document or image can contain instructions that conflict with the application’s policy. A user can attempt to manipulate tool use. A tool can return untrusted text that is later fed back to the model.

Treat external and retrieved content as data, not as trusted system instructions. Preserve the priority of application-level instructions. Restrict tool capabilities so that successful prompt injection still cannot bypass authorization. Validate outputs before side effects. Monitor unusual tool-call patterns and repeated attempts to access restricted operations.

For multimodal agents, remember that instructions can be embedded in images as visible or hidden text. The current AI-103 computer-vision objectives explicitly call out indirect prompt-injection risk in visual content, reinforcing the broader principle that untrusted content can influence model behavior.

A useful test set includes requests that try to reveal hidden instructions, bypass approvals, persuade the agent to call an unrelated tool, or reinterpret retrieved text as a command. The objective is not to create a perfect prompt. It is to verify that failures are contained by layered controls.