200 OK, but the client gets nothing: three n8n agent bugs from production

This is the second story about an AI agent in production. 20 days ago I closed the Reasoning Lock bug: the model burned tokens on hidden reasoning, sent an empty string to the client, even though the status showed success. I added an empty-response validator and telemetry. I wrote: "the log is empty — the layers are working." The log stayed silent for 20 days. Then the managers forwarded new complaints from the client: a customer messages in Direct, and the agent stays silent. But this time the culprit wasn't the LLM.

Project architecture: The n8n agent runs in production for a jewelry atelier. At night it takes requests in [REDACTED]gram Direct, carries on a conversation, collects a form (name, birth date, field of work, phone number), and creates a deal in amoCRM. The stack: n8n (self-hosted) + Redis (dialogue memory, 30-day TTL) + LangChain. The LLM changed: instead of DeepSeek V4 Pro, it's now z-ai/glm-5.3-flash via OpenRouter, with qwen/qwen3.8-flash as a fallback. The workflow grew from 64 to 88 nodes, and comment handling and retry logic were implemented.

Bug 1: Protocol tags instead of a human answer

I opened the executions — clean. Not a single failed run. The hypothesis "Reasoning Lock happened again" doesn't hold: the model responds, and quickly. The only trace in amoCRM: the client replied "Yes" at 20:06 to an order confirmation (sent at 20:02), then just a record in MESSENGER-ID, and silence in Direct.

I opened the OpenRouter card: 871 completion tokens, of which 766 were reasoning — leaving 105 visible tokens. In volume, that's protocol service tags: `[VERDICT:ORDER:DATA|HOT] [NEED_MANAGER_CALL] [STAGE:PERSONAL]`

The GLM model did respond. By the book. Not a single human word. DeepSeek 4.0 PRO used to withdraw into itself; GLM turned out to be the model student: no human text required — it just submits the form.

The validator didn't catch it because it only checks for emptiness (output isn't empty — pass). The invariant "empty content + tokens spent + finish_reason stop ≠ success" also failed: tokens were spent (yes), finish_reason was stop (yes), content wasn't empty (yes). It checked for the absence of emptiness, not the presence of human text.

Next, the Format Response node strips the tags by design — leaving `\n\n \n` (a non-empty string for n8n, characters for Meta, nothing for the client). The guard before sending checks whether the node was executed, not what it contains.

Bug 2: Meta's 1000-byte limit breaks Russian text

After the diagnosis, a red node surfaced on the final send step:

``` NodeApiError: Bad request - please check your parameters Send direct message1 ```

The failure happened on the form: name, date, field, phone number, paragraphs separated by `\n\n`. The longest message in the agent's life. Meta's API docs state: Message text must be UTF-8 and be 1000 bytes or less. Not characters — bytes.

In UTF-8, a Cyrillic letter is 2 bytes, an emoji is 3–4 bytes (✨ = 3, 💎 = 4). 1000 bytes is roughly 500–550 characters of Russian text. I ran a 570-character Russian text through it: it came out to 1030 bytes. A form with a name, a date, a field, three paragraphs, and "Is this correct?" easily crosses that threshold. The most frustrating part: `\n\n` isn't a bug — it's human paragraph breaks, just like in Word — a pipeline tuned for reasoning tripped over a simple line break.

Bug 3: A catalog instead of a filtered result — the wrong

Schema Type

While I was dealing with the sending issue, another complaint came in from the managers: "the agent is showing the wrong stuff." Ask for earrings — it dumps half the catalog; ask for watches — half the catalog again.

The get_product_catalog1 tool node handles the catalog. Specify Input Schema was enabled, but Schema Type wasn't set. n8n defaults to "Generate From JSON Example": give it an example, and it derives the schema. But the jsonSchemaExample field didn't contain a data example — it contained the JSON Schema itself, with fields like type, properties, required, category (with enum: bracelets, earrings, necklaces, luch, candles), and description.

n8n doesn't validate the content — it honestly took the schema for an example and derived a schema from a schema. The top-level keys type, properties, required became the example object, and category ended up at the bottom. The tool reads inputData.json.category, gets undefined, and falls back to the all default. Any request returns the entire assortment instead of a filtered result. A one-click fix (Schema Type → "Define using JSON Schema"), but an hour and a half of searching.

Takeaway

Three different natures behind one problem: the model answers with protocol tags instead of text, the API has a hard limit on bytes instead of characters, and the tool's config hides behind the wrong default. A green node is the worst kind of red one — at least with a failure you know where to look.