Azure AI Solution Planning After AI-102: Mapping Legacy Skills to Microsoft AI-103

 

AI-102 preparation taught many durable Azure AI engineering ideas: choose a service that fits the task, authenticate to resources, design search and knowledge flows, integrate language and vision capabilities, handle errors, and think about responsible AI. Those ideas did not become useless when Microsoft retired AI-102 on June 30, 2026. What changed is the planning surface around them. The current AI-103 exam expects an engineer to compose models, retrieval, agents, tools, identity, deployment, evaluation, observability, networking, scaling, and safety into a solution whose behavior can be explained and operated.

The best transition strategy is therefore not to compare old and new product lists. It is to map legacy planning habits to current architecture responsibilities. Some habits transfer almost unchanged. Some remain valid but need a wider context. Others become risky if they are applied without the controls that agentic and generative systems require. This guide focuses on that mapping so candidates with AI-102 history can use what they already know while deliberately repairing the gaps that matter for AI-103.

Start the planning process one level higher than the old service-selection question

A familiar AI-102-style planning question often began with a workload and asked which Azure AI capability matched it. That is still useful, but current planning should start one level higher: what complete business behavior must the solution provide, and which responsibilities must be deterministic, probabilistic, stateful, privileged, observable, or human-approved?

Suppose a company wants an internal operations assistant. A service-selection approach may identify a language model and a search capability. A current architecture approach adds more questions. Which documents are authoritative? Who may retrieve each document? Does the assistant need a fixed workflow or flexible agent planning? Which tools can it call? Can any tool modify production state? What identity performs each call? What happens when retrieved evidence is missing? How is quality measured? Where is latency observed? How are prompt, model, index, and tool changes released?

The legacy skill of matching capability to task still matters. The upgrade is to place that choice inside a system boundary before implementation begins.

Legacy mapping 1: service selection becomes responsibility decomposition

AI-102 candidates often learned to distinguish vision, language, speech, search, and document capabilities. Keep that mental taxonomy, but use it after decomposing the workload.

Write the solution as responsibilities first: ingest, extract, retrieve, reason, generate, decide, act, validate, authorize, log, evaluate, and recover. Then decide which mechanism should own each responsibility. A specialized extraction service may be easier to validate for a bounded document field. A generative model may be better for synthesis. A deterministic function should perform exact arithmetic or policy enforcement. An agent may choose among tools when the request is open-ended, but a workflow may be better when sequence is fixed.

This mapping changes how distractors look. A powerful general model is not automatically the best answer if a specialized, testable component satisfies the requirement with less uncertainty. Conversely, a collection of specialized services can become unnecessarily complex when one multimodal model meets the quality and operational constraints. Planning is a tradeoff, not a catalog lookup.

Legacy mapping 2: search knowledge becomes grounding architecture

Search was already important in AI-102, so transition candidates can have a strong advantage. The risk is treating search as finished once an index returns relevant documents. In a generative system, retrieval quality directly affects answer quality, safety, and traceability.

Map old search skills to a grounding pipeline. Start with source authority and freshness. Decide how content is extracted and chunked, which metadata must survive, which fields support security filters, and how versions are distinguished. Choose lexical, vector, semantic, or hybrid retrieval based on the query and content rather than fashion. Decide how many results enter context and how conflicting sources are handled.

Then plan evaluation at two levels. Retrieval evaluation asks whether the right evidence was found for the right user. Generation evaluation asks whether the answer used that evidence faithfully. If the pipeline combines those into a single “quality” metric, diagnosis becomes difficult.

Finally, plan provenance. Even if users do not need visible citations in every application, operations teams may need to trace a response back to the retrieved source and version. The transition skill is recognizing that search is no longer just a discovery component; it is part of the evidence chain for generative output.

Legacy mapping 3: authentication becomes an identity graph

AI-102 candidates may already understand keys, credentials, service principals, and managed identity concepts. Current planning requires making identity explicit across more components. An application may call a model, retrieve data, invoke a tool, access storage, write telemetry, and act in a downstream business system. Each arrow can use a different identity and permission set.

Draw an identity graph rather than writing “use RBAC” in the margin. For every call, name the caller, target, authentication mechanism, required authorization, and whether user identity should be preserved. Separate workload identity from the end user’s identity. A backend service should not expose all of its own privilege merely because a user can ask the agent to perform an action.

Tool use makes this mapping especially important. An agent deciding to call a function does not grant authority to perform the function. The downstream tool or API should enforce permissions and business rules. High-impact operations may require an approval step that the model cannot waive.

A current plan is incomplete when the diagram shows data flow but no identity flow.

Legacy mapping 4: responsible-AI awareness becomes layered control design

Earlier preparation often emphasized responsible-AI principles and content-safety capabilities. Those principles remain important, but agentic systems create additional control surfaces. Safety must be planned across input, retrieval, model behavior, tool use, memory, outputs, monitoring, and human escalation.

Begin with the harm, not the feature. If the risk is unauthorized disclosure, identity and retrieval filtering are primary controls. If the risk is harmful generated content, input/output safety measures and evaluation matter. If the risk is a model triggering an expensive or irreversible business action, the critical control belongs at the tool or workflow boundary. If the risk is hostile instructions inside retrieved content, the application needs a design that treats retrieved text as untrusted data rather than system authority.

Map each identified risk to at least one preventive or limiting control and one detection or monitoring signal where appropriate. Avoid a single “content filter” box that implies every risk has been solved. Responsible AI becomes much more useful when it is expressed as concrete architecture.

Legacy mapping 5: API integration becomes controlled tool design

Calling an AI service from application code is familiar territory for many AI-102 candidates. AI-103 extends that integration problem because models and agents may choose when to invoke external functions. Planning therefore has to specify tool contracts rather than only endpoints.

Design tools narrowly. Separate read operations from write operations. Use schemas that are precise enough to validate. Decide whether retry is safe. Define idempotency for actions that may be repeated. Decide what error details the agent can see and what should remain internal. Log the requested action, the identity used, the result, and any approval decision.

Consider a procurement assistant. A broad tool called “manage purchase orders” is difficult to secure and reason about. Separate tools for finding catalog items, estimating cost, creating a draft request, and submitting an approved request create clearer authority boundaries. The model can select among capabilities, while deterministic services still enforce limits.

The legacy integration skill transfers directly, but the planning artifact becomes richer because the model is now one participant in a controlled action path.

Legacy mapping 6: conversational context becomes governed state and memory

Older chatbot designs may have treated conversation history as the main state. Current agentic applications can use several kinds of memory: recent context, durable preferences, task state, retrieved knowledge, and business records. Planning must define which state is authoritative and which is merely conversational.

Create a state inventory. For each item, record owner, scope, retention, sensitivity, refresh rule, and source of truth. A user’s preferred language may be a durable profile setting. An open case identifier may need validation from a system of record. A temporary reasoning artifact may belong only to one task. Sensitive information may not belong in persistent memory at all.

Plan what happens when memory is stale. If a user changes role, access must be evaluated from current identity information rather than yesterday’s conversation. If a ticket closes, an old session should not continue acting as if it is active. The transition lesson is purposeful memory: persist only what serves a requirement and can be governed safely.

Legacy mapping 7: orchestration scripts become a workflow-versus-agent decision

Many AI-102 solutions were orchestrated by ordinary application logic: call service A, transform the result, call service B. That deterministic pattern remains valuable. AI-103 adds explicit agent and multi-agent concepts, but planning should not discard workflows automatically.

Create a decision test. If the sequence is fixed, the branching rules are known, and approvals must occur at defined points, a workflow is usually easier to validate. If the request is open-ended and the system must choose which information or tools to use dynamically, an agent may provide value. Multi-agent architecture deserves an additional justification, such as distinct responsibilities, tool boundaries, or review roles that cannot be represented simply.

Plan failure behavior before adopting flexible orchestration. What if the agent loops? What if two tools appear equally relevant? What if one agent hands incomplete state to another? What if a downstream tool is slow? Flexibility expands the number of paths that must be observed and evaluated.

A good transition candidate is able to preserve deterministic orchestration where it is the better engineering answer and introduce agents only where the requirement earns the complexity.

Legacy mapping 8: model parameters become part of a larger quality system

AI-102-era preparation may have included confidence scores, thresholds, or API parameters. In current generative systems, candidates can over-focus on model settings when quality depends on the whole application.

Plan quality as a chain. Input quality affects extraction. Ingestion affects retrieval. Retrieval affects context. Instructions affect model behavior. Model choice affects reasoning, latency, and cost. Tool results can introduce bad data. Post-processing can validate or corrupt output. Evaluation must distinguish these stages.

Use model parameters deliberately, but do not treat temperature, token limits, or a larger model as universal fixes. If answers are wrong because retrieval is stale, the correct planning response is to repair freshness. If output violates a downstream schema, structured output and validation may be more important than creativity settings.

The transfer is conceptual: parameters still matter, but current planning treats them as one control in a system rather than the whole quality strategy.

Legacy mapping 9: monitoring becomes request-level observability

Traditional monitoring asks whether resources are available, requests fail, or latency rises. Those signals remain necessary. Generative and agentic systems add a need to understand how a specific request moved through retrieval, model calls, planning steps, tools, and safety checks.

Plan a trace model. Use correlation identifiers across stages. Capture latency by component, error state, model/deployment information, retrieval metadata, tool selection and result, and selected evaluation or safety signals. Avoid collecting sensitive content indiscriminately; telemetry design should balance diagnostic value with privacy and retention requirements.

Then connect metrics to questions operations teams need to answer. Are users waiting because model inference is slow or because tools are serial? Did answer quality regress after an index update? Are failures concentrated on one role because of authorization? Did a prompt change increase tool retries?

Legacy Azure monitoring skill provides the platform foundation. The upgrade is to observe the logical AI transaction rather than only the health of individual resources.

Legacy mapping 10: deployment becomes controlled change across AI artifacts

Application code is only one part of a modern AI release. Prompts, model deployments, tool schemas, search indexes, safety policies, evaluation datasets, and configuration can change behavior even when the code is unchanged.

Map existing DevOps habits to this wider artifact set. Decide which items are versioned, which changes require evaluation, how environments differ, and how rollback works. A new prompt should trigger regression tests. A new model may require quality, latency, and cost comparison. A tool schema change should trigger contract and safety tests. An index schema change may require data migration or rebuild planning.

Separate environment-specific configuration from secrets. Use workload identity where supported. Ensure private networking does not accidentally block deployment or monitoring paths. Plan release observability so a production regression can be tied to the change that caused it.

The transition is from “deploy the app” to “control the behavior-changing artifacts of the AI system.”

Legacy mapping 11: service limits become resilience and cost architecture

Knowing that cloud services have quotas is not new. What changes in agentic systems is the number of calls and the difficulty of predicting them. One user request can trigger retrieval, several model turns, and multiple tool calls. Poor orchestration can multiply both latency and cost.

Plan capacity by component. Identify which calls are interactive and which can be queued. Decide where retry with backoff is safe and where retry could duplicate a side effect. Consider caching only where data freshness and authorization permit it. Bound agent loops and tool retries. Decide what the application should do when a preferred model deployment is unavailable or constrained.

Plan cost with the same architecture lens. Prompt length, retrieved context, model selection, agent depth, tool usage, evaluation frequency, and telemetry retention all contribute. Do not optimize one component in a way that damages the quality or safety requirement that justified the system.

A current plan includes graceful degradation rather than assuming every dependency is unlimited.

Legacy mapping 12: computer vision becomes one stage in a multimodal workflow

Vision knowledge often transfers strongly from AI-102, but current planning should connect it to the rest of the system. An application that receives an equipment image may also need OCR, structured extraction, retrieval, generation, safety checks, and a downstream case-management action.

Decompose the visual requirement. Is the system describing a scene, reading text, locating an object, extracting document structure, or answering a question grounded in the image? Different tasks can require different capabilities and validation. Decide whether extracted facts become searchable metadata or direct model context.

Then plan uncertainty. What happens when an image is blurry, contains misleading embedded text, or lacks enough evidence? High-impact recommendations may require human review. Sensitive visual content may require additional controls before logging or retention.

The legacy skill remains useful; the upgrade is to treat vision as a component in a controlled multimodal pipeline.

Legacy mapping 13: language and speech become modality choices inside an application

Text analytics, translation, and speech capabilities also retain value. Current planning asks whether a specialized capability, a generative model, or a combination best satisfies the requirement.

For a contact-center application, decide separately how audio becomes text, how entities or intent are extracted, whether the system must translate, how summaries are produced, and whether any output feeds an agent. Requirements such as latency, supported languages, structured output, validation, and privacy can lead to different designs.

Avoid collapsing every task into one multimodal model simply because it can technically accept several inputs. Generality may improve flexibility but reduce predictability or increase cost. Specialized components can create clearer interfaces. The planner’s job is to choose based on the workload, not on novelty.

Legacy mapping 14: document intelligence becomes information-extraction and knowledge architecture

Document skills now sit naturally at the front of retrieval and agent workflows. A planning exercise should track a document from raw input through extraction, validation, structured fields, chunking, indexing, retrieval, and downstream reasoning.

Identify which values require high confidence or human confirmation. Preserve provenance so a generated answer or automated action can be traced back to source material. Handle duplicate documents, version changes, low-quality scans, and schema evolution. Decide how ingestion failures are surfaced rather than silently creating stale knowledge.

If an agent uses extracted data to take action, the plan should distinguish validated business data from unverified model interpretation. The transfer from older document processing is strong, but the operational consequences are wider.

Build a transition architecture worksheet

For each practice scenario, create one page with nine sections: requirement, data, model, retrieval, orchestration, tools, identity/network, evaluation/observability, and deployment/operations. Do not fill every section automatically. If a scenario does not need retrieval or an agent, explicitly mark it unnecessary and state why.

Add two columns to every major decision: legacy knowledge used and current extension required. For example, “Azure AI Search indexing” may be the legacy skill; “permission-aware retrieval plus groundedness evaluation” may be the current extension. “Managed identity” may already be known; “separate identity for a side-effecting agent tool plus approval enforcement” may be the extension.

This worksheet turns transition planning into visible evidence. It also makes study gaps easy to prioritize because the same blank section may recur across several scenarios.

Use failure-first planning to expose weak assumptions

After drawing the happy path, break the design on paper before implementing it. Assume the model is throttled, retrieval is stale, a tool returns an invalid response, a user loses access, a private endpoint blocks a deployment runner, or an index update introduces irrelevant chunks. For each failure, define safe behavior and the evidence needed to diagnose it.

This exercise often exposes missing architecture more quickly than another feature review. If you cannot tell whether an error came from retrieval or generation, observability is insufficient. If a tool timeout could repeat a purchase, idempotency is missing. If an access change does not propagate to retrieval, authorization is incomplete.

Planning for failure is one of the clearest ways to convert AI-102 familiarity into current production reasoning.

Prioritize transition work by dependency and blueprint weight

Not every legacy skill needs the same amount of refresh. Planning/management and generative/agentic solutions are the two largest current AI-103 areas, and several cross-cutting skills influence both. Identity, retrieval, tool boundaries, evaluation, observability, and deployment deserve priority because they recur throughout the architecture.

Use smaller modalities strategically. If vision, language, or extraction is already strong, maintain it by embedding it in mixed scenarios. If one of those areas is genuinely weak, repair it, but do not let comfortable repetition displace higher-risk gaps.

A useful study decision is: which missing skill would cause the largest number of scenarios to fail? Repair that first. This is more effective than moving through the blueprint strictly in order.

Know when a legacy skill has been successfully mapped

A skill has transferred when you can use it in a current architecture without relying on an old tutorial and without ignoring the newer control surface. You should be able to state what the component does, why it is appropriate, what identity uses it, how it fails, what telemetry exposes that failure, and how its behavior is evaluated.

For search, that means more than building an index. For agents, more than calling a tool. For responsible AI, more than naming principles. For deployment, more than publishing code. The current extension must be part of the reasoning.

Test transfer with an unfamiliar scenario after several days. If the old concept still helps you make the right current decision, keep it. If it produces an outdated assumption, rewrite the rule in your notes.

Final planning model for the transition

The strongest AI-102-to-AI-103 transition keeps the old engineering foundation but changes the unit of planning. Instead of asking which service performs a task, ask how the complete system will satisfy requirements under security, quality, operational, and lifecycle constraints. Instead of treating search as a feature, treat retrieval as evidence. Instead of treating a model as the authority, put authorization in deterministic boundaries. Instead of treating monitoring as resource health, trace the logical request. Instead of deploying code once, control all artifacts that can change AI behavior.

That wider planning model is what makes legacy knowledge useful. Search, language, vision, document, identity, and integration skills still matter. They now operate alongside agents, tools, memory, evaluation, observability, CI/CD, scaling, and safety controls.

If you can take a requirement, map each responsibility to the right layer, identify who is authorized to do what, define how success will be measured, predict credible failure modes, and plan how the system changes safely over time, you are no longer studying a retired AI-102 architecture. You are using its strongest lessons as part of the current AI-103 engineering model.

Work one transition scenario from requirements to operating model

A useful capstone for planning is an internal engineering assistant that answers questions from approved runbooks, reads current service health, and can create a draft remediation ticket. The organization requires private data paths, department-based document access, no embedded credentials, measurable groundedness, and explicit approval before any future version is allowed to change production configuration.

Start by separating three kinds of information. Runbooks are controlled knowledge and need ingestion, versioning, permission-aware retrieval, and provenance. Service-health data is live operational information and belongs behind a read-only tool or API rather than being copied into a static search index. The remediation ticket is a business side effect and needs a narrow write tool with validation. That decomposition already prevents several weak designs: a model should not invent current service state from documents, and a retrieval index should not become the authority for a transactional action.

Next decide orchestration. A single agent may be justified because the user’s request can require different combinations of retrieval and read-only diagnostics. The agent can decide whether to search runbooks, call the health tool, or ask for clarification. The write path should still be constrained. Creating a draft ticket can be exposed as a distinct tool, while production changes remain unavailable or approval-gated outside the model.

Now draw identities. The application needs permission to call the model and retrieval resources. Retrieval must preserve the user’s authorization scope or enforce equivalent filtering. The health tool should expose only the data the application requires. The ticket tool should act with a service identity whose permissions are narrower than a general administrator. If the user loses department access, the next request should reflect that change even if conversation memory still contains a prior reference.

Add evaluation before deployment. Use questions with known runbook evidence, unsupported questions, stale-version traps, and requests that should require clarification. For agent behavior, test whether the correct tool is selected, whether parameters are valid, and whether the system refuses an unavailable production-changing action. Add telemetry that records retrieval metadata, model and agent timing, tool calls, authorization failures, and outcome labels without indiscriminately logging sensitive content.

Finally, plan failure. If retrieval returns a superseded runbook, the issue may be ingestion or version filtering. If only one group receives 403 errors, inspect identity and authorization. If the agent repeatedly calls the health tool, inspect orchestration and stopping behavior. If ticket creation times out after the downstream system accepted it, idempotency matters before retry. This single scenario forces legacy search, API, and identity skills to operate inside current agent, evaluation, and observability requirements.

Keep a tradeoff register instead of a list of preferred products

Planning quality improves when alternatives are recorded explicitly. For every consequential design choice, write the requirement, the selected approach, one credible alternative, why the alternative loses under the present constraints, and what change in requirements would reverse the decision. This creates a tradeoff register rather than a product preference list.

For example, you may choose hybrid retrieval because users ask both exact identifier questions and conceptually phrased questions. Pure vector retrieval remains credible, but exact identifiers may be weaker. If the workload changes to highly structured records with stable keys, a direct data query may become preferable to either. You may choose a deterministic approval workflow around an agent because policy requires a fixed authorization step. If the action later becomes read-only and low risk, a more autonomous agent may become reasonable.

This method is especially valuable during an exam transition because old habits can otherwise become defaults. “I used this service in AI-102” is not a planning argument. A tradeoff register forces the decision back to current requirements and teaches you to recognize the constraint that makes one option better than another.

Validate the architecture before considering the planning exercise complete

A final planning review should be able to answer a compact set of questions. Can every data source be traced to an owner and freshness expectation? Does every network call have a caller identity and an authorization rule? Is each model responsibility separated from deterministic business logic? If an agent exists, are its tools narrow, its state scoped, and its side effects controlled? Can the system distinguish retrieval failure from generation failure? Is there an evaluation method for quality and safety? Are request-level traces sufficient to locate latency and errors? Are quotas, retries, and cost considered without inventing unlimited capacity? Can behavior-changing artifacts be versioned and rolled back?

Do not treat this as a compliance checklist to append after the design. Use the unanswered questions to revise the architecture. If you cannot state who authorizes a tool, the tool is not fully planned. If you cannot say how an incorrect answer will be diagnosed, observability is incomplete. If a model upgrade has no evaluation or rollback path, deployment planning is unfinished.

The value of this final validation is that it catches the gaps most likely to be hidden by legacy familiarity. A candidate may know every named component yet still have an incomplete system. Current readiness is demonstrated when the components form an architecture whose behavior, authority, quality, and failure paths can all be explained.