Agentic AI

1. What is it?

An agentic system is an LLM application with control flow: the model (or a graph orchestrating models) decides which steps to take, calls tools, observes results, and iterates toward a goal — instead of executing a single prompt in, answer out.

In practice, “agent” is a spectrum, and the useful end of it is less “autonomous AI” and more stateful workflows with model-driven branches:

prompt chain  →  router  →  stateful graph with tools  →  multi-agent orchestration
(one shot)       (route by intent)   (what I build in production)      (rarely necessary)

2. Why does it exist?

Single prompts fail when the task has any of these:

• Multiple stages with different requirements (draft, then validate, then refine).
• External dependencies — data, systems, or people that must be consulted mid-task.
• Feedback loops — validation results that must change the next step.
• Audit requirements — regulated domains need to know exactly what happened and why.

A graph of typed steps with persisted state solves all four. That is what frameworks like LangGraph formalize: nodes, edges, conditional transitions, checkpoints — ordinary engineering concepts, finally applied to LLM applications.

3. How does it work?

The core loop of a production agent:

1. State — a typed, persistent representation of the task (inputs, findings, decisions, artifacts). Everything hangs off this.
2. Nodes — deterministic steps (validation, formatting, database calls) and model steps (drafting, judging) mixed freely in the same graph.
3. Tools — the agent’s hands: retrieval, APIs, databases, actions. See MCP.
4. Conditional edges — routing logic, which should be code where deterministic and model only where judgment is genuinely required.
5. Checkpoints — state persisted at transitions, so long-running tasks resume after failures and every decision is auditable.

4. Important concepts

• Orchestration vs. autonomy — production “agents” are usually orchestrated workflows with limited model-driven branching. Autonomy is a dial, and most systems want it low.
• Tool use / function calling — structured, schema-validated interfaces to external capabilities. The quality of tool contracts determines agent reliability.
• Human-in-the-loop (HITL) — explicit approval gates where the workflow pauses for a human decision. The single most effective trust mechanism in enterprise adoption.

5. Production considerations

• Determinism where possible — every step moved from “model judgment” to “code” is a step that cannot hallucinate, cannot drift, and can be unit-tested.
• Timeouts, retries, idempotency — agents call external systems; apply the same distributed-systems hygiene as any integration layer.
• Cost — loops multiply token spend. Set explicit budgets and iteration limits per run.
• Observability — trace every node, tool call, and model call (LangSmith or equivalent). Agent debugging without traces is archaeology.
• Evaluation — evaluate graphs per node and end-to-end. A regression in one node is invisible in end-to-end averages.
• Failure containment — a failed tool call should degrade a step, not poison the state graph. Design error paths deliberately.
• Security — tools are privileged interfaces. Scope credentials per tool, validate all inputs, and log every action.

6. How I approach it

1. Write the workflow without AI first. If I cannot describe the state machine on a whiteboard, the agent will not save me.
2. Mark every decision point as code or model — and defend each model decision.
3. Put HITL gates where consequences are irreversible. In pharmaceutical manufacturing, that is before anything reaches a regulated artifact.
4. Persist state at every transition. Resume-ability is a feature users notice before they notice model quality.
5. Measure per-node. The node-level failure rate tells me what to fix; the average does not.

The platform I architected for pharmaceutical recipe authoring works this way: a LangGraph workflow (draft → validate → retrieve → review → refine) with Bedrock models behind MCP tools, LangSmith tracing, and expert approval at defined gates. It reduced authoring effort from 4 months to 10 days — and the graph design, not model choice, is why.

7. Architecture

            ┌──────────── persisted, typed state ────────────┐
            ▼                                                │
user task → [draft] → [validate] ──fail──→ [refine] ←──────┘
                │           │ok                        ▲
                │           ▼                          │
                │      [retrieve context] ─────────────┤
                │           ▼                          │
                └──→ [HITL review gate] ──approved──→ [emit artifact]
                                        │
                                        ▼
                                 [audit log / traces]

Model calls sit inside nodes; routing is mostly deterministic code. The model is never the runtime — it is a component inside it.

8. Common mistakes

• Starting with “autonomous agent” instead of a defined workflow.
• Letting the model route when a rule would do (and vice versa: hard-coding what needs judgment).
• No iteration limits — the agent loops until the bill arrives.
• Prompting the model to “check your work” instead of adding a validation node.
• No persisted state, so every failure restarts from zero.
• Skipping HITL, then wondering why experts do not trust the system.

9. Interview perspective

• “When would you not use an agent?” — when the task is a fixed transformation: use a chain, or plain code. Agents pay for themselves only with real control flow.
• “How do you keep agents reliable?” — typed state, deterministic routing, schema-validated tools, per-node evaluation, iteration budgets, HITL at consequential steps.
• “Multi-agent vs. single agent?” — split only for genuinely different responsibilities; otherwise it is a prompt with extra steps.
• “How do you debug one?” — full tracing of nodes/tools/state transitions; replay runs from checkpoints; evaluate node-by-node.

10. Related topics

• RAG — the tool agents call most often.

• MCP — standardized tool interfaces.

• LLM Evaluation — how to know the graph works.

• State machines vs. free-form loops — bounded, inspectable graphs beat open-ended “let the model decide” loops everywhere outside toys.

• Memory — short-term (within-task state), long-term (across sessions). Most enterprise systems need the first and should distrust the second.

• Multi-agent — split only when responsibilities genuinely differ (e.g., generator vs. critic); otherwise you are paying coordination costs for a bigger prompt.