A gateway only sees traffic that passes through the gateway
Cloudflare AI Gateway is a useful concrete example: its current documentation centers analytics, logging, caching, rate limiting, retries, fallback, and guardrails for AI provider requests sent through the gateway. Those features are valuable because the gateway is on the request path. A child process that edits a file, runs tests, or contacts a non-gateway service is outside that traffic boundary.
Gateway logs are rich provider records, not host execution records
Current gateway analytics can summarize traffic patterns and token consumption, while logging can store request/response information according to configuration. That tells you what the routed request did at the gateway. It does not identify every local subprocess, repository path, temporary file, or package-registry connection that occurred before or after the provider request.
AgentSight starts from the workstation or host instead
AgentSight can record the selected agent process family and correlate supported model activity with commands, files, network destinations, and resource use. This makes it useful for questions about tool execution and local side effects. It does not replace gateway controls such as centralized routing, rate limits, fallback, or provider policy because it is not the traffic enforcement point.
The privacy boundary is different
Gateway logging can place model payloads in a centralized service; current Cloudflare docs expose per-request controls over whether raw payloads are collected. AgentSight stores detailed run data locally by default, but its session can also contain sensitive prompts, responses, headers, paths, and network targets. Teams should decide separately which data belongs in a central gateway log and which should remain in a local profiling artifact.
Use shared identifiers when debugging across both layers
When the model request traverses a gateway, a useful investigation links the gateway request to the local agent session by timestamp, provider/model information, request identifiers where available, and the surrounding tool phase. The gateway can explain routing and provider behavior; AgentSight can explain which local action triggered the request and what happened on the machine around it.
Do not route traffic through a gateway solely to obtain host visibility
If your main question is model routing, centralized analytics, or policy, a gateway is the natural tool. If your question is what a closed-source local CLI or its child process did, adding a gateway does not make the host effects visible. Use the two layers for their own control points rather than forcing all observability through one path.