Agentic Flows: When AI Orchestrates Its Own Path

In the previous chapters we built the pieces separately: RAG (Chapter 5, the model queries documents), MCP (Chapter 5c, the application connects tools and external systems), and memory. But having the pieces is not enough — a useful system needs to orchestrate them intelligently. That is an agentic flow: a dynamic, multi-step system where the LLM decides what information it needs, in what order to get it, which tools to use, and how to answer in order to solve a goal from start to finish.

What is an agent? (and what is not)

For this compendium, an AI agent is a system that has a goal, can perceive its environment (prompts, tools, memory), can act on that environment, makes autonomous decisions about which steps to take, and adapts within the limits the system imposes on it.

What is NOT an agent, under this working definition:

• A deterministic pipeline (“Step 1: policy. Step 2: balance. Step 3: calendar.”) — if the order is always the same and there is no real decision, it is a fixed flow, not an agent. This is exactly the distinction we draw in Chapter 6b: the sequential, parallel, and loop patterns can be orchestrated by code, not by the LLM. They can use models in their steps without becoming autonomous agents because of it.
• A single LLM call, no matter how sophisticated the answer.
• A system with no ability to interact with its environment — if it only answers once and cannot query or change anything, it works as a chatbot, not as the kind of agent we study here.

These boundaries are not universal: the industry uses the word agent with broader and narrower definitions. What matters is declaring which decisions the model makes and which ones stay encoded.

Analogy: an agent is like a human personal assistant. You say, “I want to go on vacation next week,” and it decides what to look up, in what order, proposes alternatives if there is a problem, and confirms with you before acting. A deterministic pipeline, by contrast, is like a vending machine: you insert a coin, pick a product, receive a product — no decision, no adaptation.

The scenario: our HR agent

An employee writes: “Hey, I want to take a few days next week to go to the beach — what do I need to do?”

A traditional RAG system would look up the policy and return a generic chunk — it would not solve the question, because it does not know the personal balance or the team’s availability. A system with RAG + MCP but no agent would run a fixed sequence: policy → balance → calendar → reply. It would work for this case, but it could fail if the employee says “actually, better two weeks in a row, but I don’t know if I can” and that branch was never programmed. An agent decides the flow in real time: it recognizes what information is missing, decides the order, proposes alternatives within its permissions if needed, and confirms before acting.

“Fuzzy engineering”: from deterministic code to probabilistic decisions

In traditional software, the flow is expressed with deterministic rules: you have to anticipate the relevant states and encode their response. The problem is that the real world can produce an enormous number of combinations. What happens if the employee has balance but the team is fully booked? If they ask for a holiday date? If they ask for three weeks and the policy allows two at most? A growing web of if/else can become fragile, expensive, and hard to maintain.

In the agentic approach (fuzzy), the LLM reasons in natural language about what it needs to do. You do not encode every branch; you encode bounded tools, policies, permissions, and instructions, and the model proposes a path.

Analogy: a GPS with a static route only knows the path it already calculated. A navigator knows goals and constraints, can react to traffic, and suggest alternatives.

The flip side is that agentic behavior is probabilistic — the same question can produce slightly different decisions across runs because of sampling and because of context changes. That is a problem for systems that need absolute consistency, but an advantage when handling edge cases. That is why critical constraints must not depend solely on the model “remembering” to obey them: they are also enforced in code and on the tool servers.

Case study (Workera): Workera combines deterministic evaluations for fixed answers with evaluations that require judgment, such as conversational role-play. Its Score Appeal mechanism lets someone request a human review when they challenge an evaluation. It is an example of human in the loop: the AI scales the first analysis, but a contested decision can be reviewed and corrected by specialists.

The four pillars of an agent

1. Prompts (identity and rules)

You are an HR assistant specialized in time-off requests.

Your rules:
1. Verify the general policy (RAG) before giving information.
2. Check the employee's personal balance through an authorized tool.
3. Verify team availability for the requested dates.
4. If there is a conflict, offer permitted alternatives.
5. NEVER submit a request without the employee's explicit confirmation.
6. If you do not have enough information, ask for clarification; do not guess.

The prompt can include examples of good behavior (few-shot, Chapter 2), explicit decision criteria, and verification steps. It is not enough on its own to enforce safety: authorization constraints and real-world effects must also exist outside the prompt.

2. Memory (accumulated knowledge)

• Working memory: the context of the current conversation — message history, results of tools already invoked, and the state of the flow. It is supplied to the model at every step. It is fast and simple, but it is limited by the context window and increases token consumption.
• Semantic memory: relatively stable general facts — for example, the vacation policy. It can be implemented through RAG (vector database + embeddings) and updated when the documents are reindexed.
• Episodic memory: specific events from past interactions — for example, “in an earlier conversation the employee preferred to travel in the first week of the month” or “a request was started with this identifier”. It can be stored in a vector database or in a structured log, depending on the type of query.

Episodic memory must not replace the operational source of truth. That a past interaction says “request pending” does not guarantee it is still pending: the agent must query the HR system again before making a current decision.

An important clarification, again: MCP is not memory. Looking up the balance in real time is not “remembering” — it is fetching a datum that changes, and that a vectorized memory could have stale. MCP belongs in the next pillar, tools and external systems.

3. Tools (in this case, via MCP)

check_vacation_balance, check_team_calendar, request_vacation — each one is an operation with typed parameters, a clear description, and permissions enforced by the server (Chapter 5c). The host discovers what is available, and the agent proposes which ones to use and in what order.

MCP is a standardized way to connect those tools, not a conceptual requirement for an agent to exist.

4. Degrees of autonomy

Degree	Description	Example in our case	Advantage	Disadvantage
Low	Rigid steps, encoded by the developer	Policy → balance → calendar → reply, always in that order	Predictable, easy to debug	Does not handle unprogrammed edge cases
Medium	The agent decides the order, under safety rules	Decides whether to check the calendar or the balance first; can skip unnecessary lookups	Flexible, handles more variants	Less predictable behavior
High	The agent decides the full flow within defined permissions	If the team is fully booked, it looks up alternative weeks without being asked	Maximum flexibility	Higher risk, cost, and evaluation difficulty

Recommended starting point: start with low or medium autonomy. Move to high only when robust evals (LLM judges and evals) confirm the behavior and limits exist outside the model. The Tay case in Base-model limits shows the risk of an adaptive system exposed without enough barriers, even though its mechanism was not identical to a modern agent’s.

The full flow, step by step

Step 1 — Working memory: the agent receives the message and determines that policy, balance, and team availability are missing.

Step 2 — Tool discovery: it looks up what is available, or uses a cached list whose freshness the host controls.

Step 3 — Execution, according to the degree of autonomy:

With low autonomy (deterministic code):

policy = lookup_general_policy("vacation")
balance = check_vacation_balance(employee_id)
availability = check_team_calendar(start_date, end_date)
response = generate_response(policy, balance, availability)

With medium or high autonomy, the LLM can build a plan: “First I check the balance. If they have no days available, I don’t need to look up the calendar. If it is enough, I check availability.” Then it runs check_vacation_balance → 12 days available → check_team_calendar → high availability. If the calendar were full and its permissions allowed it, it could look up alternative weeks.

Step 4 — Synthesis: the agent integrates policy, balance, calendar, and relevant history, and replies: “You have 12 days available. Next week the team has good availability. Should I file the request?” The 12 days come from the live lookup, not from episodic memory.

Step 5 — Confirmation and action: the user confirms. The agent executes request_vacation via MCP — never before explicit confirmation.

Step 6 — Episodic memory update:

{
  "employee_id": "emp_12345",
  "event": "vacation_request",
  "request_id": "VAC-2026-8473",
  "start_date": "2026-09-01",
  "end_date": "2026-09-07",
  "observed_status": "pending"
}

Next time, this memory can help decide what to look up, but the current state must be verified in the HR system using request_id.

The agentic flow as a loop — the same idea as ReAct, with more granularity

An agent is not necessarily a single sequential run — it can walk a loop until it reaches the goal, asks for help, or hits a limit:

1. Perceive → receive input from the user or the environment
2. Reason   → decide what information is missing and what to do
3. Act      → call tools or query memory
4. Evaluate → check whether the goal was reached or something is still missing
5. Iterate  → return to the cycle with the new information

This is not a new, separate concept — it is, in essence, the same ReAct pattern (Reason → Act → Observe) we cover in Agentic architecture patterns with the paycheck investigation. There it appears in three moves; here we break it into five, explicitly separating “perceive” from “reason”, and “evaluate” from “iterate”. The core idea is identical: reason, act, observe the result, and repeat until you are done.

Each iteration adds information to working memory. To avoid unbounded loops, the system must define a maximum number of iterations, cost and time budgets, and an exit or human-escalation condition.

Why this is not just “RAG + MCP together”

Aspect	Pipeline (RAG + MCP)	Agent (agentic flow)
Execution order	Fixed, encoded	Decided by the LLM within limits
Edge-case handling	Limited to what was programmed	Can propose routes that were never explicitly enumerated
Memory	Can have working memory	Can query and update different kinds of memory
Adaptability	Requires changing the flow	Can vary the plan at runtime

Analogy: a pipeline is a recipe. An agent is an experienced chef — it knows ingredients and tools, and improvises if something is missing. Technically we already had RAG and MCP in earlier chapters; what turns this into an agentic flow is not having the pieces, but how their orchestration is decided.

The organization patterns — a preview

There are specific patterns for organizing several agents or steps — sequential, parallel, coordinator, hierarchical, swarm, and more. We cover them in depth in Agentic architecture patterns, with complete examples of our own: expense receipts as a sequential flow, a climate survey as parallel, and message routing through a coordinator, among others. We do not repeat their table or their explanation here.

Our vacation case uses mainly medium autonomy inside a single agent. It does not yet need the complexity of multiple coordinated agents.

The challenges of agentic flows, and how to mitigate them

Unpredictable behavior (especially with high autonomy): start with low or medium autonomy, use evals (LLM judges and evals), keep decision traces, and apply guardrails both on the host and on the tools.

Context buildup: each iteration adds tokens; with many iterations the window can saturate. Mitigation: summarize history carefully, retrieve only pertinent information, and cap the maximum number of iterations.

Cost and latency: each iteration can imply one LLM call and several tool calls. Mitigation: small models for simple decisions, parallelism when there are no dependencies, cache for stable data, and per-run budgets.

Security: an agent can be manipulated into proposing unwanted actions — the indirect-injection risk Finnbot illustrates in Part III. Mitigation: strict authorization and validation on every tool, human confirmation for high-impact actions, least privilege, and full audit.

Chapter summary

An agentic flow is a multi-step system where the LLM takes part in deciding the path to reach a goal:

• What an agent is (and is not): under our definition, it perceives, acts, and decides among steps — it is not just a fixed pipeline or an isolated call.
• Fuzzy engineering: probabilistic decisions that handle variants, accompanied by deterministic limits.
• Four pillars: prompts, memory, tools, and degrees of autonomy.
• The agentic loop is the same core principle as ReAct in Agentic architecture patterns, described here with more granularity.
• The sequential, parallel, coordinator, and other patterns are covered in depth in that chapter, without duplicating them here.
• Unpredictability, context, cost, and security require concrete, measurable mitigations.

In the next chapter (Agentic architecture patterns) we will go deeper into agentic architecture patterns; after that we will look at multi-agent systems, for the cases where a single agent is not enough.