What this is

The gateway is the one endpoint AI clients connect to. It exposes a small orchestration surface, not the raw downstream tools — so the model sees a governed set of verbs, never a pile of unscoped app functions.

Why one front door

Without it, every agent re-implements its own connections, permissions, approvals, and logging. With it, a client configures once to the gateway; discovery, authorization, credential injection, execution, confirmation, and audit are handled centrally and consistently.

Runtime flow

gw_session (carries user_intent)
   → search_tools     availability ranking from the registry  (NOT authorization)
   → describe_tools   input schema + risk + confirm for a chosen tool
   → execute_tool     POLICY enforced here → allow | route | deny
        ├─ allow  → vault injects creds → downstream runs → result + evidence_id
        └─ route  → approval queue → confirm_operation (human) → runs → evidence_id

The boundary is execute_tool. search_tools only answers "what's relevant and available here?" — it never grants access. Discovery ≠ authorization.

Sessions

A session groups the calls for one user task. Every gateway call carries session_id + user_intent, making multi-step agent work traceable end-to-end and tying each action to the intent behind it.

Gateway tools

Tool	Answers
generate_session_id / gw_session	Start a traceable task
search_tools	Which tools are relevant and available? (availability)
describe_tools	What's this tool's schema, risk, and confirmation requirement?
execute_tool	Is this exact operation allowed now? (the policy boundary)
confirm_operation	Approve or deny a routed sensitive action
help	Orientation for the model

Honest scope

The gateway governs and records; it does not decide your business outcome. Native capabilities (ingestion, retrieval, notifications) are discoverable and executable through the same gateway tools as connected app tools — there is no second, ungoverned path.

See also

Gateway API Contract · Control Plane · Concepts