Designing an Effective Agentic AI System

Definition

Agent architecture selection chooses how models, deterministic software, tools, state and human decisions work together to achieve a specified outcome within operational constraints.

Begin with the service contract: who needs what outcome, which errors matter, what data is available and which actions may change the world. A system that only summarizes documents has different requirements from one that modifies customer accounts. Similar chat interfaces can conceal very different engineering needs.

What it covers

Task

Define accepted outcomes, uncertainty and consequential actions.

Baseline

Compare ordinary software, retrieval, fixed workflows and adaptive agents.

Boundaries

Place authorization, validation and resource limits at execution boundaries.

Evidence

Evaluate usefulness, failures, cost, latency and recovery before expansion.

A practical reference design has request intake, task state, a planner or fixed workflow, a policy-enforced tool boundary, outcome verification and an operational record. Human approval enters where the consequences require it. These are responsibilities, not necessarily separate services or a mandatory technology stack.

In practice

Practical design patterns by Min.

• Start with a task specification and representative evaluation cases.
• Choose a fixed workflow when the required steps are known; add adaptive planning where evidence supports it.
• Document trade-offs and release a bounded version with an accountable owner.

Select components by measured contribution. An extra planning loop, retrieval stage or specialist agent should resolve an observed problem that a simpler design cannot handle adequately. Record its effect on completion quality, prohibited actions, latency, cost and operational complexity.

Research notes

Source-grounded details and editorial applications. Follow each link for the original document.

Working example

Why the controls matter

The procurement example separates judgment from execution. A model can help interpret a supplier description, while ordinary software checks arithmetic and current limits. A verified purchase receipt establishes the external outcome; the model’s narrative alone does not. Recovery must handle a timeout after submission.

Common pitfalls

• Equating more agents with a better architecture.
• Using model instructions as the only authorization control.
• Optimizing a demo without measuring maintenance, failure recovery or user outcomes.

Treat the design as a versioned hypothesis. Pilot with limited data and authority, inspect failures, and revise the relevant component. Expand only when the evidence supports the broader use. Keep rollback, ownership and ongoing evaluation in the design from the beginning.

Questions for operational review

Use these questions to decide what evidence your team needs. They are editorial prompts, not a compliance checklist.

• Could a simpler workflow meet the same requirements?
• Where are permissions and budgets actually enforced?
• What evidence justifies each added component?