Use a script when you can specify the operations and the rules for choosing between them. Use a coding agent when useful next steps depend on interpreting what it discovers. Between those options, a fixed workflow with one bounded model step often gives you enough flexibility without handing over the whole process.
The decision also depends on the consequences of a mistake. An agent that proposes a local patch and an agent that changes customer records have different operating requirements, even if both can understand the task. Choose the amount of discretion and the authority to act separately.
This article offers a decision method and three worked scenarios. They are architectural examples, not a benchmark or a claim that one approach is universally cheaper.
Identify the decision you cannot write down yet
“Automate the release notes” describes an outcome. It does not tell you which part needs a model.
Collecting merged pull requests between two known revisions can follow explicit rules. Sorting entries by component can also be deterministic if the project already has reliable labels. Explaining a behavioral change in plain English may need interpretation. Deciding whether the change warrants a release is a separate decision again.
Those four steps need not share an implementation. A script can collect records, a model can draft summaries, a validator can reject entries without source references, and a maintainer can approve the final text.
The distinction used here follows the architectural distinction in Anthropic's Building effective agents: workflows use predefined paths, while agents choose their process and tool use dynamically. The article dates from December 2024 and now carries a warning that its tooling landscape has changed. Its conceptual distinction is useful; its product examples are not a current buying guide.
Before choosing an agent, write the unresolved decision as a sentence: “We cannot predict which caller must change until we inspect the failure.” If the sentence is instead “We have not written the ten known transformations yet,” a script may be the missing work.
Compare predictability, reversibility, and the cost of failure
The following matrix is a starting point for design review. It is a judgment framework, not a scored risk model.
| Task condition | Starting approach | What to verify |
|---|---|---|
| Known inputs and explicit transformation rules | Script | Input validation, output contract, and behavior on unexpected input |
| Mostly fixed process with one interpretation step | Workflow with a bounded model call | Structured output and a defined path for uncertainty |
| Investigation determines the next useful action | Agent in an isolated environment | Scope, stopping conditions, accepted changes, and truthful reporting |
| Irreversible effect or expensive recovery | Preparation separated from execution | Exact proposal, authority, current state, and post-action verification |
| No reliable way to judge the outcome | Human investigation before automation | Whether the success condition can be made observable |
Reversibility requires a practical recovery path. A local text file with a recorded baseline may be easy to restore. A message already delivered to customers cannot be unsent in the same sense. Deleting records is not safely reversible merely because a backup exists; restoration may affect other writes or take longer than the business can tolerate.
Likewise, a fixed script can be dangerous. Deterministic control flow means the program follows its rules; it does not mean the rules are correct, the input is trustworthy, or the external system will behave predictably.
Scenario one: update a known configuration field
Suppose 80 service manifests contain a field named logFormat, and the approved change is from plain to json. The manifests follow one documented schema. Unknown values must be reported without modification.
A suitable script would parse each manifest, check the schema and current value, create a proposed diff, and leave unfamiliar cases for review. It should not perform a text replacement across every file that happens to contain “plain.”
The input contract determines the safe scope:
- Only recognized service manifests are eligible.
- Only
logFormat: plainchanges. - Existing
jsonvalues stay unchanged. - Missing or unexpected values produce a report.
- Configuration validation runs against every proposed result.
An agent could help write or review this script. That does not mean a model needs to choose every update during routine execution. Once the transformation is understood, a repeatable program is easier to inspect for this particular job.
If investigation reveals three incompatible manifest formats, do not quietly generalize the replacement. Classify the formats and decide whether explicit adapters are enough. The discovery phase and the recurring execution phase may deserve different automation.
Scenario two: draft a changelog from merged work
Here the mechanical and interpretive parts are different. A collection step can record each pull request's identifier, title, labels, and diff reference. A model can propose a concise explanation of the user-visible change.
Give the model a bounded output: one entry, its supporting references, its proposed category, and an uncertainty flag. A validation step can check that references belong to the supplied input and that no required item disappears.
That validation cannot prove the explanation is accurate. A summary could cite the right pull request while describing the wrong behavior. Review should compare the proposed text with the underlying change, especially for compatibility, security, and migration claims.
Keep publication outside the drafting step. The same model call that writes a plausible sentence should not silently acquire authority to announce a release. If no user-visible change is supported, the workflow should permit “no entry needed” instead of forcing prose.
Scenario three: diagnose a repository regression
A report says a parser accepts negative limits after a refactor. You do not yet know whether the problem is in validation, conversion, or a caller that bypasses both.
An agent can inspect the relevant code, reproduce the behavior, form a hypothesis, make a patch, and use the test result to choose the next action. The route is discovered during execution, making this a more plausible use of an agent.
That discretion still needs boundaries. Provide the observable failure, supported input contract, relevant checks, and a stopping condition if the issue requires a public API change. Restrict the environment to synthetic data and the access needed for the investigation.
GitHub's task guidance for Copilot cloud agent emphasizes clear scope and acceptance criteria. Treat that as product-specific guidance supporting a general habit: describe the result you need without pretending you already know the cause.
The agent may conclude that it cannot reproduce the issue. That can be a useful outcome if it includes the attempted inputs, environment, and missing evidence. Repeatedly editing until something looks different is not an acceptable substitute.
Account for verification and maintenance
Compare the whole workflow, not just the time until the first output. Include setup, execution, review, correction, and keeping the automation working as the repository changes.
A script has maintenance costs when schemas or APIs change. An agent has operating costs when it explores unnecessary paths or produces changes that require substantial review. A bounded model step still needs examples, validation, and a policy for ambiguous cases.
You do not need a fabricated cost model to begin. Run a small, authorized pilot on representative work and record the same outcomes for each approach: accepted result, unwanted changes, human correction, elapsed time, and available usage data. Report missing measurements as missing. A fast failed run and a slower accepted change answer different questions.
Start with the smallest amount of discretion that can resolve the actual uncertainty. Expand it when observed failures show that a more flexible process would help, and keep checks and authority proportional to the effects the system can produce.
Research note: primary documentation reviewed October 28, 2026. The scenarios and matrix are design analysis; no agent-versus-script performance comparison was executed.
