You can now spot chat, and you can spot a connector hiding inside chat. The remaining trap is reaching for an agent when a dumber design would do. Agents are exciting — and the most expensive, slowest, hardest-to-debug option on the shelf.

This lesson gives you the simplest-one rule: fixed automation first, known workflow second, agent only where genuine choice within boundaries adds value.

Three designs, three levels of choice

Think of the three as a ladder of decision-making.

Automation: if X, then Y. One trigger, one fixed action, no choices. The path is fully known in advance. Example: every night at 2 a.m., copy the database to backup storage and log the result. Nothing to decide; the value is reliability. You build it with cron, a queue, or a scheduled function from Part VII — no model needed.

Workflow: a known multi-step path. Several steps in a fixed or branching order, with predictable handoffs. The route is mapped; conditions select among known branches. Example: a source-ingestion pipeline — fetch the approved feed, parse new items, deduplicate against the database, write records, queue anything unusual for review. Steps may retry or branch on error, but nobody invents a new step at runtime. Workflow tools, queues, and scripts handle this well; a model may assist inside one step (classify this item) without directing the whole run.

Agent: chooses the next action within boundaries. Given a goal, the system selects among approved tools and evidence paths, observes each result, and decides what to try next — including stopping or asking for review. Example: research triage over ten candidate sources where only some will pan out. The agent picks which source to inspect first, judges whether the evidence is sufficient, follows the promising lead, abandons the dead end, and records why. The path cannot be fully drawn in advance; that undecidability is the reason an agent exists.

automation:  trigger → fixed action → done
workflow:    trigger → step 1 → step 2 → branch → step N → done
agent:       goal → act → observe → decide (repeat) → stop or review

The test is counterfactual: could you have written down every step and branch before running? If yes, you have a workflow wearing an agent costume. If the next step genuinely depends on what the last observation revealed — and more than one continuation is legitimate — the agent may earn its place.

Backup vs ingestion vs triage

Make the ladder concrete with three nightly jobs.

• Nightly database backup (automation). Trigger: 2 a.m. Action: snapshot, verify checksum, log. There is no judgement to add. Putting a model in this loop only adds cost, latency, and a new way to fail. If someone proposes an "AI backup agent," ask what decision the model makes that a checksum cannot.
• Source ingestion pipeline (workflow). Trigger: new items in approved feeds. Steps: fetch, parse, dedupe, store, flag anomalies for review. The path is known; errors have known branches (retry fetch, quarantine malformed item). A model can help inside the "classify anomaly" step, but the pipeline — not the model — owns the order of operations and the state transitions.
• Research triage (possible agent). Goal: "from these ten leads, assemble the three best-supported findings with citations." No fixed order works, because lead three may invalidate lead seven, and a thin source may require a follow-up query the designer did not foresee. Here choice within boundaries — approved sources only, maximum five fetches, must cite, must stop with a gaps note — genuinely adds value a fixed pipeline cannot.

Notice the progression: the backup needs no model at all, the pipeline needs a model for at most one step, and only the triage needs a model choosing steps. Most "agent ideas" collapse into the first two once you list the actual decisions.

What autonomy charges you

Every step up the ladder raises four bills. Teach them as a bundle, because beginners consistently underprice all four.

1. Cost. A chat turn or fixed script costs one pass. A workflow costs its steps. An agent multiplies model calls by tool calls by retries — on the most expensive models. A triage agent inspecting ten sources can cost twenty to fifty times a single summary. Budgets and step caps (Class 30) exist because of this arithmetic. 2. Latency. Each loop iteration waits on a model call plus a tool response plus another decision. A backup finishes in seconds; an agent triage can run minutes — felt directly when a human waits in chat. 3. Debugging difficulty. Automations fail in one place with one log line. Workflows fail at a named step. Agents fail anywhere in a judgement chain: wrong tool, bad arguments, misread observation, loop repeated on a failing call. Without the run record from Lesson 29.1 — inputs, timestamps, outputs, stop reason — diagnosis is guesswork. 4. Need for review. Fixed outputs take fixed checks (checksum, schema). Agent outputs vary by construction, so review must be designed in: approval gates, auditable evidence packets, explicit stop-with-gaps instead of confident invention. The more the agent chooses, the more a human must be able to inspect and veto.

Keep this table near your designs:

The rule follows: start at the bottom and climb only when the cheaper level cannot express the job. If if-X-then-Y suffices, ship that. If a mapped path with branches suffices, ship that. Promote to agent only the step where runtime choice among approved options is the whole point.

Exercise: rewrite one "agent" idea as an automation

Take one idea you have called an agent. Write its goal, then force it through this simplification:

1. Express as much as possible as automation: which triggers and fixed actions cover 80% of the value? 2. Express the remainder as a workflow: what is the known path, and where are the branches? 3. Circle only what is left: which decision genuinely requires choosing among options based on an observation, and what are its boundaries (allowed tools, max steps, stop rule)?

Finish line: a half-page rewrite with three labeled sections — automation part, workflow part, agent remainder (or "no agent remainder") — plus the agent remainder's boundaries if one survives.

Verify: for anything kept as agent behavior, name one observation that would change the next step. If none exists, demote that part to workflow.

Common failure mode: keeping the agent "because it feels more future-proof." Future-proofing with autonomy buys present-day cost, latency, and incidents. Keep the fixed version; promote later when real runs show decisions the fixed path mishandles.

For background on the tool plumbing both workflows and agents share, see the Model Context Protocol introduction and the platform connector references from Lesson 29.2: ChatGPT apps, Claude MCP and connectors, and Gemini connected apps.

Check your understanding

1. A nightly backup, an ingestion pipeline, and a triage researcher each fail. How does the debugging session differ in each case? 2. Why can adding a model to a fixed automation make reliability worse rather than better? 3. An "agent" idea survives your rewrite with no remaining runtime choices. What do you ship instead, and why?

Next

You now carry the full Class 29 toolkit: chat answers while agents carry work forward, connectors extend chat without creating agents, and the simplest design that expresses the job wins. Class 30 puts the surviving agent ideas inside a real loop — think, act, observe, decide, stop — with budgets, timeouts, and exit ramps that keep autonomy inspectable.