Sending the model less than you think it needs
The default agent implementation passes the whole thread, the whole attachment, and everything known about the contact into the model, because that is the easiest thing to write. It is also the most expensive, the slowest, and the version that puts the most personal data somewhere you do not control.
4 min read
Cutting it back is one of the rare changes that improves cost, latency, quality, and privacy at once.
What actually needs to go
Work backwards from the reply. To answer "where is my order", a model needs the question, the order status, and enough thread context to know what was already said. It does not need the customer's full order history, their address, the seven previous conversations, or the signature blocks from every message in the chain.
Four cuts, in order of return.
Quoted history. A long chain where each message quotes the last is mostly repetition. get_thread already returns the conversation without it, which is both cheaper and less confusing than the raw chain.
Signature blocks and disclaimers. Every message carries them, none of them help, and corporate footers can be longer than the message.
Attachment bodies. Extract the fields you need and pass those. A fifty page contract does not belong in a context window when the answer depends on three numbers, per attachments.
Contact records. Pass the facts relevant to this conversation, not the whole history. The record is a store, not a payload.
| Instead of | Send |
|---|---|
| The raw chain | The stripped thread |
| The full attachment | The extracted fields |
| Everything on the contact | The facts this reply needs |
| Your whole knowledge base | The retrieved passages, cited |
| The customer's full record | The current state of the one thing asked about |
What should never go
Some things do not belong in a model call regardless of convenience.
Credentials. Not in the prompt, not in the context, ever. They live in the vault and are opened at the point of use, per permissions and grants.
Payment details. If a card number appears in an inbound message, the correct handling is to not pass it on, tell the sender not to send it, and escalate. Storing or forwarding it is worse than the inconvenience of refusing.
Other people's threads. Whatever the agent can technically reach, one conversation's context is not another's. This is the failure that context bleed produces, per when the agent sends something it should not have.
Special category data, where you can avoid it. Health, beliefs, and similar carry heavier obligations, and passing them to a third-party model provider is a decision that deserves to be deliberate rather than incidental.
Redaction, and its limits
Stripping obvious patterns before a model call is cheap and worth doing: card numbers, national identifiers, and anything matching a format you know you never need.
Two caveats stop this being a solution on its own. Redaction is pattern matching, so it catches the formats you anticipated and misses the sentence where somebody typed their details in words. And over-redaction damages answers, since a model that cannot see the order number cannot look it up.
Treat it as a safety net under a design that already sends little, rather than as the design.
The cost argument is the same argument
Everything above also reduces tokens, which is usually the largest line in an agent's running cost, per what email actually costs.
That alignment is useful when making the case internally: minimisation is not a compliance tax, it is the same change that makes the agent cheaper and faster. A thread trimmed to what matters produces a better answer too, because the model is not weighing forty lines of quoted signature against the actual question.
Where the obligations bite
Message content going to a model provider is processing personal data, which brings the questions in where the mail actually goes: which provider, under what terms, in which region, retained for how long.
Minimisation is the lever that shrinks all of those at once. It also shrinks the incident: if something goes wrong at a provider, the exposure is whatever you sent, and a design that sends the extracted fields rather than whole threads has a materially smaller problem than one that sends everything.
A short practice
- Strip quoted history and signatures before the model sees anything.
- Extract from attachments; never pass the file.
- Pass the contact facts this reply needs, not the record.
- Retrieve passages rather than shipping the knowledge base.
- Redact known formats as a net, not as the plan.
- Never send credentials, payment details, or another thread's content.
- Log ids and decisions, not bodies, per what to monitor in production.
Questions
- What should an email agent send to the model?
- The stripped thread, the specific facts needed from the contact, and extracted fields rather than whole attachments. Not the raw chain, the full record, or the knowledge base.
- Does minimisation hurt answer quality?
- Usually the opposite. A model weighing forty lines of quoted signature against the actual question answers worse than one given the relevant thread and the fields it needs.
- Is redaction enough on its own?
- No. It catches formats you anticipated and misses details written in words, and over-redaction breaks lookups. It is a net under a design that already sends little.
- What must never reach the model?
- Credentials, payment details, other threads' content, and special category data you can avoid. Credentials live in the vault and are opened at the point of use.
- What if a customer emails a card number?
- Do not pass it on or store it. Tell them not to send it, and escalate. The inconvenience is smaller than the alternative.
- Why does this matter beyond privacy?
- Tokens are usually the largest running cost, so the same change makes the agent cheaper and faster, and it shrinks the exposure if anything goes wrong at a provider.
Give your agent an address it can answer from.
Create an inbox