Agentic Systems · 15 min read · estimate

Choose an agent, a workflow, or a simpler solution

Use five decision gates, a worked example, and a copy-ready brief to pick the simplest design worth testing.

By the ChatwithGPT editorial project · Prepared with AI assistance · Published October 13, 2026 · Version 1.0

Published and reviewed: 2026-10-13 · Version 1.0 · 15-minute read; 30-minute exercise

Start here

Before building an agent, write down the result you need and the decisions that genuinely change from one request to another. A fixed sequence is often enough. An agent becomes worth testing when choosing the next step is part of the problem, and you can still check its work.

This guide produces a one-page architecture decision. It does not set up an autonomous system. All workshop examples are synthetic. The companion guides show how to rehearse a small tool-using loop and review its failures without connecting real accounts.

Plain language: who chooses the next step?

A normal program follows rules you specify, such as calculating a total
A single model response transforms supplied material, such as turning notes into a draft
A workflow follows a planned sequence, possibly with model calls inside it
An agent chooses some next steps or tools while working toward a goal
A multi-agent system divides work among several model-driven roles and adds coordination between them

These are useful design distinctions, not a ladder of sophistication. Anthropic distinguishes predefined workflow paths from model-directed agent behavior and recommends starting with the simplest adequate approach. More flexibility can also bring additional latency and cost. Source: Building effective agents

A tool is a capability exposed to the system, such as reading a record or doing a calculation. Merely calling a tool does not make the whole design an agent: a fixed workflow can call tools too.

Five decision gates

Can you state a checkable outcome? Replace “manage the workshop” with “draft a kit-shortage recommendation supported by the supplied inventory and budget.” If success cannot be checked, clarify the task before automating it.
Are the steps known in advance? If the same inputs always lead through the same sequence, start with a program or workflow. Add explicit branches for known exceptions.
Is interpretation needed? Use a model for judgment or language only where it helps. Keep exact arithmetic, identifier checks, and permission checks outside the model when practical.
Does the next useful step depend on new evidence? A bounded agent may be useful when it must inspect a result and choose among several legitimate next steps. Test this hypothesis against the workflow baseline.
Can the consequences be contained? Name the available tools, allowed data, prohibited actions, spending/time limits, and person responsible for stopping the run. If these are unresolved, keep the exercise simulated or read-only.

If several options fit, choose the one that is easiest to inspect and reverse. “No AI needed” is a valid result.

A synthetic example: workshop supply planning

A fictional organizer needs one starter kit for each of 12 adult workshop participants. The synthetic stock record shows 9 usable kits. Extra kits cost USD 4.50 each, with a USD 2.00 order fee when at least one kit is needed. The proposed purchase must fit a USD 20.00 planning limit. The exercise produces a recommendation only; nothing is purchased or reserved.

The exact calculation is simple: 12 minus 9 leaves 3 kits; 3 × USD 4.50 + USD 2.00 = USD 15.50. This is not a real quote.

Best initial design: a fixed workflow. Read the event brief, read the stock record, calculate a shortage and proposed cost, then draft a recommendation. A model may help with the final explanation, but it is unnecessary for the arithmetic.

What would justify an agent experiment? Suppose incomplete requests can refer to several kit types, records can be missing, and an authorized assistant must choose whether to ask for clarification or inspect another allowed source. That adds a real next-step decision. It still does not justify purchasing, accessing unrelated data, or adding new tools during a run.

What would justify multiple agents? Only a measured coordination need. For this small task, separate “planner,” “researcher,” and “critic” agents would add more moving parts before demonstrating value. OpenAI's evaluation guidance recommends letting evaluations drive the move to multiple agents. Source: Evaluation best practices

Run a 30-minute design session

Write the outcome, 5 minutes. Name the intended user, input, output, and one example of an unacceptable result. Keep the task small enough for a person to finish manually.
Draw the simplest route, 5 minutes. Write the steps as ordinary sentences. Mark each step as rule, model judgment, tool read, or external change. Do not hide several external changes inside “finish.”
List three exceptions, 5 minutes. Try missing information, conflicting evidence, and a request outside the allowed scope. For each, decide whether a rule can handle it or a person must intervene.
Choose a baseline, 5 minutes. Use a manual procedure, deterministic script, single response, or fixed workflow. Record why it is sufficient or what it cannot handle.
Define one comparison, 5 minutes. If an agent seems useful, give it exactly the same task, data, permissions, and success checks as the baseline. Change the routing method, not every variable at once.
Set a decision date, 5 minutes. After the small test, choose keep, revise, or stop. A successful demonstration is permission to learn more, not automatic permission for production use.

Copy-ready directive: architecture decision

Help me choose the simplest adequate design for this task. Do not create an agent, connect accounts, run tools, or perform the task.

Task and intended user: [fill in]
Inputs and allowed data: [fill in]
Desired output: [fill in]
Known steps: [fill in]
Exceptions we have observed: [fill in; say unknown if none]
Consequences of a wrong result: [fill in]
Actions that must stay with a person: [fill in]

Compare only the options that plausibly fit: ordinary program/manual process, one model response, fixed workflow, bounded single agent, or multiple agents.

Return:
1. The recommended baseline and a brief reason
2. Which decisions are fixed rules and which require interpretation
3. One concrete example where a more complex option might help
4. Available tools and the minimum permission each would need
5. Missing information, without inventing answers
6. A small comparison test, including pass/fail checks, time/cost measures, and stop conditions
7. A keep/revise/stop decision rule

Distinguish facts, assumptions, and proposed design choices. Do not claim performance improvements without recorded comparative results.

Professional layer: completed decision record

Decision: Start with a read-only workflow for the synthetic workshop example.

Task contract: Given event ID DEMO-12 and item KIT-A, return required units, usable stock, shortage, estimated incremental cost, source record IDs, and a recommendation for human review.

Baseline route: Validate event ID → read brief → read stock → validate record freshness and fields → calculate in integer cents → produce structured result → human review.

Control owner: The person running the exercise. The model cannot grant itself permissions or override a failed check.

Boundary: Synthetic records only. No email, browser navigation, account connection, purchase, inventory update, or background execution.

Experiment hypothesis: Model-directed routing may reduce unnecessary reads on varied cases while preserving correct stops and evidence. This is a hypothesis, not a reported result.

Acceptance proposal: On the companion ten-case set, both designs must respect every permission boundary and all required stop cases. Compare task correctness and effort only after these gates pass. If the agent offers no useful improvement for the intended task, keep the workflow. These are local teaching criteria, not an industry certification.

Reason to revisit: A documented new class of request that the existing route cannot handle, not a desire to use more agents.

A small scorecard

Record the following separately for each design:

Outcome: Number of cases meeting all required checks / number attempted; list failures rather than hiding them in an average
Reliability: Cases with consistent passing outcomes across repeat runs / cases repeated
Safety: Unauthorized action attempts and successful unauthorized actions, reported separately; a blocked attempt is still useful evidence
Effort: Median elapsed time and human interventions per run
Cost: Measured API/tool charges if available; otherwise “not measured,” plus tool-call and message counts as workload indicators

A shorter answer or fewer tool calls is not automatically better. A correct stop on missing data can be a passing outcome, even though the original business task remains unfinished. Do not turn this tiny sample into a claim of production reliability or financial return.

Before moving on

You should be able to name the baseline, explain where adaptive decisions are needed, and state who may authorize consequential actions. If you cannot, refine the task contract. Next, use the bounded experiment guide to test a simulated loop, then the evaluation guide to examine both its answers and its tool requests.

Sources and scope

Sources were opened and reviewed on 2026-10-13. The decision session, workshop example, directive, and scorecard are original teaching materials informed by the principles below.

Anthropic: Building effective agents — workflow/agent distinction and simplicity-first design
OpenAI: Evaluation best practices — task-specific evaluation and evidence-based architecture choices

Product interfaces and availability change. This guide does not depend on a particular model, paid plan, legacy evaluation dashboard, or agent-building interface.

Public references & scope

These references support the concepts and product guidance discussed in the guide. They do not validate the invented examples or establish this method’s performance. Check the current source before relying on a product-specific step.

Anthropic: Building effective agentsSource reviewed October 13, 2026
OpenAI: Evaluation best practicesSource reviewed October 13, 2026

IIEN means infer intent and extrapolate needs. This site uses it as a user-directed working approach: state the likely goal, label assumptions, consider useful next steps and test a bounded choice. Inferred needs never grant permission for extra actions. It is not an OpenAI product, formal certification or claim that these exercises train or fine-tune the underlying model.

Plain text for manual copying

# Choose an agent, a workflow, or a simpler solution

Published and reviewed: 2026-10-13 · Version 1.0 · 15-minute read; 30-minute exercise

## Start here

Before building an agent, write down the result you need and the decisions that genuinely change from one request to another. A fixed sequence is often enough. An agent becomes worth testing when choosing the next step is part of the problem, and you can still check its work.

This guide produces a one-page architecture decision. It does not set up an autonomous system. All workshop examples are synthetic. The companion guides show how to rehearse a small tool-using loop and review its failures without connecting real accounts.

## Plain language: who chooses the next step?

- A normal program follows rules you specify, such as calculating a total
- A single model response transforms supplied material, such as turning notes into a draft
- A workflow follows a planned sequence, possibly with model calls inside it
- An agent chooses some next steps or tools while working toward a goal
- A multi-agent system divides work among several model-driven roles and adds coordination between them

These are useful design distinctions, not a ladder of sophistication. Anthropic distinguishes predefined workflow paths from model-directed agent behavior and recommends starting with the simplest adequate approach. More flexibility can also bring additional latency and cost. [Source: Building effective agents](https://www.anthropic.com/engineering/building-effective-agents)

A tool is a capability exposed to the system, such as reading a record or doing a calculation. Merely calling a tool does not make the whole design an agent: a fixed workflow can call tools too.

## Five decision gates

1. **Can you state a checkable outcome?** Replace “manage the workshop” with “draft a kit-shortage recommendation supported by the supplied inventory and budget.” If success cannot be checked, clarify the task before automating it.
2. **Are the steps known in advance?** If the same inputs always lead through the same sequence, start with a program or workflow. Add explicit branches for known exceptions.
3. **Is interpretation needed?** Use a model for judgment or language only where it helps. Keep exact arithmetic, identifier checks, and permission checks outside the model when practical.
4. **Does the next useful step depend on new evidence?** A bounded agent may be useful when it must inspect a result and choose among several legitimate next steps. Test this hypothesis against the workflow baseline.
5. **Can the consequences be contained?** Name the available tools, allowed data, prohibited actions, spending/time limits, and person responsible for stopping the run. If these are unresolved, keep the exercise simulated or read-only.

If several options fit, choose the one that is easiest to inspect and reverse. “No AI needed” is a valid result.

## A synthetic example: workshop supply planning

A fictional organizer needs one starter kit for each of 12 adult workshop participants. The synthetic stock record shows 9 usable kits. Extra kits cost USD 4.50 each, with a USD 2.00 order fee when at least one kit is needed. The proposed purchase must fit a USD 20.00 planning limit. The exercise produces a recommendation only; nothing is purchased or reserved.

The exact calculation is simple: 12 minus 9 leaves 3 kits; 3 × USD 4.50 + USD 2.00 = USD 15.50. This is not a real quote.

**Best initial design: a fixed workflow.** Read the event brief, read the stock record, calculate a shortage and proposed cost, then draft a recommendation. A model may help with the final explanation, but it is unnecessary for the arithmetic.

**What would justify an agent experiment?** Suppose incomplete requests can refer to several kit types, records can be missing, and an authorized assistant must choose whether to ask for clarification or inspect another allowed source. That adds a real next-step decision. It still does not justify purchasing, accessing unrelated data, or adding new tools during a run.

**What would justify multiple agents?** Only a measured coordination need. For this small task, separate “planner,” “researcher,” and “critic” agents would add more moving parts before demonstrating value. OpenAI's evaluation guidance recommends letting evaluations drive the move to multiple agents. [Source: Evaluation best practices](https://developers.openai.com/api/docs/guides/evaluation-best-practices)

## Run a 30-minute design session

1. **Write the outcome, 5 minutes.** Name the intended user, input, output, and one example of an unacceptable result. Keep the task small enough for a person to finish manually.
2. **Draw the simplest route, 5 minutes.** Write the steps as ordinary sentences. Mark each step as rule, model judgment, tool read, or external change. Do not hide several external changes inside “finish.”
3. **List three exceptions, 5 minutes.** Try missing information, conflicting evidence, and a request outside the allowed scope. For each, decide whether a rule can handle it or a person must intervene.
4. **Choose a baseline, 5 minutes.** Use a manual procedure, deterministic script, single response, or fixed workflow. Record why it is sufficient or what it cannot handle.
5. **Define one comparison, 5 minutes.** If an agent seems useful, give it exactly the same task, data, permissions, and success checks as the baseline. Change the routing method, not every variable at once.
6. **Set a decision date, 5 minutes.** After the small test, choose keep, revise, or stop. A successful demonstration is permission to learn more, not automatic permission for production use.

## Copy-ready directive: architecture decision

```text
Help me choose the simplest adequate design for this task. Do not create an agent, connect accounts, run tools, or perform the task.

Task and intended user: [fill in]
Inputs and allowed data: [fill in]
Desired output: [fill in]
Known steps: [fill in]
Exceptions we have observed: [fill in; say unknown if none]
Consequences of a wrong result: [fill in]
Actions that must stay with a person: [fill in]

Compare only the options that plausibly fit: ordinary program/manual process, one model response, fixed workflow, bounded single agent, or multiple agents.

Return:
1. The recommended baseline and a brief reason
2. Which decisions are fixed rules and which require interpretation
3. One concrete example where a more complex option might help
4. Available tools and the minimum permission each would need
5. Missing information, without inventing answers
6. A small comparison test, including pass/fail checks, time/cost measures, and stop conditions
7. A keep/revise/stop decision rule

Distinguish facts, assumptions, and proposed design choices. Do not claim performance improvements without recorded comparative results.
```

## Professional layer: completed decision record

**Decision:** Start with a read-only workflow for the synthetic workshop example.

**Task contract:** Given event ID DEMO-12 and item KIT-A, return required units, usable stock, shortage, estimated incremental cost, source record IDs, and a recommendation for human review.

**Baseline route:** Validate event ID → read brief → read stock → validate record freshness and fields → calculate in integer cents → produce structured result → human review.

**Control owner:** The person running the exercise. The model cannot grant itself permissions or override a failed check.

**Boundary:** Synthetic records only. No email, browser navigation, account connection, purchase, inventory update, or background execution.

**Experiment hypothesis:** Model-directed routing may reduce unnecessary reads on varied cases while preserving correct stops and evidence. This is a hypothesis, not a reported result.

**Acceptance proposal:** On the companion ten-case set, both designs must respect every permission boundary and all required stop cases. Compare task correctness and effort only after these gates pass. If the agent offers no useful improvement for the intended task, keep the workflow. These are local teaching criteria, not an industry certification.

**Reason to revisit:** A documented new class of request that the existing route cannot handle, not a desire to use more agents.

## A small scorecard

Record the following separately for each design:

- **Outcome:** Number of cases meeting all required checks / number attempted; list failures rather than hiding them in an average
- **Reliability:** Cases with consistent passing outcomes across repeat runs / cases repeated
- **Safety:** Unauthorized action attempts and successful unauthorized actions, reported separately; a blocked attempt is still useful evidence
- **Effort:** Median elapsed time and human interventions per run
- **Cost:** Measured API/tool charges if available; otherwise “not measured,” plus tool-call and message counts as workload indicators

A shorter answer or fewer tool calls is not automatically better. A correct stop on missing data can be a passing outcome, even though the original business task remains unfinished. Do not turn this tiny sample into a claim of production reliability or financial return.

## Before moving on

You should be able to name the baseline, explain where adaptive decisions are needed, and state who may authorize consequential actions. If you cannot, refine the task contract. Next, use the bounded experiment guide to test a simulated loop, then the evaluation guide to examine both its answers and its tool requests.

## Sources and scope

Sources were opened and reviewed on 2026-10-13. The decision session, workshop example, directive, and scorecard are original teaching materials informed by the principles below.

- [Anthropic: Building effective agents](https://www.anthropic.com/engineering/building-effective-agents) — workflow/agent distinction and simplicity-first design
- [OpenAI: Evaluation best practices](https://developers.openai.com/api/docs/guides/evaluation-best-practices) — task-specific evaluation and evidence-based architecture choices

Product interfaces and availability change. This guide does not depend on a particular model, paid plan, legacy evaluation dashboard, or agent-building interface.