← Back to field notes
Architecture2026-07-126 min read

Gateway or Direct: choosing the right execution path

A practical framework for deciding when centralized enforcement matters more than a provider-direct request path.

A translucent control plane splitting one AI signal into provider paths
gateway / direct

Enterprise AI teams rarely want the same transport path for every workload. Some requests need centralized redaction, budgets, and audit. Others need to stay inside an AWS account or a private network. Policate treats that as an operating decision, not a provider lock-in decision.

Gateway mode is the managed default

In Gateway mode, the Policate gateway is authoritative. It authenticates the request, evaluates the active policy, scores eligible models, checks budgets and rate limits, optionally serves a cache hit, and records the resulting trace. Developers still use the same CLI and model roles.

This path is the strongest fit when platform, security, and finance teams need one consistent enforcement point across providers and teams.

Direct mode keeps inference in your environment

Direct mode is an organization opt-in. The binary refreshes a hash-verified, secret-free runtime bundle containing approved models, presets, fallback chains, and policy context. Requests then go directly from the binary to the company provider account or local endpoint.

The trade-off is explicit: local routing and provider-direct execution are available, but server-side budget enforcement, redaction, central caching, and authoritative audit are not. That boundary belongs in the security review and in the organization’s operating policy.

Start governed, specialize when needed

Most teams should start in Gateway mode and enable Direct mode only for workloads with a clear network, residency, or provider-ownership reason. Both modes share the same dashboard, onboarding, presets, managed tools, and startup sync, so changing transport does not mean rebuilding the developer workflow.