Microsoft AI-103: Agentic Solution Design

An AI agent becomes an engineering problem the moment it can choose an action. A chatbot that only generates text has limited consequences. An agent that searches company knowledge, calls APIs, updates records, invokes functions, or delegates to another agent can create real business effects. AI-103 therefore treats agent design as a combination of reasoning, integration, identity, safety, and operations.

The AI-103 exam explicitly covers defining agent roles and goals, conversation tracking, tool schemas, retrieval, function calling, memory, orchestrated multi-agent solutions, safeguards, approval flows, monitoring, evaluation, and error analysis.

Reliable design begins by reducing ambiguity. Define what the agent is responsible for, what it is allowed to know, what it is allowed to do, and exactly when it should stop or ask for help.

Give the agent one bounded job

The fastest way to create an unreliable agent is to give it a vague mission such as “help with operations.” That instruction leaves the model to invent boundaries. A stronger design names the task, allowed inputs, expected outputs, available tools, and escalation conditions.

The conceptual model in AI agent design is useful: an agent observes context, chooses an action, inspects the result, and decides what to do next. Reliability improves when each stage has clear limits.

If one agent requires ten unrelated capabilities, consider splitting responsibilities or moving deterministic work into conventional services.

Agent instructions need enough specificity to shape behavior without becoming a brittle script. State priorities, prohibited actions, evidence requirements, escalation rules, tone where relevant, and the conditions under which the agent may use each class of tool.

Do not rely on prompt text as the only security boundary. If an action must never occur without approval, enforce that in code, tool authorization, or workflow control rather than hoping the agent obeys a sentence.

This separation between behavioral guidance and hard control is one of the most important design lessons in agentic systems.

Tool schemas are part of the reasoning environment

The model decides among tools using the contracts you expose. Ambiguous names, overlapping descriptions, weak parameter types, or inconsistent outputs create routing mistakes even when the underlying API is correct.

Model Context Protocol reinforces the importance of clear capability contracts. Whether you use MCP or another mechanism, tools should have narrow purpose, explicit inputs, predictable outputs, and understandable errors.

A useful lab is to create two intentionally similar tools, observe the confusion, and then improve the names and schemas until selection becomes reliable.

Read and write tools need different controls

A search tool that returns public documentation does not have the same risk as a tool that changes an account, issues a refund, deletes a file, or deploys code. Reliability therefore includes an action-classification model.

Read-only tools can often run automatically if data access is appropriate. Write actions may require validation, idempotency, limits, human confirmation, or a second policy check. Irreversible actions deserve the strongest guardrails.

The agent’s service identity should also have the minimum permissions required. Least privilege limits the damage of both model mistakes and compromised integrations.

Grounding should be evaluated independently from generation

Many agents depend on enterprise knowledge. If retrieval is poor, the agent may reason perfectly over the wrong evidence. Treat grounding as its own subsystem with ingestion, chunking, indexing, filters, authorization, freshness, and relevance metrics.

The pipeline described in retrieval-augmented generation is a strong basis for testing. Ask whether the correct source was retrieved before judging the final response.

If no trustworthy evidence exists, the safe behavior may be to decline or escalate rather than infer.

Conversation state helps an agent maintain continuity, but persistent memory can also accumulate stale assumptions, sensitive data, or irrelevant history. More memory is not automatically better.

Decide what state is required for the current task, what may persist between sessions, how long it is retained, and who can access it. Summarize or discard low-value context instead of endlessly appending conversation history.

For long-running workflows, store authoritative process state in a system designed for it. Do not use model memory as the only record of what has happened.

Identity should follow the action

Agent systems often have several possible principals: the end user, the application, the agent service, or a downstream integration identity. The right choice depends on whose authority the action should represent.

Entra ID and Azure RBAC help structure Azure-side access. User-delegated access can preserve the user’s permissions, while service identities are appropriate for bounded application operations. Shared administrative credentials are a poor default.

Traceability improves when every action can be connected to a clear identity and authorization decision.

Agents are good at interpretation and adaptive decision-making. They are not automatically the best place for fixed business logic. If a sequence is known and the rules are exact, conventional workflow or code can be easier to test and cheaper to operate.

Understanding options such as Azure Functions, Logic Apps, and Event Grid helps you design a hybrid system. Let the agent choose when judgment is required, then hand predictable execution to deterministic infrastructure.

This reduces the number of steps where model variability can create failure.

An agent loop needs a definition of success, a maximum effort boundary, and failure states. Without those controls, a system can repeat failing tool calls, consume tokens, or keep delegating between agents without progress.

Set limits on steps, retries, time, or cost. Detect repeated actions and unchanged state. Escalate when required information is missing. Treat “cannot complete safely” as a valid outcome.

The goal is not maximum persistence. It is controlled progress toward a bounded objective.

Evaluation should inspect the trajectory

A correct final answer can hide a bad path. The agent might have called an unnecessary privileged tool, retried excessively, exposed sensitive context, or reached the result through an unsafe action sequence.

Use the principles of AI evaluation at both response and trajectory level. Check tool selection, argument quality, retrieval relevance, step count, approvals, safety events, and whether the agent stopped for the right reason.

For multi-step agents, traces are part of the test evidence.

Responsible AI must influence agent authority

Agentic systems amplify the consequences of unreliable output because they can act on it. Responsible AI principles therefore need to translate into authorization boundaries, content controls, human review, transparent logs, and clear user expectations.

A low-risk drafting agent can have different autonomy from an agent that makes customer-impacting changes. Risk classification should determine which tools are available and which actions require approval.

Safety is strongest when it is implemented in multiple layers rather than entrusted to one prompt.

Build one agent and make it fail on purpose

For AI-103 study, build a small agent with one knowledge source and three tools: read-only, write, and destructive. Add a confirmation gate to the destructive action. Create test cases with missing data, ambiguous requests, tool errors, permission failures, and contradictory knowledge.

Instrument the run so you can see model choice, retrieval, tool calls, errors, latency, and final outcome. Then improve the design based on evidence instead of intuition.

That exercise teaches the real exam skill. Reliable agent design is not about making the agent seem intelligent. It is about making its authority, evidence, actions, and failure behavior understandable enough to trust.

Agents operate in an environment where timeouts and ambiguous failures are normal. A tool call can succeed in the downstream system even if the agent never receives the response. Retrying a write action without protection can create duplicate tickets, duplicate payments, repeated notifications, or other unwanted effects.

Design write tools with idempotency keys or equivalent safeguards when the operation supports it. Return stable operation identifiers and let the agent check status before repeating a request. A retry policy should distinguish transport failure from confirmed business failure.

This is a classic software-engineering control that becomes even more important when a model is deciding whether to retry.

Prompt injection should be treated as untrusted input, not clever text

Agents that browse documents, retrieve knowledge, or call external tools can encounter instructions inside content they did not author. A malicious document might tell the model to reveal secrets, ignore policy, or invoke a privileged tool. The safest design does not assume the model will always recognize the attack.

Separate trusted system instructions from retrieved content, minimize the tools available for the current task, validate tool arguments, and enforce authorization outside the model. High-risk actions should still require deterministic policy checks or approval.

Security improves when the model can suggest an action but cannot unilaterally grant itself permission to perform it.

Someone must own failed tool calls, low-quality retrieval, model-version changes, quota exhaustion, safety incidents, and user complaints. If those responsibilities are divided across teams, define the handoff before production.

Good observability helps, but telemetry without ownership only creates dashboards. AI-103 preparation becomes more realistic when every lab includes the question: who would receive this alert and what action could they take?

Reliable agents also need clear user-facing failure behavior. A technical error message is rarely enough. Decide when the agent should retry silently, explain that a service is unavailable, ask for missing information, or escalate to a human. Good failure communication prevents users from interpreting uncertainty or partial completion as a successful action.

• Category: All Certifications Certifications