Tavi is an AI coworker for deep talent search that runs inside Slack. Each customer had a separate deployment, so Tavi’s engineers were not operating one agent in one environment. They were maintaining a fleet of personalised agents, now seventy-five of them.
When the number of deployments was small, Tavi’s engineers could investigate failures one at a time. If a customer reported a problem, they would send Codex into that customer’s machine over SSH, retrieve the session logs and begin debugging.
This worked, but it created more operational work with every deployment.
“Prior to Latitude, I guess it was kind of a simple approach, but it wasn’t really effective. It just involved SSHing into each customer machine, usually at the moment of failure, to figure out and see what went wrong, which obviously doesn’t scale.”
— Savva Bojko, Founding Engineer, HeyTavi
Tavi’s developers maintained internal playbooks that explained how its coding agents should access each machine and find the relevant logs. They had to update those instructions as the infrastructure changed. Giving a coding agent access to a live customer environment also carried the risk of it restarting active sessions or modifying files.
As Tavi moved from a few deployments to dozens, its engineers decided they needed a more reliable way to monitor their fleet of agents.
One debugging layer across the fleet
To monitor the growing fleet more reliably, Tavi’s engineers began sending traces from its active personalised agent deployments into one Latitude project. Customer metadata attached to each trace allowed them to identify the relevant customer and deployment during an investigation.
When a customer reported an issue, Sav and Tom could now use Codex with Latitude’s MCP server to debug it. Codex could search the centralized traces, use the customer metadata to identify the affected deployment and retrieve the relevant session to find what went wrong.
This made debugging faster as well as more secure. Codex could find the production evidence without Tavi’s engineers guiding it through machine access and local logs, and without touching the live customer environment.
“It’s become much faster to find exactly the right logs, identify the customer and everything. Codex can find the exact failure trace in Latitude without having to add any other context.”
— Tom Robbins, CTO, HeyTavi
“In terms of keeping track of these playbooks, making sure that we get access to the machines, filtering the logs, doing all this other stuff, having to work with the agent, now we have the MCP. And we just say, ‘Go do your thing. This is what we need,’ and then it figures it out.”
— Savva Bojko, Founding Engineer, HeyTavi
From a customer screenshot to the exact production trace
Tom described a particularly simple version of this workflow.
When a customer reports a problem in a shared Slack channel, he takes a screenshot using the macOS hotkey and drops it directly into a new Codex thread. He then asks Codex to look in Latitude and explain what went wrong.
Using the information in the screenshot and the customer metadata Tavi’s developers send to Latitude, Codex can identify the personalised agent deployment and find the relevant trace without Tom manually locating the machine or providing additional log context.
Customer reports an issue in Slack → screenshot → Codex → Latitude MCP → relevant production trace → diagnosis and fix
“A customer sends us a screenshot or a message in Slack. I screen grab that, put it into a new Codex thread and just say, ‘Look in Latitude and tell me what went wrong here.’ Codex can find the exact failure trace without me adding any other context.”
— Tom Robbins, CTO, HeyTavi
The screenshot is a concrete example, but the underlying workflow is shared by Tavi’s engineers. Sav and Tom can both use Codex as the interface for investigating traces across Tavi’s personalised agent deployments, without starting every investigation by accessing the affected machine over SSH.
What changed
Before Latitude, investigating a customer problem meant:
- Identifying the affected customer machine
- Giving Codex access to it over SSH
- Loading and maintaining instructions for that environment
- Finding and filtering the local session logs
- Making sure the investigating agent did not interfere with the live deployment
With Latitude, the team can:
- Give Codex the customer report or a description of the problem
- Ask it to investigate through Latitude’s MCP server
- Use customer metadata to identify the relevant deployment
- Retrieve and analyze the production trace from a centralized source
- Diagnose the problem without beginning inside the customer’s live machine
For Tavi’s engineers, the main immediate benefit is not a measured reduction in infrastructure maintenance. It is a more reliable way to start investigations across a growing fleet, with less dependence on machine-specific access, local logs and internal playbooks.
From reactive debugging to fleet monitoring
Tavi’s current workflow often still begins when a person notices a problem or a customer reports one. The next step is to use what the team learns while debugging to monitor Tavi more proactively.
After Codex finds and diagnoses a product-specific failure, Tavi’s engineers want to ask it to create a custom signal in Latitude for that behavior. The signal could then track the same issue across deployments and notify the team if it happens again. Sav gave the example of a specific tool-call failure: instead of waiting for another customer to report it, Codex could create a monitor for that failure and watch for regressions.
Latitude supports creating custom signals through the MCP, but Tavi’s engineers had not yet implemented this workflow at the time of the interview.
Tavi’s engineers also plan to use Latitude’s custom dashboards for fleet-level reporting. Sav highlighted unit economics as a useful application, which the team does manually at the moment. Custom dashboards could bring metrics such as AI costs, cost per session and tool errors into the same place as the traces used for debugging. This was also a planned next step, not part of Tavi’s current workflow at the time of the call.
For teams operating agents across many customer environments, the lesson is straightforward: debugging each deployment independently becomes harder as the fleet grows. Centralized observability gives the team one reliable way to investigate what its agents are doing, while custom signals and dashboards provide a path toward monitoring the whole fleet more proactively.