Workflows are scripted sequences: Step 1, then Step 2, then Step 3. But many real business problems don't have predetermined sequences. A customer inquiry might need data lookup, then research, then synthesis, then escalation—or it might need just data lookup and synthesis. The path depends on what the AI learns as it proceeds.

Agent systems flip the paradigm. Instead of specifying steps, you specify goals and tools. The AI agent decides which tools to use, in what order, and when it has enough information to complete the task. This flexibility is powerful but requires different thinking about control, safety, and correctness.

By the end of this lecture, you'll understand agent architectures, how to give agents access to tools safely, how multi-agent systems coordinate, and when to use agents versus workflows.

Agents vs. Workflows: Fundamental Difference

A workflow is deterministic: given input X, it always executes steps Y and Z. An agent is adaptive: given input X, it chooses the path that solves the problem best, which might be different for each input.

Workflow: "For every customer support ticket, extract the intent, look up the policy, generate a response, send it. Done."

Agent: "Given a customer support ticket, figure out what the customer wants. Explore policies, documentation, or past interactions as needed. Provide a response. If you can't resolve it, escalate to a human. Decide how to handle escalation."

The agent is deciding, not executing a predetermined script. This is more powerful for complex, open-ended problems. It's also riskier—the agent might make unexpected choices. This is why agent design requires careful constraints.

Agent Architecture: The Tool-Use Loop

An agent operates in a loop: observe state -> reason about available tools -> choose and call a tool -> receive result -> repeat until done.

Each loop iteration, the agent has available context (the problem, previous tool results, conversation history) and must decide: which tool should I use next? Most modern agents use large language models for this decision reasoning.

Step 1: Define the Goal and Context

Start the agent with clear instructions: "You are a customer support agent. Your goal is to resolve this customer's issue. You have access to these tools: search_documentation, lookup_account, send_email. Use these tools as needed. When you've resolved the issue or determined it needs human intervention, stop and provide a summary."

Step 2: Make Tools Available

Tools are functions the agent can call. You define them by providing: name (what the agent calls it), description (what it does), parameters (what inputs it takes), and implementation (code that executes the tool).

Example tool: lookup_account. Description: "Find customer account details by email." Parameters: customer_email (string). Implementation: database query. When the agent decides "I should look up this customer's account," it calls lookup_account with the email, and your system executes the database query.

Step 3: Reasoning Loop

The agent observes available tools and current context. It reasons: "The customer is asking about their billing. I should look up their account to see recent charges. After that, I might need to search our billing policies."

Most modern agents use function-calling APIs provided by LLM providers. You tell your AI tool: "Here are the tools you can use" (via the API), your AI tool decides which to use and provides a structured response saying "Call lookup_account with [email protected]." Your system executes that call, passes the result back to Claude, and your AI tool decides the next step.

Step 4: Tool Execution and Feedback

When the agent calls a tool, the result feeds back into the next iteration. "The account shows 3 failed payments. The customer's billing address changed last week." The agent processes this information and might decide: "I need to check our policies about payment failures."

Step 5: Stopping Condition

The agent stops when it has resolved the issue, determined it needs escalation, or reached a maximum iteration limit. Define clear stopping criteria upfront: "Stop when you've provided a resolution OR when you've determined the customer needs to speak with a specialist."

Controlling Agent Behavior: Tools and Constraints

The biggest risk with agents is unintended behavior. If an agent has access to a "delete_customer" tool, it might delete the wrong customer if it misunderstands context. You control agent behavior through tool constraints and safety measures.

Tool Access Control

Each agent should have access to only the tools necessary for its job. A billing agent doesn't need access to personnel records. A data analyst doesn't need access to payment processing. This principle of least privilege prevents mistakes from cascading.

Tool Parameter Constraints

Some tools might be inherently risky. A "send_email" tool should enforce: can only send to customer-related addresses, not arbitrary email addresses. A "apply_discount" tool should enforce: discount cannot exceed 50%, must be logged with reason.

Define these constraints in the tool definition, not by hoping the agent is careful. The system should reject invalid calls automatically.

Approval Gates for Risky Actions

Certain actions (refunds, deletions, major updates) shouldn't be automatic even with agent approval. Implement approval gates: agent proposes a refund, system flags it for human approval, human reviews and approves/rejects, then execution happens.

Monitoring and Logging

Log every tool call an agent makes: when, which agent, which tool, with what parameters, what result came back. This creates an audit trail and helps you spot problematic patterns: an agent repeatedly trying the same tool with different parameters, an agent calling tools in unexpected sequences.

Multi-Agent Systems and Coordination

Real business problems often need specialized agents. One agent analyzes data, another checks policies, a third handles customer communication. Coordinating multiple agents is more complex than running a single agent.

Sequential Agent Coordination

Agent A completes its task, then Agent B starts using A's output. Example: Agent A (analyst) analyzes a customer complaint and produces a summary. Agent B (policy checker) reads the summary and checks relevant policies. Agent C (resolver) uses both to generate a response.

This is straightforward because each agent completes before the next starts. The challenge: if Agent A produces bad output, Agent B's decisions are compromised. Implement quality checks between agents.

Parallel Agent Coordination

Multiple agents work simultaneously on independent parts of the problem. Example: Agent A looks up customer account history. Agent B searches product documentation. Agent C checks inventory. They work in parallel, then results combine. This is faster but requires careful merging: what if agents find conflicting information?

Hierarchical Coordination

A manager agent delegates to specialist agents and synthesizes results. Example: Manager agent receives a complex request and decides "This needs financial analysis (delegate to finance agent) and legal review (delegate to legal agent). After both complete, synthesize the results and provide recommendation."

This pattern works well when tasks are clearly separable and one agent (the manager) has authority over the specialists.

Peer-to-Peer Agent Communication

Agents communicate directly with each other to negotiate or share information. This is most complex because you need to define communication protocols (how agents ask each other for information, how they handle disagreement). Reserve this for sophisticated systems.

Coordination Pattern	When to Use	Complexity	Risk Factors	Example
Sequential	Tasks must happen in order; later agents depend on earlier results	Low	Bad output from early agents propagates	Analyze -> Check -> Respond
Parallel	Tasks are independent; need all results before synthesis	Medium	Conflicting results; synchronization complexity	Data lookup, Policy check, Inventory check in parallel
Hierarchical	Manager makes high-level decisions; specialists handle domains	Medium	Manager bottleneck; specialist disagreement	Manager delegates to Finance, Legal, Operations agents
Peer-to-Peer	Agents need to negotiate or collaborate directly	High	Deadlock; infinite communication loops	Complex distributed problem solving

Handling Agent Failures and Unexpected Behavior

Agents make mistakes. An agent might choose the wrong tool, misinterpret a tool's result, enter an infinite loop calling the same tool repeatedly, or try to use a tool with invalid parameters. Design for these failures.

Tool Call Validation

Before executing any tool, validate the call. Is the tool available? Are the parameters correct? Are they in acceptable ranges? If validation fails, provide clear feedback to the agent: "That tool doesn't accept parameters of type X. Please try again with valid parameters."

Result Validation

After a tool executes, validate the result. Sometimes tool calls succeed but return unexpected data. The agent should handle this: "The search returned 1000 results, which is too many to process. Try a more specific search."

Iteration Limits

Set maximum iterations. If an agent runs 50 loops without resolving the problem, stop it. It's probably stuck. This prevents resource exhaustion and uncontrolled costs.

Timeout Management

Individual tool calls should timeout. If a database query hangs, don't wait forever. Timeout after N seconds and tell the agent "The tool timed out. Try a different approach."

Escalation Patterns

Define what the agent should do when stuck. "If you've tried 5 times and can't resolve it, escalate to human review." This is explicit: the agent knows when to give up and get help.

Agents vs. Workflows: Decision Framework

Use an agent when: the problem is open-ended, the solution path depends on problem details, you want adaptive behavior, the task involves reasoning and exploration.

Use a workflow when: the process is well-defined and repeatable, the steps are always the same regardless of input, you need predictable behavior for compliance, error recovery must follow precise rules.

In practice, hybrid solutions are common: workflows that contain agents at certain steps, agents that call out to workflows for well-defined subtasks.

What You'll Learn Next

Now that you understand how agents work independently and in teams, the next lecture focuses on keeping them running reliably. In , you'll learn how to build resilience into workflows and agent systems, implement retry logic that actually works, and design graceful degradation when things break.