Message Unification: Turn a Burst Into One Call
The highest-leverage fix for agent cost, in one window.
- A single intent arrives as 4–5 messages in a few seconds — the normal burst.
- Unifying a four-message burst cuts that intent’s execution cost by ~75%.
- A few seconds of silence is the signal: 1 call, full context.
The problem
- People talk in bursts — a greeting, a correction, then the real request.
- A webhook-driven agent runs on each fragment: many executions, many calls, half answers.
- One intent ends up costing several times what it should.
The solution
Buffer the first message, reset a timer on each new one, and flush when the sender goes quiet — merged in order.
- Open a buffer on the first message; reset the timer on each new one.
- On a few seconds of silence, close the buffer.
- Merge in order → emit one payload → one LLM call.
Not to be confused with dedup: unification merges different messages into one intent; dedup removes identical copies.
Result: a four-message burst becomes one full call — roughly three-quarters off that intent's execution cost.
Message unification is the technique of collecting a burst of messages from the same sender inside a short time window and merging them into a single LLM call. It’s the single highest-leverage fix for AI agent cost, because it targets the way people actually talk — in bursts, not in one clean message. Here is how the window works, and the two ways to add it.
The problem it solves
People send messages in bursts: a greeting, a correction, then the real request — three or four webhooks in a few seconds. Unification collapses that burst back into the single message the user meant to send. This is the mechanism behind the cost pattern in why fragmented messages cost your AI bot 3x more — unification is the fix that pattern points at.
How the time window works
Unification hinges on one parameter: the debounce window. Hold the first message from a sender, then wait. Every new message inside the window resets the timer. When the sender goes quiet for the length of the window, the buffer closes, the messages are merged in order, and one payload is released.
t=0.0s "hi" → buffer opens, timer starts
t=0.9s "wait" → appended, timer resets
t=1.7s "actually" → appended, timer resets
t=2.4s "help with order" → appended, timer resets
t=5.4s (3s of silence) → buffer flushes → 1 LLM callOrder is preserved so the merged message reads as the user intended — “hi / wait / actually / help with my order” becomes a coherent request, not a jumble. That ordering is what lets the model treat the merged payload as one natural message and answer in one pass.
What unification changes
| Metric | Without unification | With unification |
|---|---|---|
| Executions per burst | one per fragment | one per intent |
| Model calls | one per fragment | one, full context |
| Answer quality | partial, per fragment | complete, once |
| Cost | multiplied by fragments | paid once |
On execution-priced platforms, collapsing a four-message burst into one cuts that intent’s execution cost by roughly three-quarters, and the model finally sees the whole request instead of guessing from “hi”.
The manual fix (Option 1)
Unification is simple to describe and awkward to build, because it needs state that survives across requests.
Fix 1: buffer per sender
Hold messages keyed by sender in a store that outlives a single webhook, and don’t forward until the burst looks finished. A stateless handler can’t do this on its own.
On a gateway, the per-sender buffer is built in.
Fix 2: run a timer that resets
You need a timer per conversation that resets on each new message and fires on silence — infrastructure, not a line of handler code.
On a gateway, the window is a setting you pick.
Fix 3: merge in order
Fragments must be stitched in the order sent, or the merged payload reads as nonsense. Unification is ordered merge, not random concatenation.
On a gateway, ordering and merge are handled for you.
The catch: stateful infrastructure you now own
Buffering turns a stateless webhook into a small stateful service: a store, a per-sender timer, ordering, and cleanup when someone walks away mid-thought — correct under load, and rebuilt on every channel you add. For one agent it’s doable; across a fleet it’s a system to maintain.
Place a gateway layer (Option 2) — faster
A message gateway holds the burst, merges it in order, and forwards one call — in front of your agent, with no buffering logic inside it.
- No stateful code in your agent. The gateway keeps the burst; your handler stays stateless.
- One layer, every channel. The same buffering covers all of them.
- Tune, don’t code. The window is a setting.
- Pairs with deduplication. A burst that also arrives twice needs both — dedup drops the copies, unification merges what remains.
Option 1 (DIY) vs Option 2 (gateway)
| Do it yourself | Use a gateway | |
|---|---|---|
| Per-sender buffer | ✕You build & host state | ✓Built in |
| Debounce timer | ~Must survive requests | ✓Just a setting |
| Ordered merge | ~Yours to get right | ✓Handled for you |
| Agent stays stateless | ✕Now a stateful service | ✓Unchanged |
| Every channel | ~Repeat setup each time | ✓One layer, all channels |
| Control of internals | ✓Full | ~Abstracted away |
If option 2 sounds more like you, here’s the short version of how to set it up: let a gateway unify the burst →.
Either way — go make a burst into one clean call.
Thanks for reading. 👋
Orlando. -
Orlando Quijada
Technologist with 15+ years of experience. Developer, SaaS tester, and AI collaboration & optimization specialist. Currently contributing at portarus.com.
Written on
