Agentic engineering: when AI usage becomes a cost decision

The wake-up call for BDO

For ourselves at BDO, the shift to token-based billing was not a surprise. So we decided to act before it impacted our monthly billing. In May 2026, we used our April GitHub Copilot usage to model the new pricing: keeping our usage pattern unchanged, the monthly run rate could have reached around five times the subscription baseline, enough to show the old pattern would not scale under the new model. 

Our colleagues weren’t using GitHub Copilot irresponsibly. They were using it in a way that had always made sense: strong models, broad requests, long-running help, more work packed into fewer interactions. But the rules had changed, so the operating model had to change with them. 

The response was not to slow adoption

The easy reaction would have been to restrict usage. Instead, the goal was to help people use GitHub Copilot with more intent before the token-based model went live in June. Several tracks started in parallel: clearer model-selection guidance, user-level budgets, more reusable context, and practical agentic-engineering patterns that reduced unnecessary exploration and iteration. 

By the time the new pricing model launched, behaviour had already begun to change. 

Usage stayed high and instead of the projected several hundred percent above baseline, the added cost settled at a controlled 40% to 80%. The gain came from using AI more deliberately, not less. 

More careful does not mean less ambitious

The change is visible in how our colleagues describe their own usage. One colleague put it simply: "I use GitHub Copilot more carefully, but not less." Another described the new habit as balancing "quality, speed, and token cost." A third said that "model choice is part of my normal workflow." That’s what AI maturity looks like. 

The question isn’t whether GitHub Copilot can help, but which model, context, workflow and level of autonomy fit the task. A complex architectural refactor may justify a stronger model and broader context: a contained unit test rarely needs either. The aim is to only spend expensive tokens on work that needs them.

Agentic workflows need boundaries

Once agents start doing more under token-based pricing, every step in the process has to justify itself. Exploration consumes context. Sub-agents bring their own overhead. Failed attempts generate output that still counts. A session drifting beyond its scope keeps accumulating cost after the useful work has slowed down. 

A good agentic workflow starts with a clear objective, a bounded scope and relevant context. It uses sub-agents for specific tasks rather than by default. It builds in stopping criteria: someone still decides whether the work is good enough, whether the agent should continue, or whether the session has grown too broad to stay useful. 

We saw the risk of uncontrolled automation in a separate case, where a process got stuck and created a low-four-figure monthly overrun. The lesson here: anything able to keep running needs limits, monitoring and ownership.

Context is where quality and cost meet 

Model choice gets most of the attention, but context is just as important. Every time an agent has to rediscover the project, the organisation pays for knowledge it already has. It scans files, infers conventions, asks follow-up questions and sometimes makes assumptions that have to be corrected later. That costs tokens and produces worse results. 

Specification files, repository instructions and shared project context give the model a better starting point, so it can focus on the task instead of reconstructing the environment. The same goes for reusable prompts and agent configurations: captured once and improved over time, that knowledge compounds instead of being rebuilt by every developer, again and again. That structure is what agentic engineering is about. 

The real shift is organisational

Individual behaviour matters, but the bigger gains come when better behaviour becomes the default. Which model fits which task? When is a sub-agent worth using? What context should live in every repository? When should a session stop and restart with a narrower scope? Better to settle these once than leave every developer to work them out alone. 

Organisations that get this right will have clear working habits around when and how to use each capability. Agentic engineering builds exactly that: clearer context, better task boundaries, more deliberate model choice, reusable workflows and human review at the right moments. 

The business case is simple: get more production-ready work from the AI you already use. Token-based pricing made that case visible and cost is only one part of the story. The same practices improve consistency, quality and governance too, as teams work from shared context, follow repeatable workflows and review output against clearer expectations.  

One of our other articles covers just that: how agentic engineering moves AI-assisted development from individual productivity to a shared organisational capability.

Curious what this could look like in your organisation? 
BDO can help you find the right starting point.