⟶ Insights / AI Engineering
AI agent architectures, for real work.
The patterns senior teams actually ship - single-tool, ReAct, planner-executor, multi-agent - with the guardrails, evals and cost discipline enterprise workloads need. No frameworks-worship. No demoware.
5 min read · By the Jogiitech engineering team · Updated July 2026
The short answer
Pick the simplest agent pattern that meets the SLA. Escalate one tier when - and only when - the previous tier's failure mode is documented, not suspected.
Most 'agent' failures in production are guardrail failures, not model failures. Max-step limits, tool allowlists, output validation and prompt-injection defence are the actual product. The LLM is a component.
The five patterns.
| Pattern | Shape | Where it fits |
|---|---|---|
| Single-tool assistant | One LLM call, one function. | Invoice extraction, structured Q&A, form-filling. |
| ReAct loop | Reason → act → observe, repeat until goal. | Research assistants, deep-lookup copilots, multi-step data pulls. |
| Planner-executor | One model plans; another executes each step. | Durable workflows, back-office automation, claims triage. |
| Multi-agent supervisor | Router delegates to specialised agents. | Cross-domain assistants, complex operational workflows. |
| Human-in-the-loop | Agent proposes; human approves before action. | Regulated, high-stakes or reversibility-limited steps. |
Frequently asked.
What is an 'AI agent', in the sense that matters for enterprise?+
A system that observes state, chooses an action, executes it against a tool or API, and updates its state - autonomously, over multiple steps, toward a goal. That definition rules out most 'agentic' marketing: a single LLM call with a function schema is a tool-use assistant, not an agent. Agents earn their name when they loop.
Which agent pattern do we actually need?+
Four patterns cover 90% of production wins. Single-tool assistant (one call, one function) for structured extraction. ReAct (reason-act-observe loop) for research and multi-step lookup. Planner-executor (one model plans, another executes) for durable workflows with clear steps. Multi-agent supervisor (a router delegates to specialised agents) for cross-domain work. Escalate one tier at a time - not straight to multi-agent.
What breaks in production that doesn't break in a demo?+
Five things, in order: (1) tool failure - the API returns a 5xx and the agent silently loops. (2) Context blowup - the loop grows the message history until you hit token cost or context limits. (3) Prompt injection - a document the agent reads contains instructions that hijack its plan. (4) Non-determinism - the same input produces different actions across runs. (5) Cost drift - a rare long-tail query costs 200x the median. Each has a specific engineering fix; none are 'solved by a better prompt'.
How do we evaluate an agent before we ship it?+
Trajectory evals, not just answer evals. Score the final answer, but also score whether the agent chose the right tools, in the right order, with the right arguments. Build a fixed test set of 100-500 scenarios with expected trajectories, run it in CI on every prompt or model change, and fail the build on regression. Human review of a stratified sample is non-negotiable for high-stakes paths.
What guardrails are non-optional?+
Six. (1) Max-step limit with a hard timeout. (2) Tool allowlist scoped by user role. (3) Input classification to catch prompt injection before the model sees it. (4) Output schema validation with retry-on-fail. (5) PII redaction at ingress and egress. (6) Per-request cost budget with automatic cutoff. Ship all six on day one; retrofitting them is an order of magnitude harder than building them in.
How much does an enterprise agent cost to run?+
Median ticket cost is the wrong number to track. Track the 95th and 99th percentile - a small fraction of long-running trajectories will dominate the bill. Realistic cost bands, all with GPT-4-class models: structured extraction $0.001-0.01 per call, ReAct research agent $0.05-0.50 per session, planner-executor workflow $0.30-3.00 per run. Below those bands you are probably underinstrumented, not efficient.
Matching pattern to failure tolerance.
Every pattern above trades autonomy for risk. The table below is the working matrix our architects use in scoping calls - it maps each pattern to the situation it fits, the way it actually breaks in production, and how much observability it demands before it can be trusted with real traffic. If a proposed pattern needs more observability than the team can realistically staff, that is a signal to step down a tier, not a reason to skip the tooling.
| Pattern | When to use it | Typical failure mode | Observability need |
|---|---|---|---|
| Single-turn tool call | One well-defined lookup or transform per request - invoice fields, sentiment tags, a single API enrichment. | Wrong tool argument passed silently; no loop to catch it before it reaches the caller. | Low - log input, output and the tool call; sample for schema drift. |
| Planner-executor | A durable multi-step job with a known step list - claims triage, onboarding checklists, report assembly. | Planner drifts from the intended sequence, or the executor retries a failed step into a bad state. | Medium - trace every planned step against what actually executed, alert on plan/execution divergence. |
| Multi-agent supervisor | Cross-domain work where sub-tasks need different tools, context or specialised prompts - a support agent that triages, refunds and escalates. | Agents talk past each other; a shared assumption goes stale and one agent acts on it without the others knowing. | High - per-agent traces plus a supervisor-level view of the full conversation and every handoff. |
| Human-in-the-loop workflow | Regulated or hard-to-reverse actions - payments, contract changes, data deletion, anything with legal exposure. | Approval fatigue: reviewers rubber-stamp requests once volume rises, which quietly removes the guardrail. | High - full audit trail of what was proposed, who approved it, and what changed as a result. |
Why teams skip a tier they should not.
The most common architecture mistake we see is not under-building - it is over-building. A team reads about multi-agent supervisors, likes the diagram, and ships one for a workflow that a single-turn tool call would have handled with a fraction of the failure surface. Multi-agent systems introduce a coordination problem that does not exist in simpler patterns: agents can each behave correctly in isolation and still produce a wrong outcome because their shared context drifted.
The fix is a staged rollout: ship the simplest pattern that could plausibly meet the SLA, instrument it properly, and only escalate to the next tier once you have a documented, reproducible failure that the current tier cannot handle. This is also where the guardrail work matters most - a planner-executor workflow with a hard step budget and typed output contracts will outperform a multi-agent system with none, on both cost and reliability.
If you are weighing which tier your workflow actually needs, our AI engineering team runs this triage as the first deliverable of any agent engagement, before a line of orchestration code is written.
Scoping a real agent system?
A 30-minute call with a senior AI architect. We will draw the pattern, the guardrails and the cost curve on the same page.