Open-source AI agent monitoring platform. Latitude automatically detects all the ways your agents fail at scale, and gives your coding agent the tools to fix it.
Replies
Best
Solving one of the most difficult parts when shipping AI agents!!! How to extract bugs, fixes and improvements from your traces...
Great work! How does this connect back to the development workflow, any process to do evals to validate the issue is actually resolved before deploying?
the framing of agent conversations as qualitative data is really sharp. most teams just look at error rates and latency, but the actual content of what your agent says to users is where the real failure modes hide. curious how you handle the evaluation of subjective quality — like when an agent is technically correct but the response still feels wrong to the user?
Report
The useful bit here is closing the loop from failure mode to a runnable fix, not just another trace dashboard.
For agent monitoring, I’d want each clustered issue to produce a small acceptance case: trigger, tool/write that failed, expected boundary, and proof the fix changed behavior. Is that what the MCP server hands to the coding agent?
Report
Great product Curious, for teams which are running multiple agents across different use cases, does Latitude monitor them all in one dashboard, or does each agent need its own separate set up?
Report
being open source for this category is a meaningful trust signal, since teams running agents in production are often sending genuinely sensitive trace data through whatever observability tool they pick. curious whether open source here means fully self-hostable with no dependency on Latitude's own infra, or open source code but the actual product is mainly used as a hosted service, those are pretty different commitments for a team that cares about where their trace data lives
Report
The historical tracking limitation, only capturing sessions forward from installation, is worth flagging more prominently for teams evaluating this. Most agent debugging investigations start with "something went wrong last week, what happened?" If that window predates the install, you're flying blind on the incident that prompted the evaluation in the first place. Have you considered a replay or import mechanism for existing log formats (LangSmith traces, OpenAI logs) so teams can backfill context on historical incidents, even if the clustering analysis only applies going forward?
Replies
Solving one of the most difficult parts when shipping AI agents!!! How to extract bugs, fixes and improvements from your traces...
This team rocks 🚀🤘
oqoqo
Great work! How does this connect back to the development workflow, any process to do evals to validate the issue is actually resolved before deploying?
StartupBase
Logs vs issues is such a clean way to frame it. Nobody actually reads logs. Failure modes with evals attached is the thing you fix.
AISA (aisa.to) AI Fluency Assessment
the framing of agent conversations as qualitative data is really sharp. most teams just look at error rates and latency, but the actual content of what your agent says to users is where the real failure modes hide. curious how you handle the evaluation of subjective quality — like when an agent is technically correct but the response still feels wrong to the user?
The useful bit here is closing the loop from failure mode to a runnable fix, not just another trace dashboard.
For agent monitoring, I’d want each clustered issue to produce a small acceptance case: trigger, tool/write that failed, expected boundary, and proof the fix changed behavior. Is that what the MCP server hands to the coding agent?
Great product
Curious, for teams which are running multiple agents across different use cases, does Latitude monitor them all in one dashboard, or does each agent need its own separate set up?
being open source for this category is a meaningful trust signal, since teams running agents in production are often sending genuinely sensitive trace data through whatever observability tool they pick. curious whether open source here means fully self-hostable with no dependency on Latitude's own infra, or open source code but the actual product is mainly used as a hosted service, those are pretty different commitments for a team that cares about where their trace data lives
The historical tracking limitation, only capturing sessions forward from installation, is worth flagging more prominently for teams evaluating this. Most agent debugging investigations start with "something went wrong last week, what happened?" If that window predates the install, you're flying blind on the incident that prompted the evaluation in the first place. Have you considered a replay or import mechanism for existing log formats (LangSmith traces, OpenAI logs) so teams can backfill context on historical incidents, even if the clustering analysis only applies going forward?