From chat interfaces to goal-seeking software
A chatbot answers a prompt. An intelligent agent accepts a goal, decomposes it, calls tools, and continues until a stopping condition is met or a human intervenes. In business settings those tools are rarely toys: ticket systems, ERP APIs, document stores, browsers, code repositories, and approval queues. The agent is only as trustworthy as the least-safe tool you expose and the weakest check you apply to its plan.
Teams waste cycles debating whether something is “really an agent.” Use a simpler test: does the system select actions over time based on intermediate observations, or does it execute a fixed workflow with optional LLM steps? The former needs agent controls; the latter needs workflow engineering. Many high-ROI products are hybrid—deterministic rails with agentic segments where ambiguity peaks.
Core design patterns
Planner–executor loops
A planning step drafts a task list; an executor runs tools; a critic or verifier judges outcomes. Separating roles improves debuggability. Cap plan depth and step count up front. Infinite replanning is a cost centre, not a feature.
Tool-specialised agents
Rather than one omniscient agent with forty tools, define narrow agents: research, CRM update, policy lookup, code change proposal. A thin orchestrator routes work. Narrow tool sets raise argument accuracy and lower blast radius.
Human-in-the-loop gates
High-impact actions—refunds above a threshold, customer emails, production deploys, contract edits—require explicit approval states. Design the UI of approval, not just the model prompt. Show the intended tool arguments, data sources cited, and residual uncertainty.
Memory tiers
Working memory lives in the context window. Episodic memory stores prior runs and decisions. Institutional memory is your RAG corpus and structured systems of record. Confusing these tiers produces either amnesia or hallucinated “policy.”
Pros and cons versus scripted automation
| Dimension | Intelligent agents | Scripted automation |
|---|---|---|
| Ambiguous inputs | Strong when trained/evaluated carefully | Brittle without exhaustive branching |
| Auditability | Needs structured traces and replay | Naturally step-linear logs |
| Cost per run | Variable; can spiral with retries | Stable and low |
| Change adaptation | Handles novel phrasings better | Requires engineer time per edge case |
| Failure style | Can fail creatively and confidently | Fails predictably at unhandled paths |
Failure modes you must design for
Tool hallucination: inventing endpoints or parameters. Mitigate with strict schema validation and allow-lists.
Goal drift: solving a neighbouring problem that feels complete. Mitigate with explicit success criteria encoded as check functions, not only prose.
Looping: repeated searches or edits that never converge. Mitigate with step budgets, duplicate-action detection, and forced escalation.
Privilege creep: giving the agent broad tokens “for later.” Mitigate with per-tool credentials, time-boxed tokens, and environment separation (read-only research vs write-capable production).
Evaluation theatre: demo scripts that hide brittle paths. Mitigate with held-out task suites and adversarial prompts maintained by someone other than the prompt author.
Evaluation discipline that finance will fund
Score agents on task success rate, partial credit for recoverable progress, average tool calls to completion, human escalation rate, and cost per successful outcome. Include policy violations as hard fails even when the “job” appears done. Record traces with enough fidelity to replay offline when models change.
Offline evals catch regressions; online shadow mode catches distribution shift. Never promote an agent version on anecdote alone. Version prompts, tool schemas, and retrieval corpora together so you can attribute deltas.
Pricing and capacity notes
Agentic workloads multiply tokens: plans, reflections, tool payloads, and retries all bill. A process that looks cheap in a single-shot draft can become expensive as an eight-step loop. Budget for reserved capacity or batch windows when agents process queues overnight. Some vendors sell agent runtimes with included orchestration; compare those fees against building a thin loop on raw model APIs plus your own queue.
Staff cost still dominates early programmes. The scarce skill is not “writing a ReAct prompt”—it is productising safe tool interfaces and reliable evaluation. Hire or train for that seam.
When not to use an agent
If the process is fully known, high-volume, and rarely exceptions-driven, classical automation will beat agents on cost and auditability. If the process is rare, high-stakes, and poorly specified, a skilled human with AI assistive tools may beat a semi-autonomous agent. Agents earn their keep in the middle: frequent enough to automate, variable enough to need judgment, bounded enough to supervise.
Next, explore how vendors package these patterns as agentic services, and how automation platforms host the surrounding workflow fabric.