A single-agent assistant can look impressive in a short demonstration. You give it a request, it chooses a tool, and it returns a coherent answer. The difficult part begins when the tool has a side effect, the customer changes their mind midway through the conversation, or a document contains instructions that were never authorized by the organization. Those conditions reveal whether the agent has a real application boundary or is simply a powerful model with too much freedom.
A university agent answers enrollment questions using approved knowledge, but an appointment cannot be marked confirmed until an authorized scheduling service accepts it. That boundary defines its tool and evidence contracts. Microsoft AI-901 includes configuring and testing a single Foundry agent and using a lightweight client. A sound exercise tests ambiguous instructions, missing data, unavailable tools and attempts to read another student’s records, with the user informed of the actual result.
Choose a task that justifies an agent
A university help desk can provide a useful example. The agent must answer questions about enrollment procedures, look up today’s office hours and prepare a request for an appointment. Some questions can be answered directly from provided information; others need an approved knowledge source or tool call. This variation justifies an agent more than a static model prompt does. By contrast, extracting an address from a known form might be better handled by a direct extraction service with no agent planning at all.
Set a precise task boundary: the assistant may explain published enrollment rules and prepare appointment proposals, but must not confirm a booking without user approval and an authorized scheduling result. This boundary prevents the model’s natural-language response from being mistaken for a completed transaction. Generative AI and agents explain how tool access changes an agent’s authority; a first implementation must translate that concept into enforceable limits.
Write instructions about responsibility and uncertainty
An agent instruction should describe the role, allowed knowledge, permitted tools and expected behavior when evidence is missing. ‘Be helpful’ is insufficient because it doesn’t say whether the agent may change an appointment, search a private database or guess an office hour. Give the agent a reliable path: retrieve approved office information, distinguish a requested appointment from a confirmed reservation, and ask a specific clarifying question if the user has not supplied the required details.
Instructions do not replace backend checks. A retrieved document or tool response can tell an agent to ignore earlier rules, but that content is untrusted input rather than new authority. Permission-sensitive actions must be enforced by the actual tool implementation, not requested politely in a prompt. Here, Responsible AI means testable reliability, privacy and accountability across model behavior and application controls.
Keep knowledge and actions separate
A published enrollment policy is knowledge: it informs the answer. A scheduling endpoint is an action: it may create or change a real record. The distinction guides the agent’s tools. A retrieval result may contain ambiguous or outdated text and should retain source information; an action needs validated arguments, authorization and a clear success or failure result. Mixing the two makes an agent’s fluent explanation difficult to audit and can leave users believing something happened when it did not.
For a knowledge-backed response, ask the agent to identify the source of the claimed deadline and to say when no reliable answer was found. For the scheduling tool, require an authenticated user, an allowed time, an operation identifier and explicit confirmation. Return a structured status instead of free-form output like ‘seems okay.’ The interface should show ‘appointment requested’ until the service actually returns a confirmed record. These are modest engineering rules with large consequences for trust.
Configure and test the agent in the portal
The Foundry portal provides a managed place to configure and test an agent, subject to current product and region availability. Create a narrow agent, select an appropriate model deployment, add the intended instructions and connect only the necessary supported knowledge or tools. Do not expose every available connector. A tool catalog with dozens of vaguely described actions can make tool selection less reliable and increase the surface for accidental or unauthorized behavior.
Begin with three test conversations: an answer present in the official knowledge base, a question with no supporting source and a request that requires confirmation before a real action. Inspect which steps the agent attempted rather than reading only the final text. The right answer with the wrong tool path may still be a failed test, especially if the agent accessed a record it was not entitled to read. Good portal testing examines both the outcome and how it was reached.
Model the conversation as state, not memory magic
The agent may have access to previous turns, but that does not make every remembered statement an authoritative business fact. If a user changes an appointment from Tuesday to Thursday, the application should know which pending proposal is current and whether an earlier tool action was already accepted. Keep confirmed transactions in an application-owned state store and use the conversation only as a way to interpret the user’s intent. This reduces duplicate actions after retries.
Define when sessions expire and what context the next session may inherit. An agent that sees a previous user’s private student record because a session was incorrectly reused has failed an access-control requirement, even if its answer is accurate. For a beginner exercise, a small explicit state model—pending request, confirmed action, cancelled request—is more valuable than a complicated long-term memory architecture with unclear ownership.
Test tool errors before letting users rely on it
Disconnect the scheduling service or return a deliberately malformed result. The agent should explain that it cannot confirm the appointment; it should not manufacture a booking reference. Test an expired identity and a request to perform a prohibited action. The backend should reject the request, and the agent should communicate the rejection without revealing secrets or claiming another person’s permission can be assumed. These negative tests are often more informative than repeated happy-path demonstrations.
Also test ambiguity. ‘Move it to tomorrow morning’ may refer to a draft or a confirmed booking, and ‘morning’ may not be a permitted time interval. A good agent requests the missing detail and makes the selected object visible to the user before attempting a change. This improves usability while enforcing the same boundary as a traditional application form. The agent’s natural-language flexibility should reduce friction, not weaken transactional correctness.
Use a lightweight client without hiding the rules
After the portal behavior passes, a simple client can authenticate, identify the intended agent, send messages, maintain the appropriate conversation reference and display results. Follow the current Foundry SDK guidance for the chosen runtime rather than guessing endpoint paths. The user interface should distinguish the agent’s proposed response from a tool-confirmed outcome and show an error when the service cannot complete a step.
Lightweight Foundry chat client code establishes connection and response handling, while agent clients add progress state, tool results and approval checkpoints. Do not place a privileged key in the browser merely to make the demo easier. A minimal backend that authenticates callers and enforces tool authorization is often the correct place to own these decisions.
Evaluate the agent against both helpfulness and restraint
Create a small evaluation sheet with a question, expected source, expected tool decision, allowed action and outcome. Include a prompt-injection attempt inside a retrieved document, a missing policy, a duplicate scheduling request and a legitimate request that should succeed. Inspect traces if the supported platform exposes them. A polished answer is only one measure; the test must also check whether the agent refused inappropriate actions and accurately represented uncertain or incomplete work.
Responsible AI testing requires tests for reliability, transparency and accountability rather than a successful chat response alone. A beginner does not need a giant benchmark suite. A handful of representative, intentionally difficult cases can reveal whether the assistant behaves consistently when confronted with the situations that matter most to its users.
Trace one approved action from request to confirmation
Use a synthetic appointment request to exercise the whole path. The user asks for Thursday at 10 a.m.; the agent identifies the intended office, checks availability and prepares a proposal. The client then presents the exact time and office for confirmation. Only after a separate approval does the backend submit the booking action, and only a successful service response may produce a confirmed booking reference. If the check returns no available slot, the agent should offer alternatives rather than fabricate a time.
Now deliberately disconnect the backend after approval. Does the interface show ‘pending’ rather than ‘booked’? Can the application reconcile the operation identifier if connectivity returns? Does the agent refrain from repeating the action without confirming the first outcome? This test is not advanced for its own sake: it illustrates how an AI agent differs from a conventional chatbot. The generative component interprets intent, but deterministic application state and backend validation decide whether an action actually occurred.
Know when a single agent is enough
Once the agent can answer questions, retrieve evidence, request clarification and prepare a limited action safely, resist adding a second agent merely because orchestration features exist. Additional workers create more state boundaries, failure cases and tool permissions. In many small business applications, one bounded agent combined with deterministic backend services is easier to evaluate and operate. Complexity should follow demonstrated need, not a desire to include every platform feature.
For AI-901, the essential achievement is a reliable single-agent pattern: choose the task, define boundaries, configure a model and tools, test both successful and prohibited behavior, and connect a lightweight client that displays confirmed outcomes honestly. That sequence is the bridge from understanding what an agent is to implementing one without confusing fluent language with authorization or trustworthy evidence.