Agentic solutions allow an AI system to break down a complex goal into smaller steps and use external tools to complete those steps. This matters for the AI-102 exam because you need to show how an AI application autonomously calls different services, combines their results, and returns a unified answer to the user.
Jump to a section
A simple way to picture Agentic Solutions: Orchestration and Tool Integration
You are managing a wedding reception for 250 guests. You, the catering manager, cannot personally cook every meal, pour every drink, or adjust the lighting yourself. Instead, you have a plan: the drinks are served at 7pm, dinner at 8pm, and the speeches at 9pm. To execute this, you give instructions to three specialists: the head chef (who knows the kitchen, ovens, and dietary needs), the sommelier (who knows the wine cellar and glassware), and the lighting technician (who knows the dimmers and spotlights). Each specialist has a tool: the chef has a stove, the sommelier has a corkscrew, and the technician has a control panel. You do not micro-manage how the chef sears the steak or how the sommelier opens the bottle — you just say 'serve dinner now'.
This is exactly an orchestrator in an AI-agent system. Your overall plan is the orchestration logic. The specialists are the AI agents, each with a specific role (search data, summarise text, generate images), and their tools are the APIs or functions they call (like search_database or summarise_file). You, the orchestrator, receive the high-level request, decide which specialist to call in which order, and hand them the relevant information — without ever doing their job yourself. If the sommelier needs a specific wine from a far storage, you might ask the head chef to pause the kitchen while the sommelier retrieves it. That coordination, that sequencing, and that delegation of sub-tasks is the core of agent orchestration and tool integration. It makes the entire reception seamless, just as orchestration makes an AI solution respond coherently to complex user requests.
Agentic solutions are a advanced pattern in AI application design where the system acts like an autonomous assistant. Instead of just answering a single question with a single model call, an agentic solution can plan a series of actions, call external tools (like databases, APIs, or file systems), and then combine the results to produce a final response. The two core concepts you need to understand are orchestration and tool integration.
Orchestration is the process of managing and coordinating multiple steps, agents, and tool calls to achieve a goal. Think of it as the conductor of an orchestra: the conductor does not play an instrument, but decides when the violins enter, when the drums play, and when to end the piece. In technical terms, orchestration is a central loop or workflow that receives a user prompt, decides what to do next (based on some logic, usually a large language model), executes that action (like calling an API), and then evaluates the result to decide the next step. This loop continues until the goal is met or a stopping condition is reached.
Tool integration is how the agent connects to external capabilities. A tool is any function, API, or service that the agent can call. Examples include:
A search engine API to find current news
A calculator function to perform arithmetic
A database query to retrieve customer records
An image generation model to create a picture
Each tool has a name, a description, and a set of input parameters. The agent (often powered by a large language model) reads the tool descriptions, chooses the right one for the current step, and formats the call correctly. The response from the tool is then fed back into the agent's context so it can continue.
Why does this exist? Traditional AI systems are stateless — they answer one query and forget it. But real-world tasks, like booking a holiday, require multiple steps: search flights, search hotels, check budget, book hotel, book flight, send confirmation email. An agentic solution can orchestrate this entire sequence, calling different tools (flight API, hotel API, payment gateway, email service) without human intervention at each step.
What does this replace? It replaces hard-coded, rigid workflows. Before agentic solutions, developers had to write long, brittle code for every possible scenario, with if-then-else logic that broke when the user asked something unexpected. Agentic solutions use a language model to make intelligent decisions about which tool to call next, making the system flexible and adaptive.
In Azure AI, you implement this using the capabilities of Azure AI Agent Service, Azure Logic Apps, or custom orchestration patterns with the Semantic Kernel SDK. The orchestration logic can be a simple loop (run until done) or a more sophisticated plan-and-execute pattern. Tools are registered with metadata so the AI model can understand what they do. The AI model, acting as the orchestrator, produces a structured output (like a JSON request) that tells the runtime which tool to call and with what parameters.
For example, a user asks: "Find me a vegan restaurant within 2 miles of the conference centre and book a table for 4 at 7pm tomorrow." The orchestrator might: 1. Interpret the request 2. Call a tool "search_restaurants" with parameters {cuisine: 'vegan', location: 'conference centre address', distance: '2 miles'} 3. Receive a list of restaurants 4. Call another tool "book_table" with parameters {restaurant_id: '123', time: '2025-07-15T19:00', guests: 4} 5. Return a final confirmation to the user
This entire chain is orchestrated automatically. The beauty is that the developer does not have to anticipate every possible request — the AI model, guided by tool descriptions, figures out the path.
Receive User Input
The orchestration loop starts when a user sends a natural language message. This could be a single request or a multi-step instruction. The input is added to the context window, which serves as the memory of the conversation so far.
Model Decides Next Action
The language model, given the context and the list of available tools with their descriptions, decides what to do next. It might output a structured JSON indicating which tool to call (or a message if it can answer directly). This step is purely a decision — no execution happens yet.
Runtime Executes Tool Call
The orchestration system reads the model's output and calls the specified tool with the provided parameters. For example, if the model says to call 'search_flights' with dates, the runtime makes the actual API request to the flight database. The raw result (e.g., a JSON list of flights) is retrieved.
Result Injected Back into Context
The tool's output is formatted and appended to the context window as a new segment. This means the model can now 'see' the result of the tool call. For example, it sees that flights were found and can use that data to formulate a response or decide the next tool call.
Loop Until Goal Is Met
The orchestration loop repeats from step 2: the model looks at the updated context (which now includes the tool result) and decides the next action. This continues until the model determines the user's goal is fully satisfied (e.g., all bookings are made) or a terminating condition is reached (e.g., maximum number of turns or a stop token).
Final Response Delivered
Once the loop ends, the orchestrator compiles a final natural language response for the user, summarising what was accomplished. It may also include suggestions for next steps, achieving a seamless user experience.
An IT professional at a travel company is tasked with building a customer service assistant that handles complex booking changes. The requirement: a user should be able to message the system with something like 'I need to change my flight from London to Paris on the 12th, and also cancel the hotel I booked in Paris, and book a different hotel near the Eiffel Tower.' This is a multi-step request that touches three separate systems.
Here is the concrete step-by-step scenario of what the IT professional does:
They use Azure AI Agent Service to create an agent. They define three tools:
Tool 1: FlightChangeTool (connected to the airline's booking API)
Tool 2: HotelCancelTool (connected to the hotel booking API)
Tool 3: HotelSearchAndBookTool (connected to the same hotel booking API)
Each tool has a clear description, for example: 'HotelSearchAndBookTool: Searches for hotels based on location (city, landmark) and date range, and books the selected hotel. Input: city(string), landmark(string), check_in(string), check_out(string), guests(int), hotel_rating(string). Output: booking confirmation number.'
Next, they write the orchestration logic. This is not a huge code block — it is a loop that: 1. Takes the user's natural language request 2. Passes it to a language model (like GPT-4) along with the descriptions of all three tools 3. The language model returns a decision, often in a structured format like 'call FlightChangeTool with parameters {old_booking_ref: 'ABC123', new_date: '2025-07-12', new_origin: 'London', new_destination: 'Paris'}' 4. The orchestration runtime executes that call, gets the result (e.g., 'Flight changed successfully. New confirmation: XYZ456') 5. The result is fed back into the language model's context, so it knows the flight is done 6. The loop repeats: the language model now sees the remaining tasks (cancel hotel, book new hotel) and decides the next tool to call
The IT professional must also handle errors and edge cases. For example, if the flight change fails because the fare class is full, the orchestration logic might ask the language model to generate a friendly message to the user explaining the issue and offering alternatives, like a different time.
What the IT professional does differently from the old way: before agentic solutions, they would have written a rigid state machine — a flowchart of possible intents with hard-coded paths. If the user said 'change my flight' but also mentioned a hotel, the system would either crash or require the user to start a new conversation. Now, the orchestrator handles it dynamically.
From an operational perspective, the IT professional monitors and logs every orchestration step. They set up fallback rules: if a tool call times out, the orchestrator retries up to three times before alerting a human. They also implement guardrails: before executing a tool that changes a booking, the system double-checks with the user to confirm.
This approach saves the company time (no human agent needed for routine multi-step changes) and reduces errors (the orchestrator follows the same logic every time). The IT professional's role shifts from writing endless 'if-else' code to writing good tool descriptions and robust orchestration error handling.
The AI-102 exam under objective 6.2 expects you to understand the fundamental pattern: an orchestrator (often an AI model) selects and calls tools based on user input. You will not be asked to write code, but you need to explain the architecture and identify correct configurations. Here is exactly what you need to know.
Exam topics they love to test:
The difference between a simple function call (hard-coded) and agentic orchestration (model-driven)
How tool descriptions (name, parameters, description) guide the model's choices
The role of context accumulation: the model sees the history of all tool calls and results to decide the next step
Error handling patterns: what happens when a tool returns an error or unexpected data
The difference between sequential orchestration (step by step) and parallel orchestration (multiple tools at once)
Trap patterns you must avoid:
Trap: 'The orchestrator directly executes the tool.' Correction: the orchestrator (the AI model) decides which tool to call, but a separate runtime layer actually executes the call. The exam might trick you by suggesting the model itself runs the code.
Trap: 'Tool calling is only for external APIs.' Correction: tools can also be internal functions (e.g., calculate_tax) or even other AI models. The definition is broad.
Trap: 'Orchestration and tool integration are the same thing.' Correction: orchestration is the coordination; tool integration is how you define and connect the tools. They work together but are distinct concepts.
Trap: 'The user must specify which tool to call.' Correction: in agentic orchestration, the user asks a high-level question, and the AI model decides which tools to invoke automatically.
Key definitions to memorise:
Orchestrator: the component (usually a language model with a loop) that decides the sequence of actions
Tool: a function or API with a defined schema that the agent can call
Tool schema: a JSON document describing the tool's name, description, and input parameters
Context window: the memory the model uses to track previous steps
Turn: one iteration of the orchestration loop (decision + tool call + result)
What the exam does not ask: you do not need to memorise specific Azure API endpoints or SDK method signatures. They focus on concepts. You might see a multiple-choice question like: 'Which component determines the order in which tools are called in an agentic solution?' The answer is 'the orchestrator'. They might give you a scenario of a user asking 'Book me a flight then a hotel' and ask which pattern is used: 'sequential orchestration' is correct, not parallel, because the flight must be booked before the hotel (to have dates).
Another typical question: 'What information must be provided for a tool to be usable by an AI agent?' The correct answer includes: tool name, description, input parameters (with types). Without a description, the model cannot know when to use the tool. They love testing that a good description is critical.
Study tip: practise drawing the orchestration loop in your head — user prompt -> model decides -> tool call -> result returned -> model decides again -> stop when done. That mental model will help you answer many questions.
An orchestrator is the central decision-maker that uses a language model to plan and sequence tool calls, not the tool itself.
Every tool must have a clear name, description, and input parameter schema so the AI model knows when and how to use it.
Tool integration means connecting an agent to external functions or APIs, but the model only decides the call — a runtime executes it.
Orchestration can be sequential or parallel, and you must choose based on whether tasks depend on each other's outputs.
Error handling in orchestration requires fallback logic, such as retrying a failed tool call or asking the model to rephrase the request.
The context window accumulates every step (user input, tool call, and tool result) so the model can intelligently continue the task.
Agentic solutions replace rigid, pre-programmed workflows with flexible, model-driven decision-making that adapts to varied user requests.
In AI-102, remember that a tool's description is the most critical element — without it, the model cannot know the tool's purpose.
These come up on the exam all the time. Here's how to tell them apart.
Orchestration (Agentic)
Uses an AI model to decide which function to call dynamically based on context
Supports multiple steps and can adapt to unexpected user requests
Requires tool descriptions so the model knows what each function does
Simple Function Calling (Static)
Developer writes fixed if-then-else logic for each possible request
Breaks if the user says something slightly different from expected patterns
No need for descriptions — the function call is hard-coded
Sequential Orchestration
Tools are called one after another, each depending on the previous output
Slower overall because each step must complete before the next begins
Common pattern for booking processes (first check availability, then book)
Parallel Orchestration
Multiple independent tools are called at the same time
Faster because calls overlap, but requires coordination to aggregate results
Ideal for gathering information from separate sources (e.g., weather and news)
Tool (Capability Definition)
A static schema that describes what the tool does and what parameters it needs
Exists as a definition in the system, not as a running call
Example: 'search_hotels tool with inputs {location, dates, guests}'
Action (Call Instance)
A single execution of a tool with specific parameter values
Created dynamically each time the orchestrator decides to use the tool
Example: 'Call search_hotels with location="Paris", dates="12-15 July", guests=2'
Orchestrator (Central Decision)
Responsible for the overall plan and sequencing of steps
Decides which agent or tool to call next
Has the full conversation context to make decisions
Individual Agent (Specialised Worker)
Responsible for executing a specific sub-task (e.g., only booking flights)
Does not know the overall plan — only its assigned tool's job
Has access only to the input parameters passed to it
Mistake
The AI model itself executes the tool call.
Correct
The AI model only decides which tool to call and with what parameters. A separate runtime (like the Azure AI Agent Service runtime) actually makes the HTTP request or calls the function. The model is a decision-maker, not an executor.
In everyday language, 'the AI called the API' makes it sound like the model did the work. But technically, the model outputs a structured object (like JSON), and the orchestration system reads that and performs the call. Beginners conflate the decision with the execution.
Mistake
Tool calling is only for connecting to external services like weather APIs or databases.
Correct
Tool calling can also be for internal functions like 'calculate_discount', 'send_email_notification', or 'get_current_time'. Anything that can be wrapped as a function with inputs and outputs qualifies as a tool, even if it runs inside the same application.
People often think 'tool' means 'third-party API' because that is the most common example. They forget that many enterprise tools are private, internal functions. The exam tests your understanding that tool is a broad concept.
Mistake
Orchestration always runs tools one after another sequentially.
Correct
Orchestration can be sequential or parallel. If two tools are independent (like 'get_weather' and 'get_news'), the orchestrator can call them at the same time. But the default pattern is sequential, because the output of one tool often feeds the input of another.
The word 'orchestration' sounds like a linear conductor leading each section in order. Beginners assume it is always step-by-step. The exam might present a scenario where parallel calls would be correct to optimise speed, so you need to know both patterns exist.
Mistake
An agentic solution always requires a large language model to decide every action.
Correct
While LLMs are the most common orchestrators, you can also use deterministic rules, small language models, or even a hybrid approach. For simple, predictable tasks, a rules-based orchestration (like a flowchart) can be more reliable and faster.
The hype around 'AI agents' makes people think every decision must be made by a powerful LLM. In reality, many production systems use a simpler fallback or a rules-based router for standard intents, and only escalate to an LLM for complex ones. Beginners miss this nuance.
Mistake
The same tool can be called multiple times with identical parameters without issue.
Correct
Idempotency matters: calling a tool like 'charge_credit_card' twice with the same parameters could charge the customer twice unless the tool is designed to be idempotent (i.e., it detects duplicates and returns the previous result). Orchestrators must be designed to handle retries safely.
When learning, people test with read-only tools like 'search_web', so calling twice is fine. But in real business apps, many tools have side effects (sending emails, charging payments, updating databases). Beginners assume all tools are safe to call repeatedly, which is dangerous. The exam tests awareness of side-effect safety.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No, the AI-102 exam tests your conceptual understanding, not coding skills. You need to understand how orchestration works, what a tool is, and how the model selects tools, but you will not be asked to write code.
A tool is a capability you define (like 'search_database'), and an action is an actual call to that tool with specific parameters. The tool is the definition, the action is the execution instance.
Yes, you can define an entire language model as a tool (e.g., 'summarise_text' tool that calls a smaller summarisation model). The orchestrator can call it just like any other external API.
The AI model decides which tool to use based on the description and context. If two tools are too similar, the model may call the wrong one. You must write distinct, precise descriptions to avoid ambiguity.
The orchestrator stops when the model determines the user's request is complete. This is often triggered by the model outputting a stop token or a special message indicating 'task is done'. Developers can also set a maximum number of turns as a safety limit.
Azure Logic Apps is one way to implement orchestration (as a visual workflow), but orchestration is a broader concept. You can also orchestrate using Semantic Kernel, Azure AI Agent Service, or custom code. Logic Apps is a tool, not the definition of orchestration.
You've finished Agentic Solutions: Orchestration and Tool Integration. Continue through the AI-102 study guide to build a complete picture of the exam.
Done with this chapter?