The first agent you ship after a year of workflows feels like cheating. You hand the model a tool palette, write a goal in English, click run, and watch it reason its way to an answer that would have taken you three hours of node-wiring. Then you watch it do the same task again — and this time it spends $11.40 on Anthropic API credits, calls the Salesforce search endpoint 47 times, and ends in a loop where it keeps re-deciding whether to email the customer or update the CRM first. The bill for the third run lands at $36. Welcome to the central decision every agent builder makes whether they realize it or not: which steps does the model get to choose, and which steps do you hardcode? This is the decide-vs-predefine decision, and it is the difference between an agent that ships and an agent that quietly racks up token spend until someone in finance notices.

Why the Decision Exists at All

A workflow has zero decisions. Every node, every branch, every API call is pinned down by the builder at design time. The agent does what you told it, and only that. The good news: predictable, debuggable, cheap. The bad news: brittle. The moment a new ticket type arrives, a new customer segment appears, or a new compliance requirement lands, you ship a workflow change.

An agent has more than zero decisions. You hand it a set of tools — a Salesforce lookup, a Slack post, a Gmail send, an internal knowledge search — and the model picks which to call, in what order, with what arguments, until the goal is met or the iteration cap fires. The good news: handles cases you did not predict. The bad news: occasionally expensive, occasionally wrong, occasionally locked in a loop where it keeps picking the same wrong tool because the last tool call returned an error message it cannot interpret.

Between those two extremes sits the decide-vs-predefine spectrum. The skill is not picking one end. The skill is knowing which steps in a workflow benefit from the model's judgment and which steps must be pinned down — and the willingness to draw the line explicitly before shipping. Operators who get this wrong build either over-rigid workflows that need redeployment every Tuesday, or under-constrained agents that spiral into $300 days when a customer email arrives in an unexpected format.

An agent is not "a workflow with a brain." An agent is a workflow where you have explicitly granted the model decision authority over specific steps. Everything else is still hardcoded. The "explicitly" is doing all the work in that sentence.

The Framework: Five Questions Per Step

For every step in the workflow you're about to ship, ask five questions. The answers decide whether that step is a hardcoded node or a model-chosen action.

Question 1: Does the input shape vary?

If the input is always a JSON object with the same fields in the same order — say, a Stripe payment-failure webhook — the step is predefined. The model adds nothing. A code node, a Make module, an n8n function gets the job done with no token cost and no surprises. If the input is unstructured (customer email, RFP PDF, support ticket comment, a transcript) the model earns its keep. Parsing intent out of human-written text is what models are for; writing thirty regexes to handle the variations is what workflows are for.

The boundary: a Stripe webhook is predefined. A "customer wrote in with a refund question" is model-decided. A "customer wrote in with a refund question through one of seventeen channels each with slightly different metadata" is model-decided for the intent, predefined for the channel-specific dispatch.

Question 2: Is the next step a function of the previous step's content?

If yes, the model decides. If no — if the next step is the same regardless of what the previous step returned — the workflow predefines.

A lead-enrichment workflow that always calls Apollo, then Clay, then writes to HubSpot regardless of what Apollo returned has no model decisions. A lead-enrichment workflow that calls Apollo, and based on the firmographic profile decides whether to call ZoomInfo for additional data or skip ahead to scoring, has one model decision in the middle. The decision earns its keep because the alternative is hardcoding a fifteen-branch if tree that ages poorly the moment Apollo returns a field shape change.

Question 3: Is the cost of getting it wrong contained?

If the wrong tool call sends a misworded email to a single internal Slack channel, the model decides — the blast radius is small and the recovery cost is "post a correction." If the wrong tool call deletes a Salesforce record, charges a credit card, or fires a webhook to a customer-facing system, the workflow predefines and the model only gets to draft, not execute. The decide-vs-predefine question collapses to a blast-radius question for these steps. Levels 1 and 2 of this program drilled into blast radius for a reason: it is the load-bearing constraint in agent design.

Question 4: Does the team have an eval set for this decision?

Agents need evals more than workflows do because the failure modes are subtler. If your team has fifty real examples of "this is what a correct next-step decision looks like for this input" the model can be granted authority over that decision and you can measure when it drifts. If you do not have an eval set, predefining is safer. You can build the eval set retroactively from workflow logs and then promote the step to model-decided in the next iteration. Shipping a model-decided step with no eval is shipping in blind mode; you will not know it's broken until a stakeholder Slacks you at 11 p.m.

Question 5: Can you draw the iteration cap?

If the step is "the model loops calling tools until the goal is met," then the question is not whether to predefine — it is what number to put in the max-iterations parameter. We will come back to this. It is the single most important parameter in any agent's configuration.

The Max-Iteration Cap Is Everything

Every agent loop must terminate. The model does not know to terminate. The cost meter does not stop ticking just because the agent is "thinking." The max-iteration cap is the single parameter that decides whether your agent costs $0.12 per run or $36 per run on the same task.

A loop that fires forever is not theoretical. We have seen it three times in production agents shipped by operators new to the discipline:

• The Salesforce loop (March 2026). A lead-enrichment agent kept calling the Salesforce search tool because the search returned zero results and the model interpreted that as "search again with different parameters." 312 search calls over 11 minutes before the API rate limit finally killed the loop. Cost: $14.20 in one run on a workflow budgeted at $0.40.
• The Notion read-and-summarize loop (January 2026). An agent was supposed to read a Notion page, summarize it, and write the summary to a different Notion page. It read the source page, wrote the summary, then "verified" the summary by reading the destination page, then "re-verified" by reading it again, then "compared versions" by reading both, and so on. 47 reads before someone noticed the workflow's cost dashboard had a vertical line on it.
• The customer-email triage loop (April 2026). The agent kept asking itself "do I have enough information to draft a response yet?" — the kind of meta-cognition that reasoning models are prone to. Each iteration was an internal monologue, no tool call, just thinking. The thinking cost about $0.30 per iteration on Claude Sonnet 4.6. 92 iterations before max-tokens-per-run kicked in. $27.60 for one customer email.

The cap is the only structural defense. Set it explicitly, set it low, and tune it up only after the workflow demonstrably uses every iteration it gets. The default in Anthropic's Agent SDK is 10. LangChain defaults to 15. Both are reasonable starting points; both are far too high for many agent roles. A customer-email triage agent should usually be capped at 4 or 5. A research agent that needs to compose multiple searches and synthesize results might earn 12 or 15. A "drop everything in and let the model figure it out" agent gets capped at whatever number you can afford to lose on a single bad run.

Pick the max-iteration cap before you pick anything else. Pick it based on what you can afford to lose on a single run, not what the agent ideally needs. The agent will adapt down. Your finance team will not adapt up.

The cap is per-task, not per-day

Iteration caps live at the run level. They protect against a single bad run, not against a fleet of runs that each behaves normally but compounds into a four-figure bill by Wednesday. You need both. The max-iteration cap protects one run; a daily cost budget with an alert at 80% protects the fleet. Operators ship the first and forget the second. The second is what catches the long-tail failure where the agent does its job correctly but a misconfigured trigger fires it 4,800 times instead of 48.

Three Canonical Agent Shapes

The decide-vs-predefine spectrum collapses to three working shapes in 2026 production. Most operator-built agents are one of these three.

Shape one: the constrained-tool agent

The model picks which tool to call from a small palette (3-7 tools), and the workflow handles everything before and after. The model has no decision authority over input shape, output format, or where the result goes — only over the middle step of "which tool, with what arguments." This is the safest shape for first agents.

Example: an inbound email triage agent. Workflow extracts sender, subject, body, attachments. Model picks one of four tools: route_to_sales, route_to_support, route_to_billing, flag_for_human_review. Each tool takes a single argument (the email ID) and the workflow handles routing. Iteration cap: 1. The agent makes exactly one decision per email and is done. Cost per run: roughly $0.008 on Claude Haiku 4.5.

The constrained-tool agent is what most operators ship first. It's a workflow with a model in the middle making one categorical decision. It is forgiving, fast, cheap, and easy to debug. The model has decision authority; the blast radius is bounded.

Shape two: the bounded research agent

The model can call tools repeatedly, but only within a bounded research task. It has an iteration cap (typically 5-15), a tool palette (typically 5-12), and a goal stated in English. The workflow handles delivering the final result. The agent's job is to pick steps until the goal is met.

Example: an account-research agent that takes a company name and produces a "what should our sales rep know about this account" brief. The model can call search_company_news, read_company_homepage, search_internal_crm, search_linkedin, and summarize_findings. It loops until it calls summarize_findings or hits the iteration cap at 8. The workflow takes the summary and posts it to the sales rep's Slack. Cost per run: $0.20-$0.60 on Claude Sonnet 4.6.

The bounded research agent is shape two because it requires a clearer eval set, a tighter iteration cap, and more careful tool design than shape one. It is also where most of the value lives — research tasks are where models genuinely outperform branching workflows.

Shape three: the orchestrator agent

The model coordinates other agents, picks which sub-agent to invoke for which sub-task, and synthesizes the results. The orchestrator does not call tools directly; it delegates to specialized agents that each have their own bounded tool palette. This is the shape Anthropic ships in Claude Code, where the main agent delegates to subagents for searches, file edits, web fetches.

The orchestrator shape is the riskiest and most expensive, because the cost compounds (every sub-agent has its own iteration cap; one orchestrator call can fire ten sub-agents each running 8 iterations). Save it for tasks where the alternative is a 200-node workflow that no one wants to maintain. The orchestrator is power-user territory; it is also where the next chapter of this program goes deep.

When to Predefine: Five Cases the Model Should Not Touch

The model's decision authority should never extend to these five steps, regardless of how clever the agent gets:

Authentication and authorization

The model never decides which credentials to use, which scope to request, or which user to act-as. Predefined. Always. The agent has tools that already include the right credentials; the model picks tools, not identities. Most real-world agent breaches in 2025-2026 started with an agent that could pick its own scope and was prompt-injected into picking too much.

Financial transactions above a threshold

The model can draft a refund or a discount; the model never executes one above the human-approval threshold. Predefine the dispatch: drafts above $50 go to an approval card, drafts below $50 may auto-execute. The threshold is a number you pick, document, and defend in front of finance; the model has no opinion on it.

Customer-facing communication sent without review

The first sixty days of any new agent role, every customer-facing output goes through a human-in-the-loop review step. Predefined. The model drafts; a human approves. Once the eval set hits 95%+ accuracy on a 100-example set, you can promote specific high-confidence outputs to auto-execute. Not before.

Data-deletion operations

The model can identify what should be deleted. The model never actually deletes. Predefine a soft-delete pattern with a 14-day grace window; the model writes the soft-delete row, a workflow hard-deletes after the grace period if no one objects. The asymmetry between "deleted thing that should not have been" and "kept thing that should have been deleted" is enormous in operator pain.

Cross-system writes that span audit boundaries

An agent that writes to Salesforce and Zendesk and your billing system in one task crosses three audit boundaries. Each system's compliance team has different expectations about what triggered the write. Predefine which system gets written to in which order, with which fields. The model can decide whether to write at all; the model never decides where to write.

The Trace Is the Feature

An agent's trace — the chronological log of every decision the model made, every tool it called, every argument it passed — is the single most important artifact in agent development. Workflows can be debugged by re-running them; agents must be debugged by reading their traces. Operators who skip the trace habit end up with agents that work most of the time and remain mysterious when they do not.

The trace habit looks like this: every time a customer or stakeholder reports the agent did something weird, pull up the trace, read every step out loud, and explain it to the reporter. If you cannot explain a single step, you have a learning to make. If the model picked a tool you would not have picked, ask why. If the model passed an argument that surprised you, ask why. The "why" is in the model's reasoning tokens, which most agent SDKs (Anthropic, OpenAI, LangChain, LlamaIndex) expose by default in 2026.

The first ten times you read an agent trace, it will feel like reading someone else's brain. By the fiftieth, the patterns are obvious — the model loops here because the tool description was ambiguous, the model picks the wrong argument because the schema field is poorly named, the model hallucinates a tool that does not exist because the system prompt mentions a capability the agent does not actually have. Every one of these is a fix at the platform layer, not at the model layer. Reading traces is how you find them.

The Pre-Flight Checklist Before Shipping an Agent

Operators who ship reliable agents run this checklist. Eight items, none of them skippable:

1. Tool palette is documented. Each tool has a name, a one-sentence description, a JSON schema for arguments, and a single example of correct invocation. If you cannot describe a tool in one sentence, the tool is not crisp enough for the model.
2. Max-iteration cap is set and justified. The number is on the workflow's documentation page. The justification is "we measured the agent uses at most N iterations on 95% of test inputs, and 1.5N protects the long tail."
3. Per-run cost ceiling is enforced. Most SDKs support this directly (Anthropic's max_tokens_to_sample per-run); Make and n8n need a custom check at the start of each run that fails fast if the workflow exceeds a daily budget. Both are cheap to implement and catch the long-tail bill.
4. Daily cost budget alert is wired. Slack alert at 80% of the budget; pause the workflow at 100%. Anthropic, OpenAI, and most platforms expose cost dashboards that integrate with Slack via webhook.
5. Eval set has at least 50 real examples. Each example labeled with the correct outcome. Re-run the eval on every prompt change. If you do not have 50 real examples, the workflow predefines this step; do not promote to model-decided.
6. Three buttons exist. Roll back, pause, kill. From Chapter 2.7. Non-negotiable for an agent that touches production systems.
7. Trace export is enabled. Every run writes its full trace to a storage location you can query (S3, BigQuery, Snowflake, or a postgres table). Sampling rate: 100% for the first 30 days, then statistically sample if cost is a concern.
8. Rollback procedure is per-action-type. Same as Lesson 2.7.3. Email rollback is a correction send. Salesforce rollback is a restore from field history. Database rollback is a soft-delete restore. External webhook rollback is "pause and notify recipient."

Eight items, two hours of setup, zero tolerance for skipping any of them. Operators who ship the eight items have agents that survive a year in production. Operators who skip have agents that survive until the first Saturday cascade.

Real Numbers From Real Agents

Numbers from operator-built agents in production at companies in the 50-500 employee range, May 2026:

• Email triage agent. Claude Haiku 4.5, max-iter 2, palette of 4 routing tools, 12,400 emails/month. Average cost per email: $0.009. Total monthly cost: $111. Replaced an 18-node n8n workflow that had cost $34/month in Anthropic credits but $400/month in maintenance time.
• Account-brief agent. Claude Sonnet 4.6, max-iter 8, palette of 7 research tools, 220 briefs/month. Average cost per brief: $0.42. Total monthly cost: $93. Replaced a 90-minute manual research task; sales rep time saved estimated at 330 hours/month at $45/hour blended cost = $14,850/month.
• RFP-response drafter agent. Claude Sonnet 4.6, max-iter 12, palette of 9 tools, 40 RFPs/month. Average cost per RFP: $1.80. Total monthly cost: $72. Each RFP saves a solutions engineer roughly 3 hours; estimated value $13,200/month.
• The runaway loop case (March 2026, before fix). Same Salesforce-search loop described earlier. Max-iter was unset (defaulted to 25 in the SDK). 312 iterations on a single bad run. Single-run cost: $14.20 on Sonnet 4.6. Single-week cost before the loop was noticed: $1,140. The fix was setting max-iter to 6, which is what the original eval set had measured as sufficient. Total time to fix: 8 minutes.

The ratio that matters: a well-designed agent saves 10-100x its inference cost in human time. A poorly-designed agent costs 10-100x its budget. The decide-vs-predefine framework is what gets you the first ratio.

The Mental Shift From Workflow Builder to Agent Builder

Workflow builders think in flowcharts. Every box, every arrow, every branch has been considered. The mental model is "I am building the program; the model is one node inside it." Workflow builders are great operators because they have already learned the discipline of explicit handoffs, explicit failure paths, and explicit human-in-the-loop steps.

Agent builders think in contracts. The contract has three parts: the goal (in English), the tool palette (with schemas), and the iteration cap (with cost budget). Everything else is the model's job. The mental model is "I am setting up the playground; the model figures out how to win the game inside it." Agent builders are accountable for the playground design, not the play-by-play.

The shift is uncomfortable for operators who have spent years getting every node right. It feels like giving up control. It is, in a sense — but the control you give up is the control over which specific tool fires next. The control you keep is much more valuable: which tools exist at all, how they're described, what they return, and what the agent can never do without human approval. Operators who make this shift well are the ones who realize the playground design is the agent design. The model is the player; the playground is the product.

The next three lessons of this chapter unpack the implications. Lesson 2 addresses the trade-off that surprises every operator the first time: reasoning models are not strictly better than non-reasoning models for tool-using agents, and the February 2026 paper that named the trade-off changed the model-selection conversation. Lesson 3 walks you through building your first working agent loop in Lindy, Relevance AI, or n8n's LangChain integration. Lesson 4 is the next step beyond: fine-tuning a small model on your team's eval set to get frontier-model tool-call reliability at one-tenth the cost.

The first agent you ship is not the agent. It is the playground design. Set the max-iteration cap, draw the tool palette, document the eval set, wire the three buttons, then let the model play. The hardest part is not picking the model. The hardest part is deciding which steps you will not pre-decide.

Key Takeaways

• An agent is a workflow where you have explicitly granted the model decision authority over specific steps. Everything else is hardcoded. The word "explicitly" is doing all the work.
• For every step, ask five questions: Does input shape vary? Is the next step a function of the previous step's content? Is the cost of getting it wrong contained? Does the team have an eval set? Can you draw the iteration cap? Answers decide hardcoded vs model-chosen.
• The max-iteration cap is the single most important parameter in any agent's configuration. Set it explicitly, set it low (typically 1-12 depending on agent shape), tune up only after measuring. Anthropic SDK defaults to 10; LangChain defaults to 15; both are too high for many roles.
• Three real loop-forever failures cost $14.20, $11.40, $27.60 on single runs. Setting max-iter to the eval-measured ceiling+1 is the fix. Eight minutes of work each time.
• Iteration caps are per-run protection. You also need a daily cost budget alert at 80% and a hard cap at 100%. Per-run + per-day = both layers.
• Three canonical agent shapes: constrained-tool agent (model picks from 3-7 tools, iteration cap 1-3, cost per run cents), bounded research agent (5-12 tools, iteration cap 5-15, cost per run cents-to-dollar), orchestrator agent (delegates to sub-agents, costs compound, save for tasks where 200-node workflows would otherwise be needed).
• Five steps the model never decides: authentication/authorization (always predefined), financial transactions above threshold (predefine the dispatch), customer-facing communication for first 60 days (human-in-the-loop), data deletion (soft-delete pattern), cross-system writes that span audit boundaries.
• The trace is the feature. Every weird agent behavior gets debugged by reading the trace step-by-step out loud. Anthropic, OpenAI, LangChain, LlamaIndex all expose reasoning tokens in 2026.
• Pre-flight checklist before shipping: tool palette documented, max-iter set and justified, per-run cost ceiling, daily budget alert, eval set with 50+ real examples, three buttons (rollback/pause/kill), trace export enabled, rollback procedure per-action-type. Eight items, two hours, zero skipping.
• Real numbers: email triage agent at $0.009/email replacing $400/month of maintenance; account-brief agent at $0.42/brief saving $14,850/month of rep time; runaway loop case at $14.20/run before max-iter was set. The well-designed-to-poorly-designed cost delta is 100x.
• Workflow builders think in flowcharts; agent builders think in contracts. The contract: goal in English, tool palette with schemas, iteration cap with cost budget. The model picks the play; you design the playground. The playground design is the agent design.