Agentic AI — System Flow

Block diagram • ReAct loop • Component interplay • Architecture trade-offs

Master Block Diagram — End-to-End Agentic System

Left to right: Input → Agentic Core → World. The dashed return path is the feedback loop that makes it agentic rather than a chain.

AGENTIC CORE — the loop 🎯 Goal / Task user intent + constraints success criteria 🧠 PLANNER decompose · decide next ReAct / Plan-and-Solve ⚙️ EXECUTOR validate args · dispatch retry · timeout · sandbox 🔧 TOOLS search · code · API · DB read vs write privilege ✅ FEEDBACK observe · verify · critique CONTINUE or STOP 💾 MEMORY working — context episodic — events semantic — RAG procedural — skills has NO LLM · pure storage read/write every step 🤖 LLM (stateless) next-token predictor temperature · max_tokens emits intent, not actions 🌍 EXTERNAL WORLD Web / Search Databases / RAG index APIs / Code sandbox Files / Email / Payments goal action invoke raw result LOOP · until done prompt (context in) reasoning / tool call out call data / side effect 🛑 STOP CONDITIONS max_steps · budget · done
control / data flow feedback loop (makes it agentic) memory read/write termination path
How to present this slide: trace your finger along one path only — Goal → Planner → Executor → Tools → World → Feedback → back to Planner. Then say the punchline: "The green edge is the whole story. Delete it and every box remains but the system becomes a chain. The green edge is what makes it an agent."

ReAct Loop — Thought → Action → Observation

The tightest possible agent loop. One iteration = one Thought, one Action, one Observation. The loop exits only on Final Answer or a stop condition.

ONE ITERATION (repeats, max_steps times) 🧠 Thought reason about state "what should I do?" ⚡ Action tool + JSON args runtime executes it 👁 Observation tool result (trimmed) error fed back as data decide execute → result ↻ loop back — append observation to context, reason again INSIDE the LLM YOUR RUNTIME TOOL / WORLD RESULT 🛑 Stop check max_steps · budget · no progress → force terminate ✅ Final Answer goal satisfied → exit loop 🧾 Reflexion (optional) on failure: write why it failed into memory → retry smarter
The line that gets you the job: "Thought and Action are inside the LLM's output. Observation is never written by the model — my runtime injects it. That's the boundary that prevents hallucinated tool results." Point at the purple dashed frames: left = model's job, middle = your code's job, right = the world's answer.

The 5 Core Components — Interplay

Mnemonic P-E-M-T-F — "Perform Every Mission To Finish". Memory is drawn as the hub because every other component reads from and writes to it.

💾 MEMORY the hub — every component reads/writes 🧠 1 · PLANNER decides the next step reactive · upfront · hierarchical ✅ 5 · FEEDBACK observe · verify · critique decides continue vs stop ⚙️ 2 · EXECUTOR validate · dispatch · retry sandbox · idempotency 🔧 3 · TOOLS search · code · API · DB the agent's real capability 4 memory types working · episodic semantic · procedural (working = context window) 🛑 Termination max_steps · budget cap no-progress detector explicit success criteria 1 → 2 → 3 → 5 → back to 1 · memory (4) is touched at every step
Present it as a rotation, not a list: Planner decides (1) → Executor validates & dispatches (2) → Tools hit the world (3) → Feedback observes/verifies (5) → loop returns to Planner. Memory (4) is the only one sitting outside the rotation, and you touch it at every single hop. Court question: "Which component is most often neglected?" → Feedback, specifically the stop condition.

Monolithic vs Modular Architecture

Same task, two shapes. The left is cheaper and simpler; the right isolates context and scopes tools — which is the real reason it works.

MONOLITHIC — one agent, one context ⚠ every step sees everything 🤖 ONE LLM · ONE PROMPT planner + critic + persona in 1 prompt tool A search tool B code tool C…N 40 tools! context bloat · tool-choice confusion ✔ simple · low latency · cheap · one trace ✔ few LOC · easy to prototype ✔ best for 3–10 tools, single domain ✘ context exhaustion · degrades past ~15 tools ✘ no fault isolation · prompt conflicts ✘ hard to debug, one tangled trajectory
MODULAR — orchestrator + specialists 🎛 ORCHESTRATOR routes · merges · never does work 🔎 Research ctx: 2 tools search · scrape 💻 Coding ctx: 2 tools exec · read file 🧪 Critic ctx: rubric only verifies output delegate 🗄 SHARED STATE narrow typed handoffs — not full chat logs ✔ context isolation = each agent small & sharp ✔ scoped tools → high selection accuracy ✔ parallelisable · fault-isolated · extensible ✘ 3–5× complexity · higher cost & latency ✘ new failure: agents miscommunicating ✘ harder global debugging
The senior answer: "Default to monolithic. Modularise only when measurements show a concrete wall — context exhaustion, tool-choice confusion past ~15 tools, or a genuine need for parallelism. Multi-agent is 3–5× the complexity and often worse than one well-engineered agent with good tools."

Where Agents Break — Failure Points on the Flow

Same loop, annotated with the 8 highest-frequency failure modes and the layer that catches each. Green = the mitigation; red = the break.

PREVENT (design) → ABSORB (runtime) → VERIFY (check) → OBSERVE & CONTROL (bound) PLANNER reasoning EXECUTOR dispatch TOOLS/WORLD side effects FEEDBACK verify + stop ① GOAL DRIFT objective lost at step 12 → restate goal every turn → explicit success criteria ② TOOL MISUSE wrong tool · malformed JSON → tight schemas + enums → validate before invoke ③ PROMPT INJECTION untrusted page = instruction → least privilege → approval on writes ④ NO VERIFICATION confident wrong answer → critic / unit tests → schema + output checks ⑤ RUNAWAY LOOP same action forever · never ends → max_steps · budget cap → no-progress detector ⑥ CONTEXT EXHAUSTION truncation → forgets the goal → rolling summarisation → externalise to memory ⑦ ERROR CASCADING step-2 error poisons 3–10 → per-step verification → checkpoints · fail fast ⑧ OSCILLATION thrashes between 2 approaches → loop detection on (action, args) pairs OBSERVE & CONTROL — always on, wraps every box above full trajectory logging · step / token / cost counters · loop detector · kill switch · alerting on abort rate Metrics: task success · steps to completion · tool-call accuracy · cost/task · p95 latency · human-intervention rate · abort rate
The closing line for this slide: "Agent failures aren't reproducible from the output — you must log the whole trajectory. So the two things I build first are an explicit stopping condition and full tracing. Everything else layers on top."