Query agent runs and sessions from The Context Company in Sazabi

Last verified on Nov 8, 2026.

When an AI agent misbehaves in production, the application logs usually look fine. The model answered, the tool endpoint returned, the HTTP status was 200. What went wrong lives inside the run: which step called which tool, with what arguments, and what the model did with the result.

The Context Company records those runs and sessions for agent products. Its MCP server lets the Sazabi agent, part of Sazabi's AI-native observability and security platform, pull them into the thread where you are already reading service logs, so one conversation can cover both the infrastructure and the agent behavior.

What the Sazabi agent can do with The Context Company

The connector calls The Context Company's hosted MCP server at https://api.thecontext.company/mcp. You create a read-only API key in the Context Company dashboard, and Sazabi stores it and sends it as a Bearer token. Sazabi's docs list three tools:

• insight_search takes a natural-language question and returns a written answer. The Context Company describes it as a multi-step analytics agent over your telemetry, and says each finding links to the runs behind it.
• get_agent_runs returns agent runs.
• get_agent_sessions returns agent sessions.

Keys carry a tcc_key prefix and are read-only. When you create one you choose a scope: dev only, prod only, or dev plus prod. The Context Company documents write tools for its own workspace, but they need OAuth sign-in and a read-only key is rejected for them, so this connector stays on the read side. Its docs list other read tools too, such as get_agent_run for one run, so check the tool list on the connection page.

Questions it answers

• What were the most common reasons runs failed this week?
• Which tool calls returned an error while the final reply looked fine?
• What did the last five production runs cost, and which model drove it?
• Which runs belong to the session a user complained about?
• Did the failures start after the deploy I am looking at?

A worked example: a refund agent that says it succeeded

Support reports that customers are told their refund went through, but the refunds are not showing up. Your refund-service logs show a handful of POST /refunds calls returning 422. In a Sazabi thread you ask:

refund-service returned 422 on POST /refunds about 40 times since 10:30 UTC.
Use The Context Company: ask insight_search for runs in the last two hours
where a tool returned an error but the final answer said the refund was
processed, then show me the sessions for the three most recent.

The agent first confirms the window and request count from your logs. It then calls insight_search with the question. Per The Context Company's docs, the answer is a written summary with links to the underlying runs. It follows with get_agent_sessions for the affected users and get_agent_runs for the runs themselves. Back in Sazabi, it lines up the run timestamps against the 422 responses in your logs and reports which argument the model sent that the service rejected.

The result is a pair of facts you can act on: the service validation that fails, and the agent behavior that hid it. The fix usually has two parts, a stricter tool schema and a prompt change so that a tool error is reported as one. Keep in mind that insight_search queries production data only, so a staging reproduction needs the raw run tools with a key that includes dev data.

How it fits with other integrations

The Context Company is one of several sources for agent behavior. LangSmith and Langfuse cover the same layer for teams that trace with them, and AgentCat covers how agents use an MCP server you run. All of these sit near the AI frameworks category. Service logs reach Sazabi through OpenTelemetry, and the integrations index lists every method.