Shipping a paid AI agent took me a week, and almost none of it went where I expected. I assumed the hard part would be the model. It wasn't. What ate the week was a hidden dependency order: most of my lost time came from attempting perfectly valid work before the thing it depended on was actually real.

Shipping a paid agent is a chain of gates, each invisible until you hit it. Attempting a later stage before an earlier one is true doesn't throw an error that says "too early" — it throws a wall that looks exactly like a bug in whatever you're working on, so you debug the wrong layer for hours.

The dependency chain

Each arrow is a gate: the left side must be actually true before the right side can be productively worked on at all.

   wallet created + funded
            │  (identity must resolve)
            ▼
   MCP / tool calls work
            │  (rules must be real, not requested)
            ▼
   enforcement in CODE → tests mean something
            │  (results become trustworthy)
            ▼
   command REGISTERED (not just deployed)
            │  (platform will route it)
            ▼
   live platform behavior testable
            │  (the seam is reachable)
            ▼
   pricing / tier economics tunable
            │  (real signal exists)
            ▼
   real-traffic hardening
       (the hardest failures finally surface)

Every one of these looks like something you can work on whenever. You can't. Each is gated, and the gate is silent.

The edges, and the out-of-order failure at each one

Wallet → tool calls. The premature task: calling MCP tools to make the agent act. Why it failed: the bot wallet wasn't funded to the activation minimum, so identity couldn't resolve. The signal: tool calls failed opaquely — not "fund your wallet," just a failure that looked like a broken tool. I inspected the tool layer for the problem when the real cause was an unmet prerequisite one step upstream.

Tool calls → enforcement in code (and therefore trustworthy tests). The premature task: testing the agent's tier limits and guardrails and believing the results. Why it failed: those rules existed only as prompt instructions, and prompt instructions aren't enforcement — the model honored them on friendly inputs and ignored them on hard ones. The signal: a rule I'd "tested successfully" broke the instant a real input pushed on it. This is the most expensive gate to miss, because until a behavior is deterministic code, every test result is noise — "it worked when I tried it" isn't proof when the next identical try can behave differently. Trustworthy testing is itself gated by code-level enforcement.

Tests → command registered. The premature task: deploying a new command, restarting, and using it. Why it failed: the platform routes by the registered command list, not by what your code handles. A deployed-but-unregistered command returns "Unsupported command" — the message never reaches your agent. The signal: it worked in local testing and was rejected instantly live. Deploying and registering are two separate acts; only the second makes a command exist.

Registration → live platform behavior. The premature task: believing local tests confirmed the agent was ready. Why it failed: command-only routing, cache and status lag, and the messenger's validation layer only engage once you're registered. The signal: the documented "ask in plain English" onboarding flow passed every local test and died on the first real message, because the platform silently blocks anything that isn't a registered command. An entire class of behavior was unreachable until after launch.

Pricing, then real-traffic hardening. Two quieter gates at the end. You can declare prices at registration but can't tune them — judge whether the free funnel converts or the tiers fit demand — until real users arrive; pre-traffic pricing is a guess. And the hardest failures only exist under real traffic: the worst bug of the whole project, the model dumping its internal monologue into a real user's answer, never appeared in any of my own tidy test questions. The signal there is the brutal one — the worst failure surfaced after I thought the project was done. The most important hardening is structurally the last thing you can do, because its prerequisite is the one thing you can't fake: strangers using your agent.

What another builder will get wrong

You'll think the hard part is the model. It isn't — the model is a component you can mostly buy. The hard part is that the components must come online in an order the docs never give you, and working out of order doesn't announce itself; it just costs you a day debugging the wrong layer.

So hold the chain in your head before you start: fund the wallet, get tools resolving, move every money-or-trust rule into code before trusting a single test, register before expecting a command to work, test the platform seam live, then tune pricing and harden against real traffic last. Each step is a gate. Knowing they exist is the skill — so when you hit a wall, your first question is "is this broken, or did I attempt it one step too early?" That question alone would have saved me most of a week.