Skip to main content
Gateways are pluggable execution runtimes where agent work actually happens. They run LLM calls, invoke tools, execute code, and report results. Forge treats gateways as ephemeral — they can be added, removed, or replaced without affecting durable state. owns the run history; gateways own the live execution.

🔄 Gateway Lifecycle

GATEWAY LIFECYCLE

1. Self-Register

Bridge starts, loads adapter, calls Convex with gateway name, URL, capabilities, token

2. Health Monitor

Convex pings every 60s. Updates status: healthy, degraded, or offline.

3. Dispatch

Interpreter routes steps. Governance checks health before every dispatch.

4. Deregister

Graceful shutdown. InstanceId prevents races.

HEALTH STATUS

Healthy

Dispatch proceeds normally

Degraded

Dispatch + logged warning

Offline

Dispatch blocked by gate

Registration Fields

FieldPurpose
gatewayIdStable identifier from Bridge (deduplication key)
nameHuman-readable display name
environmentproduction, staging, dev, or custom label
urlGateway HTTP endpoint
token / tokenHashAuthentication credential (SHA-256 hash for secure storage)
instanceIdPer-process UUID to prevent deregister races during rolling deploys
registrationSourceself (auto-registered) or manual (operator-configured)
capabilitiesDeclared gateway capabilities (see below)

💚 Health Checking

A cron job runs every 60 seconds (gateway health check) and pings all registered gateways:
StatusMeaningDispatch behavior
healthyGateway responded within timeoutDispatch proceeds normally
degradedGateway responded with warningsDispatch proceeds with a logged warning
offlineGateway did not respondDispatch blocked by gatewayHealthGate
Health history is recorded in the gatewayHealthHistory table and retained for 90 days.
The governance pipeline’s first gate (gatewayHealthGate) checks the gateway’s current status before every dispatch. An offline gateway blocks all step execution — no step can bypass this gate.

🧩 Gateway Capabilities

Each gateway declares its capabilities at registration time. The platform uses these for routing decisions and feature availability.
CapabilityTypeDescription
streamingbooleanCan emit events during execution (tool calls, partial output)
sessionResumebooleanCan resume a prior conversation/session via resume token
fileIObooleanAgent can read/write files on the host filesystem
mcpServersbooleanSupports Model Context Protocol tool servers
sandboxingbooleanProvides built-in execution isolation
subagentsbooleanSupports native subagent orchestration
costTrackingbooleanReports cost per execution in the result
structuredOutputbooleanSupports structured/JSON output mode
managementbooleanSupports the RuntimeManager interface (agent sync, management)
maxConcurrentnumberMaximum concurrent executions
outputStrategiesstring[]Supported output capture methods: file, stream, structured
costTierstring?Cost classification: low, medium, high
latencyProfilestring?Latency classification: fast, moderate, variable

Capability Comparison

CapabilityOpenClawOpenClawClaude Agent SDKClaude Agent SDKVercel AIGloo AI
StreamingYesYesNoYes
Session ResumeYesYesNoNo
File I/OYesNoNoNo
MCP ServersYesNoNoNo
SandboxingYesNoNoNo
SubagentsNoYesNoNo
Cost TrackingYesYesNoYes
Structured OutputNoYesYesNo
ManagementYesNoNoNo
Auto-RoutingNoNoNoYes
Grounded CompletionsNoNoNoYes (opt-in)
TraditionNoNoNoYes (opt-in)

🔌 Multi-Gateway Support

Forge supports multiple gateways simultaneously. The interpreter routes steps to specific gateways based on deployment configuration. With multi-adapter Bridge, multiple gateways can share a single Bridge URL — Bridge loads all configured adapters and routes each dispatch to the correct one by provider name.
Gloo AI’s unique feature is intelligent model routing. It analyzes each request and selects the optimal model tier automatically — simple tasks get fast, cost-effective models while complex tasks get more powerful ones. Agents deployed to a Gloo AI gateway do not need hard-coded model assignments.
Steps are routed to gateways through the deployment binding. When a workflow is deployed, it specifies which gateway to use. The interpreter resolves the gateway at dispatch time via resolveRoutingCandidates() and routeExecution().

🔐 The Ownership Boundary

The most important architectural principle in Forge’s gateway model:

OWNERSHIP BOUNDARY

ConvexConvex Owns
What to executeWhether to executeWhat happenedHow much it costWho did it

Durable state, audit trail, governance

Gateway Owns
How to executeLive execution stateRuntime environmentAgent workspace

Ephemeral — nothing is lost if gateway crashes

If a gateway crashes, nothing is lost. The step timeout enforcer detects the stall, the on_failure policy is applied, and Convex has the full audit trail of everything that happened before the crash.

🔑 Token Rotation

Gateways authenticate with Convex using tokens. Forge supports zero-downtime token rotation:
  1. A new token is generated and set as the current token. The previous token is stored in previousToken with an expiration timestamp.
  2. During the rotation window, both tokens are accepted.
  3. After previousTokenExpiresAt, only the new token is valid.
  4. Callbacks include a tokenVersion header for version tracking.
See also: Bridge & Adapters | Governance Pipeline