Gateway Scope Decision (Onboarding)

Gateway Scope Decision (Onboarding)

1. 01

   Map every external system the client's build must touch before selecting any gateway

   List CRM, payment rails, LLM providers, and any physical device fleet. A client with three integrations and no agent traffic does not need the same control plane as one routing model calls across four vendors.

2. 02

   Classify each endpoint by blast radius if it fails

   Separate revenue-path calls (checkout, lead capture) from internal reads. Only the first group justifies token rate limiting, retry budgets, and fallback routing on day one.

3. 03

   Score the client's actual AI traffic volume against the cost of a dedicated gateway

   A gateway that caps LLM spend pays for itself when monthly model calls run into the thousands; below that, the license is a line item the retainer cannot absorb.

4. 04

   Confirm whether the client already owns a gateway the new layer must sit above

   Some clients run Apigee, Kong, or AWS Gateway internally. A gateway-agnostic management layer can unify discovery and keys across those without a rip-and-replace project.

5. 05

   Decide the documentation surface before the first endpoint ships

   If the client's own developers or partners will call the API, generate the reference from the spec at build time rather than writing it by hand after launch.

6. 06

   Write the scope decision into the statement of work with a named owner

   State which gateway, which documentation tool, and who monitors uptime. Unnamed ownership is how API stability quietly becomes unpaid agency labor.

7. 07

   Set a 90-day review trigger to revisit the gateway tier

   Traffic patterns shift once a client's agents go live. A tier chosen at kickoff may be over-provisioned by month three or undersized by month six.