Where AI agents help—and where they get in the way

The next step was not known until the source was read

During the research for this publication, a public project description led to a local source file. That file revealed a function name, which led to a persistence operation, which exposed a distinction worth explaining in the article. The next useful read depended on what the previous read showed. That is a task where adaptive tool use can help.

The same publication also contains deterministic jobs: compile a known catalog, count manuscript words, and render charts from recorded values. Those jobs have a fixed procedure. Giving an agent freedom to invent a new sequence every time would add decisions where repeatable execution is more useful.

This guide uses that contrast to decide where an AI agent belongs. It draws on the actual research and artifact preparation performed for TrendsWhat, plus the operator's inspected approval and outbox designs. It does not report an agent benchmark or claim that a particular tool configuration improved productivity. The examples outside those tasks are explicitly design scenarios.

Original TrendsWhat decision guide. The useful distinction is whether the workflow needs new decisions, not whether it contains several steps.

Define the job before defining the agent

An agent can be understood as a system that chooses actions using its current task and observations. That choice may include which source to inspect, which tool to use, or whether the task is complete. A fixed script can also have several steps and error branches, but it does not need an open-ended planner for every decision.

Start with the deliverable. “Find the implementation that commits an approved draft and explain its limits” creates a bounded investigation. “Explore the project and improve everything” leaves completion and scope unclear. The second request may cause more activity while making it harder to assess whether useful work was completed.

A good task description includes the starting evidence, allowed operations, expected artifact, and completion checks. These are not restrictions added for their own sake. They let the agent distinguish useful exploration from unrelated work and let the user understand what the resulting claim is based on.

Where adaptive work helped in this publication

The source-inspection case studies required following evidence across files. A service function showed one part of the behavior, while the repository explained the write boundary. A comment raised a question that could be resolved only by reading the executable expression. The investigation changed direction when the evidence warranted it.

That work benefits from an assistant that can maintain the question while selecting relevant reads. It still needs to distinguish observations from inferences. Finding a test file is not the same as running it, and reading a transaction wrapper is not a complete production validation. The article must preserve those boundaries even when the exploration feels coherent.

The useful output was not a transcript of every tool call. It was a source-backed explanation, a small set of inspection notes, and a diagram. An agent should organize its work around the artifact the reader needs, rather than treating a long action history as evidence of quality by itself.

Where a fixed procedure was better

Our manuscript compiler reads a catalog, loads the named manuscripts, checks their lengths and required evidence sections, verifies related references, and writes a generated data file. The chart renderer reads recorded experiment values and creates the corresponding figures. Those procedures are intended to behave consistently on the same inputs.

There is no benefit in asking an agent to guess the article count or hand-edit chart values after every change. A fixed script provides an inspectable rule and a clear failure when a manuscript falls outside the stated contract. It also reduces the chance that a polished final answer hides an incomplete artifact.

Use this distinction in your own workflow. Let adaptive reasoning discover what must be done when the path is uncertain. Once a repeated procedure is understood, capture it in ordinary code or a clear checklist. The agent can invoke the procedure and interpret failures without reimagining its mechanics each time.

More tools create more responsibility

A tool list is also a list of possible consequences. Reading a file differs from changing it. Preparing an email differs from sending it. Creating a draft differs from committing a record. An agent that can choose among tools needs to understand those differences and remain within the user's authorized task.

The operator's StockNote case study provides a concrete application boundary: an AI-structured expense draft follows a separate approval path before commitment. That pattern does not solve every agent problem, but it shows how software can make a consequential transition explicit rather than relying only on a conversational instruction.

For a tool workflow, provide the smallest set of capabilities needed for the task and make consequential operations reviewable. A research assistant usually needs source access, not permission to publish automatically. A drafting tool can produce a complete proposed action before the final operation is authorized. The appropriate boundary depends on the user's actual request and the system's design.

Tool responses are evidence with a scope

A tool returning success may establish that a command completed, not that the user's whole objective was achieved. A build can pass while a page has the wrong text. A page can return HTTP 200 while its image is missing. A source query can return a record without proving that a related user flow works.

Define the completion evidence at the same level as the task. For this publication, manuscript count alone is insufficient. The pages need the complete text, functioning images, sources, navigation, and appropriate metadata. That requires inspecting the rendered artifact as well as checking the data file.

An agent should summarize the evidence boundary clearly. “The local build passed” is useful. “Everything works” is usually too broad unless the relevant behaviors were actually exercised. The difference is not cautious phrasing for its own sake; it tells the user what they can rely on and what remains to be checked.

Handle ambiguous actions as state problems

When a tool times out, the agent may not know whether the operation happened. Repeating the call can be appropriate for some reads and dangerous for some writes. The next step should depend on the action's semantics and available state, not on a generic instinct to retry.

The MaybeTomorrow outbox case illustrates this issue in ordinary synchronization code. Pending intent, in-flight work, and acknowledged versions are distinct states. An old response must not erase a newer edit. An agent acting on persistent records needs comparable clarity about what it knows after an ambiguous response.

A useful tool interface can expose an operation identifier and a status check. A workflow can preserve a draft or idempotency key. The exact implementation varies, but the reasoning is stable: a failure to observe completion is not always proof that nothing occurred. Keep that uncertainty visible until authoritative state resolves it.

Copy this agent suitability worksheet

The worksheet is not a score that automatically authorizes deployment. It helps identify missing design work. A task can be suitable for agent assistance in discovery while still using a fixed script for execution and a person for the final decision.

Set a stopping rule that can be checked

An agent needs to know what counts as complete and when further exploration is unnecessary. For a bounded code investigation, completion may mean identifying the relevant path, checking its callers, documenting the evidence, and listing unverified runtime behavior. It does not mean reading every file in the repository.

For a creation task, the stopping rule should include the artifact and its acceptance checks. A report is not complete because a draft exists. A website is not complete because a development server started. The criteria should describe the user's intended result, including requirements that are easy to forget after the first successful output.

Also define what should happen when the task cannot be completed with available evidence. The agent should preserve the work already done, state the exact missing condition, and avoid inventing success. A temporary dependency wait differs from a genuine need for new user information; the response should reflect that difference.

Budget effort across the whole task

Tool calls, model reasoning, repeated checks, and human review all consume resources. A workflow that searches endlessly after sufficient evidence is gathered may become less useful. A workflow that stops at the first plausible answer may miss the key condition. The goal is enough investigation to support the required conclusion.

Use checkpoints tied to uncertainty. After identifying a likely source, inspect it. After changing a behavior, run the relevant check. Once a check passes, repeat it only when new changes or unresolved concerns justify another run. This keeps validation meaningful rather than turning activity into a substitute for progress.

This article does not provide measured cost or time savings for agent use. If those outcomes matter, record them in your own comparison, including reviewer effort and recovery from failed actions. A lower call count is not necessarily a better result if it leaves important requirements unverified.

Make handoffs carry decisions, not only summaries

A long task may cross sessions or involve several people. Preserve the objective, current artifacts, verified results, remaining requirements, and important limits. A summary that says “mostly done” is less useful than a checklist identifying which pages were rendered and which policies remain stale.

Keep references to authoritative files and results so the next worker can verify the state. Do not rely on an old summary when a current artifact is cheap to inspect. The summary should make inspection faster, not replace it with confidence in a previous statement.

For AI work, this is a transferable supervision skill. Ask for evidence that changes the next action. A useful progress update explains what was learned, what remains uncertain, and what check will resolve it. It does not need to narrate every routine operation.

Choose the smallest system that can finish the job

Adaptive agents are useful when the task genuinely requires decisions between steps. Fixed procedures are useful when the path is already known. Human judgment remains important where the task depends on responsibility, ambiguous evidence, or a consequential choice the system should not make on its own.

The publication work combines all three: adaptive source investigation, deterministic experiment and compilation scripts, and explicit limits on what the evidence proves. That combination is more informative than labeling every multi-step process an agent.

Before adding another tool or planning loop, ask which uncertainty it resolves. If you cannot name one, the simpler workflow may be easier to understand and verify. If the uncertainty is real, give the agent the evidence and boundaries needed to resolve it, then judge the completed artifact rather than the amount of activity along the way.

Sources, materials, and limits

• Research process: actual source-inspection workflow used for this publication.
• Approval boundary and outbox case: inspected project mechanisms for consequential state transitions.
• Reusable experiment package: deterministic procedure and evidence preservation.
• Original suitability worksheet and decision diagram. No agent product benchmark, productivity measurement, or claim of universal autonomy is reported.