AI agents have become the go-to tool for developers, taking on the task of investigation, debugging, code writing, refactoring, test writing and answering ad-hoc questions. After AI vendors hooked everyone on using AI agents, they have now increased their usage cost. This should prompt everyone using AI agents to take some effort into optimizing agent usage. Maybe your every-day search engine question, or task to reformat a markdown document, does not need to be run with the latest & greatest AI model there is?
A normal AI interaction might involve one prompt and one response. An agentic development session can involve dozens of model calls. The model reads context, reasons about the task, calls tools, reads the results and reasons again. If the same high-end model is used for every step, token usage can grow quickly.
For one developer, that may still be acceptable. Across several developers, multiple repositories and agents working throughout the day, the economics start to look very different. This does not need to be a problem.
A typical development task contains several different kinds of work.
Some parts require strong reasoning effort. Understanding an ambiguous requirement, deciding how a change should fit into an existing architecture, reviewing whether an implementation actually solves the original problem - these should be don with a high-performance model.
Other tasks - writing code, adding a test case, inspecting a module, running tests - once specifications are good enough, these lower-level tasks can be delegated to smaller models.
If your agentic workflow is that one agent does all, then you end up doing all the trivial tasks also with the premium model, prompting your costs to go up unnecessarily.
The question - or development task you then face is: how to rewrite your workflow so the expensive model handled the difficult decisions, while cheaper models handle the well-defined execution?
This is where an orchestrator-and-subagent pattern becomes useful.
Instead of giving one model a large objective and letting it work continuously, an orchestrator first breaks the objective into smaller tasks.
For example, rather than asking an agent to “implement this feature”, the orchestrator separates the work into understanding the affected components, identifying relevant tests, making a focused backend change, updating a frontend component and checking documentation.
Before those tasks are executed, they can be reviewed to ensure tasks are well-enough defined for the “smaller agents” and address the issue we are solving.
Poorly scoped tasks create unnecessary exploration, repeated model calls and large context windows. A well-defined subtask gives the next agent a much smaller problem to solve.
Using this workflow, the expensive model is no longer spending tokens searching through every file and performing every routine step. Its capability is reserved for the places where it adds the most value.
The higher-performance model can act as the planner and reviewer. It interprets the original task, helps decide how the work should be divided and checks whether the resulting plan makes sense. The cheaper models doing subtasks do not need to be as capable. They just need to execute a narrow task correctly.
When the pieces are finished, the results are brought back together and reviewed again with a higher-performance model. The pattern becomes:
PLAN → REVIEW TASKS → DELEGATE → EXECUTE (CHEAPLY) → REVIEW RESULTS
Rather than paying premium model rates for every step, the workflow pays for premium capability where judgement matters.
There is another cost advantage. Large agentic tasks often require large amounts of context. If using just one or few agents, they may need to understand the requirement, repository structure, earlier decisions, tool output and work already completed. Passing that growing context repeatedly to a frontier model is expensive, and often not necessary.
Subagents can work with much narrower contexts. One agent may only need three files and a test result. Another may only need a specific API definition. They consume less context but get the job done.
The orchestrator’s duty is to keep track of the larger objective while each worker receives only the information required for its particular job. That makes model selection and context size two separate levers for reducing cost. You can optimize specific workers quite well with this approach - as well as track individual task token spending.
There is of course a catch: Adding subagents adds model calls. If the tasks are split too aggressively, an orchestrator can create several agents where one or two would have been enough. Then you unnecessarily split the task and use both premium models as well as low-end models, when one call to a premium model would have got the job done.
That is why reporting skills become valuable. You need to capture model usage and cost at the session level. Instead of seeing only a monthly or daily AI invoice, you can see how the agentic development workflow behaved per session, enabling you to select the best models per subtask, and defining different workflows.
Once session-level costs are visible, developers can start improving the flow based on evidence. Perhaps repository discovery is consuming too many frontier-model tokens and should be moved to a cheaper subagent - or some agents are doing too many retries, or always rediscovering the same git flow.
The solutions to these are probably creating reusable skills, scripts that agents can use, documenting the existing solutions - tasks that look like old-school development.
After these changes, your engineering organization practices using agents starts to look more defined and CTOs like that you are able to also report cost usage. And tell that the usage is optimized accordingly.
There are anti-patterns in AI cost optimization. Enabling only the cheapest models for everything, or restricting usage because costs skyrocketed or not tracking usage at all.
The goal is not to minimize model cost at every individual step or to make developers report agent usage every day and justify the cost. AI agents have become the norm in developer tooling, and that needs to be supported with proper guardrails.
As agentic development grows, companies will need to treat model usage more like other engineering infrastructure.
Kinetive can help teams design these agent flows, build the supporting reporting and optimize them based on real usage rather than assumptions.