Agents vs. Scripts: Choose the Simplest Reliable System

Run the supplied return router, change one input, and choose where a model would help. The core task uses Node and fictional business rules; it makes no API request and cannot issue a refund.

Use a script for known rules, a model-assisted workflow for a bounded interpretation step, and an agent when choosing the next tool/step is itself part of the problem. Each added degree of autonomy creates more behavior to test and control.

Level 1: deterministic script

Inputs follow a known schema, rules are explicit, and the same input should take the same path. Examples include renaming files, validating CSV columns, calculating invoice totals, sending a reminder at a fixed time, or calling an API after a form submission. Ordinary code gives you exact conditions, straightforward tests, and predictable cost.

Level 2: model-assisted workflow

The sequence remains controlled by code, but a model performs one bounded judgement: classify a support message, extract fields from a receipt, summarize a document, or draft a response. The model returns a structured result; code validates it and chooses the next step. This covers a large share of useful business AI without an open-ended agent loop.

Level 3: bounded agent

The application gives the model a defined goal and a small tool set. The model may decide which tool to call next, inspect the result, and continue until a stop condition or approval point. This is justified when the next correct step cannot be fully known in advance—for example, investigating a support incident across a knowledge base, order system, and status service. Even here, permissions, budgets, maximum steps, and side effects remain controlled by application code.

OpenAI's current Agents guide makes the ownership choice explicit: use the Responses API when your application should own the loop, and the Agents SDK when you want the SDK to manage recurring tool calls, handoffs, sessions, tracing, guardrails, or resumable approvals. That is an implementation choice after you establish that an agent is necessary.

Can ordinary code express the requirement? Keep it deterministic. Does one fixed step need language interpretation? Add a bounded model step and validate its result. Does an investigation need to adapt its tool sequence to findings? Consider a bounded agent only after defining tools, permissions, maximum steps, elapsed/cost limits, and escalation.

Do not choose an architecture from its label. Compare the observable task: a script can validate an order age without a model, while a free-text complaint may need interpretation.

A fictional seller receives a return form with order ID, delivery date, reason, requested remedy, and optional message. The first prototype is often pitched as a “returns agent.” Break the job apart:

• Validate required fields: deterministic code.
• Check whether the order exists: deterministic API call.
• Calculate days since delivery: deterministic code.
• Look up the applicable policy: deterministic retrieval with version filters.
• Classify an unstructured customer explanation: bounded model call.
• Decide whether the case is automatically eligible: deterministic rules.
• Draft a courteous reply: bounded model call using verified facts.
• Approve a refund above a threshold: human decision.

There is no reason for an agent to invent this sequence. A controlled workflow is easier to test and safer around money.

Here is a minimal runnable JavaScript version of the deterministic spine:

function routeReturn({ deliveredAt, reason, amountPkr, orderFound }) {
  const allowedReasons = new Set(["damaged", "wrong_item", "missing_parts", "changed_mind", "other"]);

  if (typeof orderFound !== "boolean") {
    return { state: "ESCALATE", reason: "INVALID_ORDER_STATUS" };
  }
  if (!orderFound) return { state: "ESCALATE", reason: "ORDER_NOT_FOUND" };
  if (!allowedReasons.has(reason)) {
    return { state: "ESCALATE", reason: "INVALID_RETURN_REASON" };
  }
  if (!Number.isFinite(amountPkr) || amountPkr < 0) {
    return { state: "ESCALATE", reason: "INVALID_AMOUNT" };
  }

  const now = Date.parse("2026-10-05T12:00:00.000Z"); // fixed evaluation time
  const delivered = typeof deliveredAt === "string" ? Date.parse(deliveredAt) : NaN;
  if (!Number.isFinite(delivered) || new Date(delivered).toISOString() !== deliveredAt || delivered > now) {
    return { state: "ESCALATE", reason: "INVALID_DELIVERY_DATE" };
  }
  if (now - delivered > 14 * 86_400_000) return { state: "REVIEW", reason: "OUTSIDE_POLICY_WINDOW" };
  if (reason === "changed_mind") return { state: "REVIEW", reason: "POLICY_CHECK" };
  if (reason === "other") return { state: "REVIEW", reason: "UNCLASSIFIED_REASON" };
  if (amountPkr > 20_000) return { state: "APPROVAL", reason: "HIGH_VALUE" };
  return { state: "ELIGIBLE", reason: "RULES_PASSED" };
}

console.log(routeReturn({
  deliveredAt: "2026-09-30T12:00:00.000Z",
  reason: "damaged",
  amountPkr: 7_500,
  orderFound: true,
}));

The thresholds here are fictional for the lab: the window is at most fourteen elapsed 24-hour periods, and timestamps use the exact UTC ISO form shown. They are not marketplace rules; a real seller must encode its approved current policy. A model can classify a free-text reason into a fixed enum, but the code should validate that enum and handle uncertainty. It should not be allowed to call issueRefund merely because the customer's message sounds convincing.

When might an agent become justified? Perhaps an exception investigator must look up shipment scans, ask a courier-status tool, retrieve a policy clause, identify contradictory records, and assemble an evidence packet. Even then, let the agent investigate, not transfer money. Give read-only tools by default and place a human approval gate before the side effect.

Tools should do one understandable job, accept a strict schema, return structured results, and enforce permissions internally. Prefer get_order_status(order_id) over run_sql(query). Prefer draft_refund_case(...) over manage_customer(...). Tool names and descriptions help the model choose, but authentication and authorization must live in code.

Separate read tools from write tools. Log every call. Set timeouts. Return typed errors such as NOT_FOUND, TEMPORARY_FAILURE, and FORBIDDEN. Define whether a call is safe to retry. An agent cannot compensate for ambiguous tool contracts.