What is prompt bloat in an AI agent?

Prompt bloat is text an agent reads on every single call that no longer earns its place. It comes in two forms. The first is repetition: the same rule written twice because someone re-added it under stress, or a tool list typed into the prompt in prose when the framework already sends the tool schemas. The second is staleness: facts that were true when the prompt was written and are not now, like a product name that has since been retired, or an entire agent whose job has ended. Both cost tokens on every call and neither adds any capability.

Should you list an agent's tools in its system prompt?

Usually not. Most agent frameworks already send each tool's name, description and input schema to the model separately, so a second copy written in prose inside the system prompt is duplication. Worse, the prose copy drifts: you add a tool and forget to update the prose, so the model now has a hand-written list that under-describes what it can actually do. Delete the prose list and let the schemas be the single source of truth. In our own audit this alone removed a stale list that was missing two real tools.

Does trimming an agent's prompt improve its accuracy?

It can, but do not assume it. The public result that inspired this work reported a large eval jump after cutting a prompt and its tool count, but that was their measurement on their task. When we trimmed our own agent we measured only what we could honestly measure: the prompt got 13 percent shorter, about 326 tokens saved on every call, with every hard rule verified still present. We did not re-run an accuracy benchmark, so we claim no accuracy change. Cut for cost and clarity, keep a backup, and only claim the numbers you actually measured.

We Put Our Agents On a Prompt Diet, Workloft Research Note №63

§1The claim that started it

A short post did the rounds this week: an engineer took an agent that ran on a 400-line system prompt with a dozen tools bolted on, cut the prompt to about 15 lines and the tools to 3, and the eval score went up, not down. The instinct is to file this under "clever team, specific task, does not apply to me." That is the wrong instinct. The claim underneath it is general, and it is uncomfortable: most agent prompts are carrying weight that does nothing, and the people who wrote them cannot see it any more.

We build and run a small fleet of agents. So rather than admire the post and move on, we did the boring thing and read our own prompts against it, file by file, asking one question of every line: is this earning its place on every single call, or is it just here? Here is what we found, and what we cut.

§2A prompt hides two kinds of fat

Before the specifics, the frame we ended up with, because it is the reusable part. An agent's system prompt is the text the model reads before every reply. It does not get skimmed. It is paid for, in tokens and in attention, on call one and on call ten thousand. And it rots in two distinct ways.

The first is repetition. The same rule, stated twice, because someone hit a failure, panicked, and added the instruction again a few paragraphs down without checking it was already there. Or a list of the agent's own tools, hand-typed into the prompt in prose, when the framework is already sending the model a full schema for each tool. This is fat you can measure with a ruler. It makes the prompt longer and adds nothing.

The second is staleness. Facts that were true the day the prompt was written and are not true now. A product that got renamed. A tool that got removed. A workflow that changed. Worst of all, an agent whose entire job has ended. Staleness does not always make the prompt longer. It makes it wrong, quietly, on every call, and wrong is more expensive than long.

One of our agents had the first problem. The next one had the second. Neither looked bloated from the outside.

§3Agent one: it was arguing with itself

The first agent we read was a day-job assistant with 13 tools and a 76-line system prompt. A textbook version of the shape from the post. Two findings, both boring, both real.

It stated its single most important behavioural rule twice. The rule was "if you tell the user you are going to build something, actually call the tool in the same turn, do not just promise." Vital rule. It appeared once, in full, with examples, and then again two paragraphs later, reworded, saying the same thing. Both had been added on the same day, months apart in the file, by someone (us) firefighting the same bug and not noticing it was already handled. We merged them back into one.

Then it re-listed its own tools in prose:

# in the system prompt, by hand:
Available tools:
- web_search  - current web info
- larry_run   - dispatch a browser research task
- companies_house_search - UK company checks
- ...and so on

The model was already receiving all 13 tools as proper schemas, with names, descriptions and input formats. This prose copy was a second, worse version of information the model already had. And it had done exactly what hand-maintained copies always do: it had drifted. The prose list was missing two tools that had been added later. So the agent was reading a hand-typed summary that under-sold its own abilities. We deleted the list and left one line pointing at the schemas as the source of truth.

The result, measured honestly:

before:  9,701 chars   76 lines
after:   8,397 chars   68 lines
cut:     13.4%   (~326 tokens saved on every call)

We then checked, mechanically, that every hard rule still appeared in the file exactly once. It did. Nothing the agent could do changed. It just stopped repeating itself.

§4Then the job ended, so we deleted the whole thing

Here is the part that reframed the exercise. Days after that trim, the reason the agent existed went away. The specific task it was built for stopped being a task we needed done. And a 13 percent prompt saving on an agent you no longer need is a rounding error on the real waste, which is the agent itself.

So we retired it. Stopped its service, archived the whole directory to a backup we can restore in one command, and removed it. The ultimate prompt diet is not a shorter prompt. It is noticing that the job is done and deleting the agent whole. Most teams never do this. Agents accumulate like cron jobs: easy to add, socially awkward to kill, still burning tokens and attention long after anyone remembers why. If you audit prompts and never audit whether the agent should exist, you are tidying a room you should be leaving.

§5Agent two: sometimes the prompt is already lean

The temptation, once you have found fat in one place, is to assume it is everywhere and start cutting. So the second agent matters more than the first. It is our scoring agent: a high-volume, low-cost worker that reads a piece of text and returns a structured score, across about a dozen different scoring tasks.

We read all of its prompts expecting repetition. There was almost none. Each scorer was tight, each one asked for a specific JSON shape, and the shared parts were genuinely shared, not copy-pasted. On the length axis, there was nothing worth cutting. If we had gone in determined to shave a percentage off, we would have started removing instructions that were doing real work. Lean is a valid audit result. Not every prompt is bloated, and a diet that cannot return "this one is fine" is not a diet, it is just cutting.

But the audit still paid for itself, on the other axis. That agent was describing the product it scores for by a name we retired months ago. The old name sat in 23 separate strings that the model reads on every scoring call. No length problem at all. A pure staleness problem: the agent was quietly briefing itself with an out-of-date fact, thousands of times a day. We replaced the name in all 23 places, checked the code still parsed and the identifiers were untouched, and kept a backup. The win there was correctness, not compression, and we would never have found it if we had only been hunting for length.

§6What to take from this

You do not need our fleet to use any of this. You need one agent with a system prompt and half an hour.

Read the prompt as if reviewing someone else's code. You wrote it, so you skim it. Force yourself to read every line and ask what breaks if it is deleted. Most bloat survives because nobody ever reads the whole thing in one sitting.
Hunt the two failure modes by name. Repetition: is any rule stated twice? Is there a tool list in the prose that the framework already sends as schemas? Staleness: is every fact in here still true? A renamed product, a removed tool, a changed process, an ended job.
Measure before and after in tokens, not vibes. "Feels tighter" is not a result. "9,701 to 8,397 chars, 326 tokens a call" is. Small per-call numbers stack into real money at volume.
Only claim what you measured. The post that started this reported an accuracy jump. We did not re-run an accuracy benchmark, so we do not claim one. We claim a size cut and a correctness fix, because that is what we actually checked. Borrowing someone else's headline number for your own work is how build-in-public turns into fiction.
Keep the backup, and ask the bigger question. Every change here is one command from being undone. And before you trim an agent, ask whether it should still be running at all. Sometimes the answer is no, and that is the biggest saving on the table.

None of this is clever. It is the agent equivalent of deleting dead code and fixing a stale constant. The only reason it is worth a note is that almost nobody does it, because a prompt does not throw an error when it gets fat. It just quietly costs you, on every call, until you read it.

Methodology note. This is an audit of our own production agents, not a benchmark. Agent one was a day-job assistant (13 tools, a 76-line system prompt): we merged one duplicated behavioural rule and deleted a hand-written in-prose tool list that the model already received as schemas and that had drifted out of date, taking the prompt from 9,701 to 8,397 characters (13.4 percent, about 326 tokens per call), verified every hard rule still present, then retired the agent entirely when its task ended and archived it to a restorable backup. Agent two was our scoring worker: no meaningful length bloat, but the retired product name appeared in 23 live prompt strings, which we replaced, leaving the code identifiers untouched, with the pre-change file preserved as a backup. We report no accuracy figure because we did not re-run an accuracy benchmark; the only numbers we claim are the character, token and occurrence counts we actually measured.

We Put Our Agents On a Prompt Diet