The Log Line Vercel Connect Won't Write For You
You ship an agent that talks to Slack, then Salesforce, then a custom API. At 14:31, a token gets revoked mid-turn. At 14:32, your agent's third tool call fails. Vercel Connect shows you the token revoke event. It won't show you why your agent broke.
Vercel Connect's new observability is real progress. You get token issued, refreshed, and revoked events. You get runtime events: connector invoked, cache hit/miss, latency, status. You get correlation IDs scoped to each connector call. But a connector's view of the world stops at the connector boundary. It doesn't see the agent's reasoning loop, the tool call that triggered the invocation, or the next turn's decision that went sideways because of a silent partial success two steps back.
The invisible seam is where time gets lost and root causes hide. Your agent made a decision at turn 4 to call Tool X. The connector refreshed a token, hit a rate limit, and succeeded on retry. The agent got back a payload and interpreted it as "operation complete." But the interpretation was stale. The next reasoning step sent the agent down a rabbit hole. Connector logs show the retry. They don't show the faulty interpretation that bridged the silent failure to the downstream error.
Connector-Scoped vs Agent-Scoped: The Cardinality Problem
Connect's correlation IDs are per-connector-invocation. Your agent's correlation should be per-agent-run. One agent turn can trigger 4–8 connector calls plus 2–3 LLM calls. Multiply that across 50 turns and you're chasing IDs across three systems per incident. In practice, you spend 15–40 minutes per incident chasing IDs across three systems.
The root cause is that connector logs and agent logs record different levels of detail. A connector log answers: "Did the token refresh succeed?" An agent log needs to answer: "Why did the agent decide to call this tool?" and "What did it do with the response?" These questions operate at different levels. When you try to join them, your queries break under retries and parallel calls.
OpenTelemetry's trace_id propagation breaks at the connector boundary. Vercel owns the connector span, and your agent loop doesn't inherit it—it has to inject it. You can wrap it in a custom header, but you're now managing two trace ID namespaces and a manual bridge between them. This is where most teams start to bleed. We've gotten this wrong before: we built a routing system that emitted trace IDs to one place, agents to another, and left a junior engineer at midnight trying to stitch them together by hand.
The fix requires a correlation ID contract that spans from the API entry point through every tool call, including into Vercel Connect. Read more about cache-reason logs as an observability pattern to see how granularity compounds the problem across retrieval layers too.
The Correlation ID Contract We Now Ask Every Agent To Honor
Start with a single agent_run_id generated at the entry edge—your API route, your queue consumer, wherever the agent's turn loop starts. Never regenerate it downstream. Pair it with turn_id and tool_call_id as a 3-tuple. Pass all three in every outbound header: x-agent-run-id, x-agent-turn-id, x-tool-call-id.
When you call Vercel Connect, inject x-agent-run-id so the connector's runtime events inherit your agent's trace context. Vercel doesn't use it yet, but it will flow through their logs and your own stream, and when you export Connect's runtime events to your log backend, that ID is already there.
Your structured log schema should look like this: {run_id, turn_id, tool, connector, status, latency_ms, tokens_in, tokens_out, cost_usd}. Log the tokens the LLM spent planning between tool calls alongside the tool call itself, not as a separate event. One agent turn should emit one summary log line that lets you eyeball the whole turn in 10 seconds. Reason cost, tool cost, outcome, and error class in one place.
Store 30 days hot in Clickhouse or Axiom. Archive the rest to S3. Typical volume is 2–5KB per turn. At 50 turns per agent run and 100 agent runs per hour, you're looking at 10–25MB a day. Nothing that breaks a budget, but enough that you'll want cheap cold storage.
See how this pattern applies upstream in your token routing layer at scale in our look at agent architecture and the token routing problem.
Failure Modes You Only See With Agent-Scoped Traces
Silent partial success: a connector returns 200, the agent interprets the payload as "operation complete," and the next tool call proceeds on stale data. Connector logs show the 200. Agent logs alone won't show the misinterpretation. A correlation trace connects them.
Retry storms: the LLM sees a tool call fail (even though the connector already handled the 429 and retried internally) and re-plans to send another request to the same connector anyway. The second call hits the rate limit too. Now you have two retries, two token refreshes, doubled cost, and a 30-second turn that should have been 5 seconds.
Token refresh race: Connect refreshes a token mid-turn. Your agent has cached the old response from a previous call to the same connector. The next turn's reasoning step uses stale credentials or a stale permission set and the operation fails two turns later. Connector logs show the refresh. Agent logs show the failure. A correlation trace shows they're the same incident.
Cost blowouts from reasoning loops that never hit a connector. The LLM spends 40k tokens planning because your prompt didn't give it clear enough constraints. Connector logs see nothing. Agent logs alone show the cost, but not why. You need both.
The phantom timeout: your Vercel Connect timeout is 30 seconds. Your agent's overall turn budget is 90 seconds. A tool call hits the 30-second timeout, the agent sees the failure, re-plans, and makes another call. The second call also times out. Now the agent has burned 60 seconds and three LLM calls on a single tool invocation. Connector logs show two timeouts. Agent logs show a confused turn. A correlation trace shows it was a systematic timeout cascade, not a fluke.
For concrete production examples, see the HP and OpenAI Frontier partnership case study on agent observability.
What To Instrument This Week
Emit agent_run_id at the entry edge and never regenerate it downstream. Pass it into Connect via x-agent-run-id. Wrap every Connect call in a lightweight adapter function that injects the headers and mirrors Connect's runtime events into your own log stream so you have a unified schema to query.
Add a single "agent turn summary" log line. Inputs, tool calls, cost, outcome, error class. If your turn summary line is longer than two lines of JSON, you have too many fields.
Build one dashboard query: "Show me all turns where any downstream call failed, grouped by tool." Run it. If the results are noisy, you have a tool reliability problem or a misunderstanding about what your connector is supposed to return. Either way, that's the priority.
Run a game day. Kill a token mid-turn. Time how long it takes an on-caller to find the root cause. If the answer is "more than five minutes," add x-agent-run-id to every Connect call this sprint and time it again. If the answer is "a lot less," you've justified the instrumentation cost.
The Closing Move
Pick your noisiest agent in production. Add agent_run_id, turn_id, and tool_call_id headers to every Vercel Connect call. Emit one structured turn summary log line per agent turn. Run one production incident with this data available. Measure your MTTR. If it drops by 10 minutes or more, you've found a pattern worth shipping to the rest of your fleet. If it doesn't move, you may have a different problem—maybe observability isn't the bottleneck, or maybe your agent's failure modes don't surface cleanly in logs at all. Either way, you'll know. When you're ready to scale this across your agent stack, we can help.