4.3AI agent workflows
The essentials in 30 seconds
- The LLM answers, the agent accomplishes: it reasons, picks a tool, calls it, observes the result and retries until the goal.
- Limited toolbox + bounded goal: the agent can only do what it is allowed to do.
- Human in the loop: the agent PROPOSES, a human validates before any sensitive action (send, pay, delete).
Running case — Lina frames a support agent
Building on her classification step (4.2), Lina wants to go further: an agent that reads a technical ticket, searches the internal documentation and drafts a proposed answer. She bounds the goal, limits the tools to three (search, read, draft) and imposes the golden rule: the agent PROPOSES, she validates before sending. First test on ten real tickets, decisions traced, step limit set. Lina has a useful — and safe — agent.
Sequel to cases 4.1-4.2 — Lina moves from one-off AI calls to the framed agent.
1. Answering vs accomplishing
One step up: the AI agent. Where an LLM receives a prompt and answers once, an agent reasons, picks a tool, calls it, observes the result and retries until it reaches its goal. You give it a goal and a toolbox (search, call an API, send an email), and it decides which actions to chain. It is the difference between “answering a question” and “accomplishing a task” — like Lina's support agent that searches then drafts.
2. Building a simple agent
With n8n, Make or Zapier, you build simple agents without coding: an “agent” module connected to tools (authorised actions) and a memory (context: history, intermediate results). Lina's example: goal “propose an answer from the docs”, tools limited to three, memory of the request thread.
The proportionality rule: many needs are handled very well with simple, well-chained AI calls (4.2) — only bring out the agent when autonomous chaining truly adds something.
3. Framing: mandatory safeguards
Powerful, but to be framed: limited tools, human in the loop for sensitive actions, traced decisions, step limit. Lina's agent can neither send nor delete: it proposes, she validates. The agent is the automation that “decides” — hence the safeguards. You widen its autonomy gradually, as confidence in its results grows.
The overzealous agent (scene not to reproduce)
Moral: bounded goal, 3 tools, validating human — the leash is not optional.
🔎 Concrete example — 🔎 Concrete example — A framed support agent
Lina's agent sheet, pinned above her screen:
Goal: propose an answer to a ticket
Tools: search the docs, read a document, draft
Memory: the request thread
Safeguard: the agent PROPOSES → a human validates before sending.Reading: three authorised tools, one implicit prohibition (sending alone).
Lesson: a useful, safe agent with bounded actions.
Section vocabulary
- AI agent
- AI that, to reach a goal, reasons and chains actions itself: pick a tool, call it, observe, retry.
Simple example: Lina's agent searches the docs then drafts, without being told each step.
What it is not: a simple AI call answering a prompt once (see 4.2).
Reflex: ask: does my need really require autonomous chaining?
- Tool
- Action the agent is allowed to use; together they form its toolbox.
Simple example: At Lina's: search, read, draft — and nothing else.
What it is not: unlimited access to all company systems.
Reflex: list the authorised tools in writing before connecting.
- Reasoning loop
- The “think → act → observe” cycle the agent repeats until it reaches the goal.
Simple example: Lina's agent searches, reads the result, refines its search, then drafts.
What it is not: a single answer with no intermediate step.
Reflex: set a step limit to avoid endless loops.
- Memory
- Context kept between steps (history, intermediate results) to guide the agent.
Simple example: Lina's agent keeps the ticket thread during its searches.
What it is not: an external document base (see RAG in 4.4).
Reflex: check what the agent retains — and what it must forget.
- Human in the loop
- Checkpoint where a person validates a sensitive action before the agent performs it.
Simple example: Lina re-reads and validates each answer before sending to the customer.
What it is not: after-the-fact monitoring of damage already done.
Reflex: forbid the agent to send, pay or delete without validation.
In practice — In practice — Building a simple AI agent
- Define a clear, bounded goal (e.g. “propose an answer to a support ticket from the documentation”).
- Give the agent a limited toolbox: search a base, read a document, draft an answer — like Lina.
- Add memory/context so it keeps the thread, and test on real cases while observing its decisions.
- Place a safeguard: the agent PROPOSES, a human validates before sending (especially for sensitive actions).
Ready-to-say script — framing an agent before the team (30 s)
«This is Lina: our support agent proposes answers from the docs, with three authorised tools — search, read, draft. It can neither send nor delete: each proposal goes through human validation before sending. We trace its decisions and will widen its autonomy once tests are conclusive.»
To say before any production rollout; write down the lists of authorised and forbidden tools.
Copy-paste template — agent sheet (fictitious example)
AGENT SHEET — fictitious example to adapt
BOUNDED GOAL: _______________
ALLOWED TOOLS (3 max at first): 1) ________ 2) ________ 3) ________
FORBIDDEN WITHOUT VALIDATION: send / pay / delete
MEMORY: _______________ (thread kept between steps)
STEP LIMIT: _______________ (e.g. 5 max)
HUMAN VALIDATION BY: _______________
DECISION LOG: _______________ (log reviewed on: ___)Pressured customer support
Keep the agent in proposal mode: the gain (pre-drafting) is immediate, the risk (wrong sending) stays zero.
Internal monitoring and synthesis
A good first agent: bounded goal, reversible actions (read, summarise), light validation.
Irreversible actions at stake
Forbid outright: the agent prepares, the human executes — no autonomous sending, payment or deletion.
Team tempted by all-agent
First test chained AI calls (4.2): if they suffice, the agent is superfluous — more powerful but less predictable.
✓ Best practices
- Bound the goal and limit the tools.
- Human in the loop for the sensitive.
- Trace decisions, limit steps.
✗ Common pitfalls
- Giving too many tools or a vague goal.
- Letting the agent act alone on the irreversible.
- Rolling out an agent when chained calls suffice.
Key takeaways
- An AI agent reasons and chains actions itself (pick a tool, call it, observe, loop).
- You provide it with a toolbox (authorised actions) and a memory (context).
- Key difference: the LLM answers, the agent accomplishes a task.
- To be framed: limited tools, human in the loop for the sensitive, traceability.
48h challenge — apply tomorrow
Write the agent sheet for 1 real bounded case (goal, 3 tools max, named human validator) — without connecting it yet.
- I can distinguish an AI call from an AI agent.
- I can cite the 3 mandatory safeguards.
- I have written 1 bounded, validatable agent sheet.
Frequently asked questions
What is the difference between a simple AI call and an agent?
An AI call is one-off: one input, one answer, done. An agent pursues a goal and chains several steps by itself: find information, call a tool, read the result, draft — looping if needed. The call is a function; the agent is an autonomous performer, more powerful but less predictable.
Is a no-code AI agent reliable for production?
With safeguards, yes for many cases: strictly limited tools, bounded goal, human in the loop for the sensitive, traced decisions, step limit. Well framed, an agent that proposes and lets the human validate is already very useful and safe. You widen its autonomy gradually, as confidence grows.
What is the difference between an AI call and an AI agent?