An API built for agents

Context

Most "API access for AI" stories amount to a thin REST wrapper over endpoints originally designed for a single-tenant administrative client. The seams reveal themselves immediately under agent load. As soon as an autonomous agent must operate across multiple businesses, the authentication model breaks; the permission model leaks; and item resolution — the act of mapping the user's natural-language reference to the correct catalogue identifier — becomes the bottleneck that the wrapper was never designed to absorb.

Design

• A multi-tenant authentication strategy granting an agent scoped access across many businesses without requiring a backend role-based access-control rewrite. The mechanism is a pool of business-scoped sessions managed at the gateway layer.
• A gateway routing layer so the agent communicates with a single stable surface even as upstream services evolve. The agent's contract is therefore decoupled from internal service boundaries.
• Item resolution as a first-class endpoint: free text in, ranked canonical identifiers out, served by the same retrieval pipeline used elsewhere in the platform for partner menu mapping. Resolution is treated as a primitive of the agent platform, not a per-feature convenience.
• An explicit out-of-scope boundary for destructive operations. Operations whose effects cannot be cheaply undone remain outside the agent's reach for the foreseeable future. The decision is treated as a structural constraint, not a settings flag.

Outcome

Agentic features ship without forcing a wholesale authentication rewrite. The item-resolution primitive is reused across multiple AI surfaces — voice ordering, support, onboarding — yielding a compounding architectural return on a piece of infrastructure that would otherwise have been reimplemented several times.

Stack

Go services · Kong gateway · OAuth2 / service-account tokens · shared retrieval service.