I run a paid AI agent on the Post Fiat Task Node network — it answers questions about validators and charges per query across tiers. Building and hardening it took weeks. Registering it in the public directory was supposed to be the easy part: one function call and you are live.

Then a class of failure I had not anticipated showed up.

Nothing was wrong with the agent's logic — it had passed every local test. What broke lived in the seam between my agent and the platform's own runtime rules: failures that are structurally impossible to catch before registration, because they only fire when a real message hits the live platform. This memo is about that seam. If you're about to register a paid agent, the lesson is simple and expensive to learn the hard way: registration is not the finish line. It's the start of a second round of bugs that local testing cannot reach.

Why local testing can't save you here

Before launch you test the only way you can: call the agent's logic directly, read the output. That runs the agent in isolation. It never exercises the platform layer — the messenger that delivers messages, the directory that lists your commands, the validation that decides what even reaches your code. Those engage only once you're registered and a real message comes through. So a whole category of behavior stays invisible until it's too late to fix quietly. Here's what surfaced, in the order it hit.

1. The platform silently blocks anything that isn't a command

My help text told users to send their question in plain English and the agent would route them to the right tier. Clean onboarding, and it worked in every local test.

The first real plain-English message comes back instantly: "Unsupported command." Not from my agent — from the messenger. The Task Node messenger only forwards messages beginning with a registered slash command. A plain-English message never reaches the agent at all.

So my agent's own documented first step was impossible on the live platform — and undiscoverable beforehand, because local testing calls the agent directly, with the messenger's validation layer out of the loop. The feature died the instant a real user touched it.

2. A command you've deployed still doesn't work until you register it

The fix was a new command — /tier — that takes a question and names the tier it needs, a platform-compliant version of the routing I'd promised. I wrote it, deployed it, restarted the agent, tested it.

"Unsupported command."

The code handled /tier perfectly. But the messenger doesn't validate against what your code can do — it validates against your registered command list, and /tier wasn't on it. It only worked after I re-ran registration to add it. Deploying a command and registering a command are two separate acts; the platform enforces the registered list, not your code's capabilities. Every command you add after launch needs a re-registration before a single user can reach it.

(One smaller trap rides along here: after re-registering, /tier still failed until I fully reloaded the messenger, which had cached the old command list — and the directory kept showing the agent "online" after I'd stopped it, because liveness updates on a delayed ping cycle. Neither is a bug, but both make a correct change look broken. After a registration change, give the platform a beat and reload before concluding anything's wrong.)

3. Real users send what you never tested

Local testing used tidy, single-purpose questions. The first hard real query was a four-part monster: compare two validators across rounds, compare a third against the top ten, explain why one was down, and why a fourth wasn't ranked — one message.

The answer led with the model's entire internal monologue: something close to "Let me get the network data. Actually, that tool isn't available. Let me be transparent about what I can show..." — paragraphs of thinking-out-loud before the real answer. (Reconstructed from the live output; the shape was a multi-sentence planning dump ahead of the substance.)

The leak had been latent all along. My happy-path questions were simple enough that the model answered cleanly in a step or two and never narrated. A complex enough live query surfaced it at full severity. You don't get to choose the first hard question — a stranger does.

The fix that held wasn't a prompt rule. I already had one against showing reasoning, plus a regex guard that retried on detected leak phrases. Both failed live — the retry even leaked a new phrase on the attempt meant to fix it. What worked was a deterministic post-processing stage: after the model answers, a separate tool-less call rewrites it to return only the substance, stripping all reasoning and planning.

async function polishAnswer(draft) {
  const r = await client.chat.completions.create({
    model: 'deepseek-chat',
    messages: [
      { role: 'system', content: 'Return ONLY the final answer. Remove all reasoning, planning, and process narration.' },
      { role: 'user', content: draft }
    ]
  });
  return r.choices[0].message.content || draft;
}

It can not narrate — no tools, one job. I deleted the regex retry as redundant. Behavior that touches user trust needs a deterministic stage, not a request to the model.

4. A tool-level gate silently overrode the prompt

After deciding my free preview tier should answer broader questions, I updated its prompt to allow them. The behavior didn't change. Preview kept refusing multi-validator questions.

The cause was a second control layer: a per-tier allowed-tools list in code that physically blocked preview from calling the comparison and ranking functions. The prompt said "answer anything"; the tool gate said "you may only call single-validator tools." The gate won, silently, and the only way I found the disagreement was by testing the exact case.

This is the same shape as the narration leak, stated as a rule: the prompt is advisory, the code is law. When two layers govern the same behavior, the deterministic one wins — so that's the layer that has to be right, and the one you have to test against directly.

What another paid-agent builder will get wrong

The assumption that will cost you: that passing local tests means the agent is ready to launch. It means the agent's logic is ready. It says nothing about how the agent behaves wearing the platform's rules — command-only routing, registered-command enforcement, cache and status lag, tool-gate overrides, and real users sending inputs you'd never script for yourself. None of that is reachable locally, and all of it is live the moment you register.

So, the minute you register, before you trust anything: send a plain-English message and confirm it even arrives. Run every command through the real messenger, not just your code. Make a registration change and watch how long the directory takes to reflect it. And throw your single hardest, ugliest, multi-part question at it — because a real user will, and you want to be the one who finds what breaks.

Registration is not the finish line. It's where a new set of bugs becomes possible, and the only way to find them is to test the agent the way the platform actually runs it: live, through the front door, with the messages you were hoping no one would send.