Agentic AI: when does an agent actually help?

What is agentic AI?

In an agentic workflow, a model can choose among allowed next steps: retrieve information, use a tool, inspect an intermediate result, or hand work to a person. That differs from a simple model call following a fixed chain. More freedom to act also calls for clearer controls.

When is it the right tool?

An agent is most useful when the task takes several steps, information changes from case to case, and the result can be checked. If a rule, a search, or ordinary software solves the problem more predictably, start there. An agent should earn its extra complexity through better outcomes, not a more impressive demo.

• Is there a concrete outcome you can evaluate?
• Can tool access be limited to what the task requires?
• Can failures be detected, stopped, and recovered from?

When do subagents help?

Stronger models can often plan, use tools, and revise their work in one continuing loop. Anthropic points to this shift beginning with Opus 4.5. In several deployments, its team found better results when a main agent retained context and loaded instructions and tools only when needed. Handoffs to subagents can add latency and lose details. Their findings still need to be tested in each new system.

In Anthropic’s proposed design, the main agent plans the work and revises that plan as results arrive. A former specialist can become an instruction for how to work or a tool for reading data and taking an action. The instructions do not all have to occupy context at once. Cost, turn, and write limits still belong in the harness and tools, where the model cannot talk its way around them.

I would keep a subagent for independent parallel work or separate verification, when the main agent measurably suffers from context overload, or when conflicting instructions and tools are hard to manage in one loop. In other cases, clear instructions and tools in the main agent may be simpler. Compare both designs on the same tasks, against the same quality bar, including time and cost.

Give the agent the right context

In July 2026, Anthropic reported removing more than 80% of Claude Code’s system prompt for its Claude 5 models without a measurable loss on its coding evaluations. Rules and examples that helped older models could constrain newer ones. That does not mean a shorter prompt is always better. Each instruction needs a purpose, and a model upgrade calls for testing the whole workflow again.

I would keep the core instructions short, make project-specific pitfalls easy to find, and let tools surface relevant information when it is needed. That is a useful direction for ctx too: show the code relationships a task calls for instead of loading a large graph into context at the start.

Measure and improve with MLOps

Choose a recurring task and measure how it is done without an agent. Then give the agent the tools it needs and test it on the same cases. In my ctx experiments on 36 coding tasks, the same model solved 28% with my first harness and 51% with pi without any extension. The way an agent works can matter more than one additional tool.

MLOps offers a useful discipline here. Version the model, prompt, tools, and harness together. Record inputs, tool calls, outcomes, time, and cost. Maintain a small set of known cases and rerun it whenever something changes. Then review real runs: which tasks fail, what do people have to correct, and which new failures should become tests? This shows whether a new model, a subagent, or a revised instruction improves the whole workflow.

Use those tests to stop changes that make results worse, and keep human approval for actions that are hard to reverse. Feedback then becomes part of the system rather than a review performed only after something breaks.

Anthropic also emphasizes that evaluation cases should resemble real work. Keep some cases held out while tuning prompts and tools. If scores rise on the cases you tune against but stay flat on the held-out cases, you may be fitting the test rather than improving the work. Check that the grader itself makes sound judgments too; otherwise you are optimizing the wrong measure.

Example: an agent in a codebase

A coding agent needs to find the right files, understand what already exists, make the change, and show that it works. I built ctx to give an agent a queryable model of the codebase when it struggles to find those connections itself. The original idea was especially useful for less capable agents: help them navigate without reading large amounts of code or rebuilding something that already exists.

Opus 4.6 is an example of an earlier model generation on which I would want to test whether that help is needed. I have not tested ctx with Opus 4.6 itself; my reported agent runs mostly used gpt-oss-20b. In those runs, a filename sometimes worked as well as a graph, and pi without ctx found the right file almost as quickly. That does not make the graph useless, but ctx did not produce a measurable improvement on those tasks.

With newer models, the question is more specific: can ctx help when filenames do not reveal where a change belongs, when a change spans a large repository, or when the agent might miss existing code it should reuse? A clear map of calls and dependencies could help, but that remains to be demonstrated. I want to compare the same tasks with and without ctx, measuring solved tasks, time, cost, and the work left for a reviewer. More context matters only if it improves those outcomes.

When the agent can change code

In October 2026, Anthropic’s Claude Code team described how it reviews code when agents make more changes than people can read line by line. The agent first runs checks and shows the results. Automated code and security review, ordinary CI checks, and human approval where the change carries more risk follow. The agent saying it is done is not verification.

They do not measure only how quickly a change is approved. They also track reverts and incidents, so time saved in review does not simply become time spent fixing failures later. For another team, I would start smaller: have the agent show test results and the change’s risks, require review for sensitive areas, and track failures after release.