Agentic AI Product Patterns

TL;DR

• Reliability compounds across dependent steps. A five-step workflow with independent 95% step reliability delivers about 77% end-to-end reliability.
• Three useful production patterns are deep research, task execution, and multi-agent orchestration. Use orchestration only when one bounded agent cannot do the job reliably.
• The best interface follows the job. Sometimes that is chat; often it is a notification, completed task, or changed state.

---

Agentic systems differ from standard AI features because they choose subsequent actions from intermediate results. That extra authority creates product value and more ways to fail.

A compelling demonstration proves that a path can work. A reliable production system must also handle variation, partial failure, permissions, cost and recovery. Closing that gap starts with a precise definition of "agentic" and a workflow narrow enough to evaluate.

What makes a workflow agentic

"Agentic" is not a marketing label. It describes a specific architectural property: the system makes decisions about what to do next based on intermediate results, rather than following a fixed sequence.

Three capabilities commonly appear in agentic workflows:

Autonomy. The system decides its next action based on what it observes, not a hardcoded pipeline. It can branch, loop, retry, or stop based on intermediate results.

Tool use. The system may interact with external systems such as APIs, filesystems, databases, browsers or terminals. Tool access is essential for execution agents, but an agent can also plan, branch and stop without changing external state.

Multi-step execution. The agent maintains context across a chain of operations, accumulating information and adjusting its approach as it goes.

If a system follows a fixed prompt chain with no branching based on intermediate results, it is a pipeline. That may still be the right architecture.

The 95% trap

This is the math that kills agentic products:

A 5-step workflow where each step succeeds 95% of the time delivers 0.95^5 = 77% end-to-end reliability. At 10 steps, you're at 60%. At 20 steps, 36%.

Required reliability depends on the consequence of failure. The compounding accuracy problem means multi-step workflows need explicit validation, recovery, and escalation rather than faith in per-step performance.

The SOP approach

Reliability usually improves faster when the workflow narrows than when the team waits for a stronger model.

Instead of building general-purpose agents, encode a bounded standard operating procedure (SOP). Keep the scaffolding proportionate to the job: give the model the required tools, a goal and explicit constraints. Orchestration built only to compensate for a temporary model weakness may have a short useful life. Each step has:

• A clearly defined input and expected output
• Explicit success criteria (not vibes)
• A fallback path when confidence is low
• A human escalation threshold

Three rules govern reliable agent design:

Remove drudgery, not judgement. Agents excel at patience-heavy tasks (processing 500 invoices, monitoring 12 dashboards, searching across 40 documents). They fail at judgement-heavy tasks (deciding whether to fire a vendor, choosing between two product strategies). If the task requires weighing competing values or navigating ambiguity, keep a human in the loop.

Validate one step before chaining. Don't begin with a ten-step agent. Build one step, test it against a threshold set by the cost of failure, then add the next. Each step earns its place through measured performance, not assumed competence. The evaluation frameworks chapter covers how to build the eval suites that make this validation rigorous.

Narrow the context. Broad, noisy context can reduce reliability and always widens the security boundary. The PM's job is to define which tools, data sources and actions the task requires. Supply those inputs and exclude the rest.

Three production patterns

1. Deep research (plan-gather-synthesise)

The agent creates a research plan, executes searches across multiple sources, gathers information, and synthesises a structured output.

This pattern is comparatively easy to constrain when operations remain read-only, each phase has a clear output and the final synthesis is reviewed before action.

When to use it: competitive intelligence, due diligence, customer research, technical analysis, regulatory scanning, content aggregation.

PM decisions: which sources to include, how to handle conflicting information, what output structure serves the user, how to score source reliability. The retrieval layer itself is a product decision: chunking, indexing, and grounding choices have direct UX and trust implications that PMs should own, not delegate entirely to engineering.

2. Task execution (filesystem, terminal, API access)

The agent receives a goal, plans an approach, and executes it using real tools: writing files, running commands, calling APIs, modifying databases.

This pattern powers AI coding assistants, IT automation, data pipeline management, and operational workflows. It's more powerful than deep research and more dangerous, because the agent changes state.

When to use it: code generation and review, infrastructure management, data transformation, document generation, workflow automation.

PM decisions: which tools the agent can access (principle of least privilege), what requires human approval before execution, how to handle partial completion, rollback strategies when things go wrong.

3. Multi-agent orchestration (manager-worker hierarchies)

Multiple specialised agents collaborate on a task, coordinated by a manager agent that delegates work, aggregates results, and handles exceptions. The multi-model orchestration chapter covers the routing and model selection decisions that underpin this pattern.

This pattern can produce impressive demonstrations, but coordination, compounded failure and multiplied cost make it harder to operate. Use it only when specialised or parallel workers improve the outcome enough to justify that overhead.

When to use it: complex workflows requiring genuinely different capabilities (one agent searches, another analyses, a third writes), tasks too large for a single context window, workflows where parallel execution provides meaningful speed improvement.

When NOT to use it: when a single agent with the right tools can do the job (the most common case), when the orchestration cost exceeds the task value, when you can't afford the manager's audit tax.

The manager-worker pattern introduces a specific cost problem: the reviewer consumes worker traces and may call tools or trigger retries. Calculate the full trace rather than assuming the manager is a small surcharge. Use deterministic checks where possible, calibrated risk signals where validated, and sampled review for low-consequence outputs. High-consequence actions still need the review required by their risk class. The business viability chapter provides the full cost formula.

Execution agents vs chat agents

Many enterprise AI workflows stop at generated text: a human reads it, copies what is relevant, and acts manually. The loop does not close. The agent talks; the human does.

Execution agents close the loop. Instead of generating a recommendation about what to do, they do it: write the file, call the API, update the record, run the test. The output is a changed state in the world, not a message for a human to interpret. For products whose value is completing work, execution architecture can matter more than another increment of model quality.

This is an important architectural distinction in agentic AI. Many product teams default to chat because it is familiar and reviewable. That can leave the user doing the last mile of copying, translating, and acting. When the job is execution, measure that detour against a safely integrated workflow.

What execution agents require

System access. Execution agents need real integration with the systems they act on: filesystem access, API credentials, database write permissions. Teams hesitate because the risk is real. Manage it through scope constraints, least privilege, approval, observability, and recovery. A read-only agent that returns suggestions is a research tool, not an execution agent.

Persistent task state. Multi-step or long-running work needs a durable record of completed actions, findings, constraints and pending work. User preferences may belong in separate memory with explicit consent and retention controls. Neither chat nor execution alone determines whether persistence is required.

Sandboxed consequences. Because execution agents change real state, rollback capability and permission scoping become product requirements, not engineering nice-to-haves. The principle of least privilege is the safety model: the agent has access to exactly what it needs for the task, nothing more.

Locate the handoff from AI output to human action, then decide whether eliminating it improves the job without exceeding the risk. A manual step after an AI output is a candidate for execution, not automatic evidence that it should be removed.

The copilot-to-autopilot spectrum

Not every AI feature needs the same level of autonomy. The design decision is where on the spectrum each feature sits:

Begin at the highest autonomy that the evidence, reversibility and consequence of failure support. Novel or consequential work will often start in shadow mode or as a copilot. Low-risk, deterministic jobs may begin with bounded autonomy. Moving further along the spectrum is optional, not a maturity requirement.

A costly product mistake in agentic AI is starting at the wrong level of autonomy. Too much autonomy with unproven reliability damages trust. Too little autonomy where reliability and recovery are proven leaves value unrealised.

Invisible AI: an important pattern

Many valuable agentic products do not need chat interfaces.

The UI is a notification that a task completed. A changed field in a CRM. A generated report in your inbox. A flagged anomaly in your dashboard. The user doesn't interact with the agent. The user interacts with the outcome.

Chat interfaces force users through the "AI detour": open a separate tool, formulate a prompt, interpret the response, copy the result back to where they were working. Every step in that detour loses users.

When designing agentic features, ask whether the agent can work within the user's existing workflow. The right interface makes the outcome clear and gives the user the control the risk requires.

What agentic PMs look like

The anti-pattern: the everything agent

The everything agent can "do anything." It has access to all your tools, all your data, and a system prompt the length of a novel. It demos beautifully. A founder can show it doing five impressive things in a row.

In production, its broad scope makes failures harder to predict, costs harder to control and permissions harder to secure. A wrong action can damage trust quickly.

A common fix is to decompose the everything agent into narrower workflows. Each workflow has clear inputs, outputs, success criteria, permissions, and cost ceilings. Broader autonomy should be earned through evidence that it improves the outcome without exceeding the risk and operating budget.