# Runbook — too many messages in a row, or a message that never arrived > **Symptom.** *"el agente manda muchos mensajes seguidos"* · *"contesta en 4 mensajes cortitos"* · > *"me llegó cortado"* · *"ese mensaje nunca llegó aunque el agente lo escribió"* · *"Meta nos > bloqueó"*. > > Two symptoms, one runbook, because operators report them together and the boundary is not obvious > from the outside: some of this is the model writing too much, and some is the platform changing > what the model wrote on the way out. Always compare **what the model produced** against **what the > lead received** before deciding which. --- ### H1 — The message was swallowed whole The most damaging and least visible failure here. When a reply contains **text plus the silence token together**, the platform drops the entire message — not just the token. The agent believes it answered, the transcript shows an intent to speak, and the lead received nothing at all. This is worst exactly where it matters most, because safety and redirect messages are the ones most likely to be written alongside a decision to stop. - **Test:** find a turn where the agent clearly meant to say something and the lead received nothing. Check whether the generated reply also carried the silence token. - **Stop condition:** text and the token in one reply → **you're done**. - **Fix:** the reply must be one or the other. Fix it in the examples: never end an example that contains a message with the silence token. A rule will lose to the examples. - **Note:** inline versus alone makes no difference — the whole message is suppressed either way, so do not spend time on placement. *Evidence: an audit found six of these per run, including a crisis-line message and a minor-redirect message. Across ninety days of real data, zero safety messages had ever been delivered.* ### H2 — Monologuing taught by the examples The agent sends three or four messages in rapid succession: greeting split in two, an interpretation split across three. This is almost always learned — if the examples show a reply broken into fragments, the model reproduces the fragmentation. - **Test:** read the examples for the step where it happens. Count how many separate messages a single example turn represents. - **Stop condition:** examples show split turns → **you're done**. - **Fix:** merge them into one message per turn in the examples. When a client supplies copy as several bubbles, that is still **one** message in the example. - **Do not** add a rule about message count. The model follows examples over rules, and this is the cleanest demonstration of that in our history. *Evidence: a post-deploy analysis of 59 conversations measured monologuing at a 49% failure rate, root-caused to both examples splitting turns. A separate agent's rapid-fire replies to ad traffic produced 44 Meta blocks before it was caught.* ### H3 — Splitting is a platform setting, not a rule Message length and splitting are configured on the platform. An agent writing one long message can still arrive as several, and no prompt instruction changes that. - **Test:** compare the generated text to the delivered messages. A clean split at a length boundary is the platform, not the model. - **Stop condition:** the split is at the configured boundary → **you're done**. - **Fix:** change the setting. A rule like "máximo 3 líneas" is inert — the agent has no concept of a bubble and cannot act on one. ### H4 — Formatting stripped on the way out Punctuation, symbols and inverted marks can be removed after the model writes them, which reads as truncation or as the agent ignoring an explicit instruction. When an agent's own formatting configuration is unset, a platform default applies — including rules the operator never chose. - **Test:** compare generated to delivered. If characters are missing but words are intact, it is the formatting layer. - **Stop condition:** only formatting differs → **you're done**. - **Fix:** set the agent's formatting configuration explicitly. Do not chase it in the prompt. *Evidence: an agent stripping inverted punctuation even where it was written literally into the keyword responses — its formatting config was unset, so a hardcoded default applied.* ### H5 — Style copied from the SDK's own files Em dashes, bullet lists and hyphens appear in output because they appear in the files the model is reading. Nobody instructed it; it is imitating. - **Test:** search the **live** config for the character — the deployed sections, not the local `agents//` working copy. Presence in the source is the diagnosis. - **Fix:** clean the sections and redeploy with `deploy_agent_sdk`. Keep format prohibitions as explicit rules as well — an example can demonstrate what to do, but it cannot demonstrate an absence. *Evidence: an agent producing hyphens, dashes and bullets as the top violation across 29 conversations while no example used them — they were in the SDK prose. Elsewhere, an em dash reached production inside a line for an agent with an explicit rule against them.* --- ## When to stop If the model's output matches what the lead received, the examples show single-message turns, and the platform settings are what the operator wants, then this is a copy preference — take their wording and change the examples. Otherwise capture it: the conversation id, the generated text, the delivered messages, and the turn where they diverge. Send that with `report_feedback`.