Your Agent Instructions Are Tech Debt. The Difference Is You Now Get a Bill Every Month.

The industry has spent a year treating context engineering as a quality problem. Get the right context in, get better output out.

Token billing made it a finance problem too. Every sloppy line in every instruction file is now a recurring charge, billed per turn, per engineer, per day. You pay it again tomorrow whether or not anyone opens the file.

That last part is what makes it tech debt rather than a tuning exercise. Ordinary tech debt sits quietly until something breaks. This kind shows up on an invoice every month, which is roughly what we predicted would define 2026.

Compression will not fix it. Shrink a bad instruction file, and you have made the wrong output cheaper to produce. You still get the wrong output.

I got a good line out of Sergio Sisternes about four minutes into recording Stacked Sessions, and it took me until the edit to realize it was the whole episode.

He was describing a client with a specific Jira workflow. Create the issue in this state, put the description here, move it to ready for review there. Normal enterprise process, the kind every organization has and almost nobody has written down.

Point an agent at that process without telling it the steps, and the agent tries to work them out on its own.

"The agent won't follow that every time. We would try to figure out what it needs to do, burning tokens, and most probably nine out of ten times won't get it right, because it's guessing every time."

Read that as a cost statement. The agent spends tokens guessing, gets it wrong, a human catches it in review, and the agent spends tokens again on the rework. You pay twice for knowledge your organization never wrote down once.

Sergio heads up Microsoft Azure for the UK and Ireland at EPAM, out of London. He's an engineer and architect by trade; he contributes to APM, Microsoft's open-source agent package manager, and he spends his days on the technical foundations an organization needs before agentic development works at scale. He also has a clear view of where the money is going.

The token cost arithmetic nobody runs

GitHub moved from premium requests to usage-based billing on June 1, calculated on input, output, and cached tokens at each model's API rates. Anthropic bills enterprise subscriptions on tokens. Microsoft is heading the same way. Sergio is blunt about who was winning under the old model.

"Pay four pence for a premium request and I consume two billion tokens. Obviously for us it was a very good business, but it wasn't for Microsoft. We were using basically a billing model that was designed for five years ago."

The numbers are heading somewhere uncomfortable. Gartner predicts that by 2028, AI coding costs will surpass the average developer's salary as token consumption climbs and vendors move from seat-based to consumption-based licensing. Nitish Tyagi, the Gartner analyst on that research, adds the part that should worry engineering leaders: "Token discipline will not emerge through developer choice alone, as developers tend to optimize for speed and convenience over cost efficiency." Nobody is going to trim an instruction file on their own initiative. It has to become somebody's job.

The mechanic that makes context bloat expensive is worth stating precisely, because plenty of people are hand-waving it. Every token in your context window gets billed again on every turn the model takes.

"In an interaction you can have ten, fifteen turns. Every single time that you are in a turn, you are getting billed for every single token that you've put into the context that's coming from agents, skills, instructions, MCP servers."

Cached input is cheaper. It is not free, and the cache expires, so every fresh session pays to write that file back in at a premium before it spends all day paying to read it.

So a 4,000 token skill file that should have been 800 tokens reads like a 3,200 token mistake. The real figure is 3,200 tokens, times fifteen turns, times every interaction that engineer runs today, times every engineer with that file loaded, times every working day this year. Discount the read side to cache rates if you want to be generous. The shape of the number doesn't change, and neither does the fact that nobody has ever reviewed the file.

Sergio's version.

"We are creating massive skill and instruction files without any consideration, any optimization. Times engineers, times skills, times days, times number of days in a year. And there's a lot of wasted money going into unoptimized agent skill instruction prompts."

Run that against your own headcount. I did it on a napkin during the recording and stopped, because the number was embarrassing for a category of artifact that has never once been through code review.

That's the part that should bother you. We review code. Infrastructure changes go through a pull request. Somebody always has an opinion about a stray database query. Meanwhile the instruction file that gets injected into every agent turn across the entire engineering organization was written in one sitting by whoever needed it that afternoon, pasted from a blog post, and never opened again.

Context compression is the wrong instinct

The tempting response is to shrink everything. Sergio sees teams reaching for tools and tricks to pull context down, and he doubts that's where the real gain sits.

"The best optimization that you can do is really think and apply the design best practices that you should be applying to your agent packages, and make sure the team is aware of those best practices."

What he describes instead is the software playbook, applied to files we have been treating as documents. None of it is novel, which is exactly why it works.

Start by writing down the knowledge that only lives in people's heads. His first and biggest point. Organizations run on process that transfers by one person teaching another, becomes "the way things are done here," and never gets documented. The moment you need a skill file for an agent, you either have that process written down or you are doing a live brain dump into a prompt and hoping. The hoping is the part that costs money.

Then build small modules and compose them, instead of one file that does everything. A skill that knows your Jira flow. A skill that knows your front end patterns. Validate each one on its own, then combine them through dependency trees. When a small module is wrong you can see which one; when a 4,000 line instruction file is wrong, finding the bad paragraph is its own project.

Put them in source control and run them through CI. Release notes, builds, validation, the same treatment as anything else you ship. His framing is that agent definitions are software, so ship them like software. Some teams have started treating spec and skill authoring as its own craft. Most have not.

Nothing on that list would surprise anyone who read Continuous Delivery fifteen years ago. That's the uncomfortable part. We solved software distribution decades ago with packages and versions, then re-created the problem by moving instruction files around with copy and paste, and now we pay interest on it by the token. DORA's AI ROI data keeps landing in the same place, which is that returns come from the engineering practices around the tools rather than from the tools themselves.

One measurement note, because it follows directly. If token spend tracks undocumented knowledge, the number to watch is rework rather than volume. Sergio's read on heavy PR intervention is that "something is not right in the agent's instructions, because we are wasting tokens in rework and we are wasting human hours." Rework is where context quality becomes visible. The same pattern shows up in survey data. Half of product and engineering teams say ticket quality is causing drag, and a bad ticket is the human version of the same problem. Work gets handed off without enough context to act on it, so somebody does it twice. Lines of code tells you nothing about either.

What agent instruction discipline can't fix by itself

Sergio's answer is discipline: modular packages, versioning, CI, and real upfront effort on requirements. Requirements matter most because every downstream token gets spent acting on them. That's the case for spec-driven development stated in cost terms rather than process terms.

There is still one thing a well-packaged skill file cannot do, which is know whether what it says is still true. A skill file knows whatever somebody typed into it, on the day they typed it. That beats nothing by a wide margin. It is also a snapshot, and snapshots drift away from the codebase, from what customers are asking for, and from what the team actually shipped last sprint. Nobody gets a notification when a skill file goes stale. So you keep paying tokens, on every turn, to load a confident description of software that has since changed.

Allstacks Product Studio comes at it from the other end. Product definitions get built out of the real codebase, real customer voice, and real delivery history, with adversarial reviewers stress-testing the spec before engineering sees it. Because it stays wired to those systems, the context updates when they do, so what an agent loads describes the software you have now.

Sergio's work makes sure agents follow your process. Building specs out of live systems makes sure the process is pointed at something worth doing. Both matter for the same reason. As AI speeds up output, teams build the wrong things faster, because no single person carries the whole picture anymore. If you skip both, the token bill is where you find out.

What I'd do Monday morning to cut token waste

Read your five most loaded instruction files the way you'd read a pull request. You are looking for tokens that earn nothing. If nobody on the team can say why a paragraph is in there, that paragraph is rent you pay on every turn.

Find your most expensive undocumented process. The workflow everybody knows, nobody wrote down, and agents currently guess at. Write it down once, properly. That's a cost reduction and a quality improvement in the same edit, which makes it the easiest item here to get approved.

Start measuring rework instead of volume. Count how often a human sends agent output back during review. That number is your context quality score, and it tracks token waste better than anything on your dashboard today.

FAQ

What is context bloat?

Context bloat is the accumulation of tokens in an agent's instruction files, skill files, and MCP server definitions that do no useful work. Because the full context window is re-billed on every turn of an interaction, bloat behaves as a recurring operating cost rather than a one-time inefficiency in a single prompt.

Why are bloated agent instruction files expensive?

Every token in the context window is billed on every turn, and a single interaction can run ten to fifteen turns. Context arrives from agents, skills, instructions, and MCP servers, and cached input is cheaper but not free. Waste multiplies by turns, by engineers loading the file, and by working days, so an oversized instruction file is a recurring charge rather than a one-time inefficiency.

Will AI coding costs really exceed developer salaries?

Gartner predicts that by 2028 AI coding costs will surpass the average developer's salary, driven by rising token consumption and the shift from seat-based to consumption-based licensing. GitHub moved Copilot to usage-based billing on June 1, calculated on input, output, and cached tokens at each model's API rates, and other vendors are following.

Is context compression the best way to reduce AI token spend?

Compression helps at the margin but treats the symptom. Larger gains come from applying software design practices to agent definitions: small validated modules composed through dependencies, versioning and source control, CI validation, and documenting the implicit process knowledge agents currently guess at. Guessing burns tokens and produces work that has to be redone, which costs tokens twice plus human review time.

What should leaders measure instead of AI code volume?

Rework rate, meaning how often humans send agent output back during review, is the clearest signal that instructions and specs are underspecified. Pair it with lead and cycle time, standards adherence and defect introduction, and deployment velocity from ready code to production. Lines of code and pull requests accepted are easy to capture and measure activity rather than value.

Listen to the full episode of Stacked Sessions with Sergio Sisternes. You can find his writing at sesispla.net and reach him on LinkedIn.

Allstacks Product Studio is the workspace where product and engineering define, refine, and share specs built out of the real codebase, customer voice, and delivery history, so the context your agents run on is worth what you're paying to load it. Sign up for free

‍