The Payload System: Why Your AI Workflows Are Slow (And the Architecture Fix)

A client was spending $9 per AI query. Same task every time. Same output quality. Same model.

Blake got it to $0.07.

The difference wasn’t the prompt. It wasn’t the model. It wasn’t even the data. It was the architecture — specifically, a pattern called the payload system that I’ve since started applying to almost every AI workflow I build.

Here’s what was happening and why it matters beyond this one client.

The Problem: Too Much Context

The product Blake was building processed conversation data — 1.5 gigabytes of raw audio transcripts, behavioral events, questions asked, statements made by every participant. Massive dataset.

Every time a user opened a session, the AI searched through that entire database to find what it needed. This created three problems:

1. Speed: Searching 1.5GB takes time. Lots of it.
2. Cost: AI providers charge by token. More context = more tokens = more cost. $9 per query.
3. Accuracy: Context windows have limits. I think of the context window like a single sheet of paper. As long as everything fits on that one page, the AI reads every word. Once you start cramming in too much, it skims. Accuracy drops. Hallucinations increase.

Most people who hit this problem reach for the same solution: a better model. A larger context window. More compute.

That’s the wrong instinct. The bottleneck almost never is the AI. It’s the architecture.

The Fix: Pre-Compute What Each Use Case Needs

The payload system works like this.

Before a user even opens a session, a script runs in the background and generates five small files — one for each feature the product needs to support. Each file contains only the slice of data that specific feature actually needs.

The file for the “questions” feature has every question that specific user has ever asked. That’s it. No behavioral events, no other participants, no timestamps — just the questions.

The file for the “behavioral events” feature has only behavioral events. Right-sized for the job.

When the AI runs, it doesn’t search the database. It reads the payload file. Small, focused, pre-built.

For edge cases — situations where the payload doesn’t have enough — you can always go back to the raw database. But most of the time, the payload is enough.

Result: $9 per query dropped to $0.07. Same output.

The Rule Behind the Pattern

If you’re pulling the same data consistently, pre-compute it. Don’t make AI search everything every time. Build the right-sized version for each use case.

This is the same idea behind what I call Centralized Context — the principle that AI agents perform better when they have access to a focused, curated memory layer rather than being asked to search through everything every time they need something. The difference between a good AI workflow and a fragile, expensive one is usually whether the right data is already in the right format when the AI needs it.

Think about how this applies to your own workflows. If you have an AI agent that runs every day and always needs the same type of information — your top priorities, your CRM contacts, your upcoming meetings — that’s a candidate for pre-computation. Pull it once. Format it for the use case. Give the AI a clean file to read instead of a raw database to search.

What “Right-Sized” Actually Means

The payload concept forces you to think clearly about what each feature actually needs. That’s the underrated part.

When you build a payload, you have to answer: what information does this specific use case require, and what is irrelevant? That clarity often reveals that your AI workflow was doing a lot of unnecessary work — searching for data it didn’t need, processing context that had no bearing on the output.

In Blake’s case, the “questions” feature didn’t need behavioral events. The “behavioral events” feature didn’t need statements from other participants. Separating them made each feature faster, cheaper, and more accurate — because the AI was working with a focused signal instead of a noisy mess.

Applying This to Your AI Stack

You don’t need 1.5GB of data to benefit from this thinking. The pattern applies at much smaller scale.

If you use AI for weekly reviews, pre-compute a document with your calendar events, task completion stats, and project status before the AI runs. Don’t make it pull from five different places every time.

If you use AI for meeting prep, pre-compute a contact brief for everyone on your calendar before the week starts — not 30 minutes before the meeting.

If you have an AI agent that updates your CRM, pre-compute the relevant contact record and recent interactions before the agent runs its update logic.

Pre-compute. Right-size. Give AI the payload, not the database.

The $9-to-$0.07 story stuck with me because it reframed how I think about AI performance problems. When something is slow or expensive or inaccurate, my first question now is: what is the AI being asked to search through, and does it actually need all of that? Nine times out of ten, the answer is no.

The fix is usually subtraction, not escalation.