6.3 AI Agents, Tools, Orchestration, and Business Workflows

Agents as bounded task orchestrators

A conversational model can answer questions, but many business requests require steps. A customer asks to change a delivery date. An employee asks whether a laptop is available and then wants to submit a request. A sales manager asks for account risk, then wants a follow-up task created. AI agents are designed for these multi-step scenarios. An agent can interpret the request, ask for missing details, use a knowledge base, and call approved tools, such as business APIs, to take action. The AIF-C01 exam guide version 1.1 asks you to define the role of AI agents and their business applications (objective 3.1.6) and to know foundational agentic AI concepts such as multi-agent patterns, the Model Context Protocol (MCP), memory management, tool usage, and workflow orchestration (objective 2.1.6).

Current AWS services (checked 2026-10-22): Amazon Bedrock AgentCore is AWS's agentic platform for building, deploying, and operating agents with any framework and foundation model, and the version 1.1 guide lists it as in scope. Its modules include Runtime (secure, serverless hosting for agents and tools), Gateway (turns APIs, Lambda functions, and existing services into MCP-compatible tools), Memory (short-term memory for a conversation and long-term memory across sessions), Identity (agent identity and access), Observability (tracing and debugging), and Policy in AgentCore, which evaluates each agent request through AgentCore Gateway against deterministic policies before allowing tool access. Strands Agents, an open-source agent toolkit, is also in scope. The older Amazon Bedrock Agents service, which defined actions as "action groups," is now Amazon Bedrock Agents Classic and is no longer open to new customers; existing customers can continue to use it.

The practitioner-level distinction is important. An agent is not a free-form robot with unlimited access. It should be a bounded orchestrator for a workflow the organization understands. The business defines instructions, available tools, tool input schemas, the systems that carry out each action, knowledge sources, permissions, and escalation behavior. AgentCore provides important agent infrastructure, but the organization is still responsible for whether the agent is allowed to perform a business action and how that action is controlled.

Tool definitions are central. Each tool describes one approved action, such as CreateTicket, GetOrderStatus, CancelReservation, ResetPasswordRequest, or ScheduleAppointment, with the inputs it requires and a description so the agent knows when it has enough information. The business system performs the action. If an input is missing, the agent can ask the user. If a request falls outside the approved tools, the agent should not invent an action.

Scenario: a travel company wants a booking assistant. A simple RAG chatbot can answer baggage policy questions. An agent may be justified if users can check bookings, change dates, or cancel reservations. The agent's tools should expose only the approved booking APIs, require confirmation before cancellation, validate traveler identity through the application, and log the request ID. The agent should not receive broad database credentials or execute arbitrary SQL because the user asked politely.

Scenario: an IT help desk wants to automate password resets. This is high risk because identity and access are involved. An agent might collect the issue summary and create a ticket, but the actual reset may need deterministic identity verification, MFA, approval, or an existing IAM Identity Center workflow. A practitioner should not choose an agent just because the request is repetitive. The right design could be an agent for triage plus a separate secure workflow for privileged actions.

Scenario: a procurement team wants employees to ask for office equipment. An agent can retrieve purchasing policy, ask for quantity, cost center, delivery location, and business justification, then submit a request through an approved tool. It should enforce spending limits, identify missing approvals, and hand off exceptions. If the policy says managers must approve purchases above a threshold, the agent should create a pending request, not approve it itself.

Orchestration design checklist:

• Define the exact business outcome and the actions that are in scope.
• Decide which requests need knowledge retrieval, which need action, and which need refusal.
• Keep the tool list narrow and map each tool to an existing API or controlled function.
• Require confirmation for irreversible, financial, customer-visible, or regulated actions.
• Validate parameters before fulfillment and avoid relying on generated text as a trusted input.
• Use least privilege for service roles and downstream credentials.
• Log the agent trace, API request IDs, user identity, and business outcome where policy allows.
• Provide a human escalation path for ambiguity, errors, policy exceptions, and user disputes.

The agent may need memory or session context, but memory is not a substitute for source-of-truth systems. If a user says their address changed, the agent should call the customer profile API or ask for confirmation based on the approved process. It should not treat a casual chat statement as an authoritative record update without validation. This is where non-builder judgment matters: ask which system of record changes, who can authorize it, and how the organization reverses mistakes.

Agents can be overbuilt. If the user only needs answers from a handbook, a Knowledge Base chat pattern is simpler. If the process is deterministic with fixed fields, a web form or workflow engine may be safer. If the task requires heavy mathematical optimization, a specialized service or custom application may fit better. Choose agents when natural-language interaction, dynamic slot filling, knowledge use, and API orchestration add clear value beyond a normal application flow.

Testing an agent requires more than asking happy-path questions. Use scenarios where the user omits a required field, changes their mind, asks for an unauthorized action, provides conflicting information, requests sensitive data, or triggers a downstream API error. A strong design shows that the agent asks clarifying questions, refuses unsafe requests, retries or escalates cleanly, and records enough evidence for review. For AWS Skill Builder practice, focus on reading agent traces and mapping each step to the business workflow.