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.
Until now, companies have focused on collecting quantitative data about their products: user counts, churn rates, conversion. Qualitative insight was reserved for corporates who could afford to hire an agency. But agents changed that. We have the single most valuable source of knowledge about our product sitting right in front of us, and we're not using it. No one at your company talks to your users as much as your agent does. Latitude exists to tap into that.
Latitude does 3 things:
1. See what your agent really does in production
Latitude clusters thousands of conversations into one clear picture: what people ask for, and where they hesitate, escalate, or drop off.
2. Catch what's breaking before users do
When your agent keeps failing the same way, Latitude collapses those moments into one signal: the problem, how often it fires, and why. It detects issues automatically, or you set your own. Either way, you hear about problems first, and evals are created automatically for each signal.
3. Fix it without leaving your editor
The MCP server brings your signals, traces, and searches straight into your coding agent. Turn real failures into a dataset and verify the fix worked before you ship.
Latitude is open source and MIT licensed. Try it at latitude.so
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?
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
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?
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?
The "gives your coding agent the tools to fix it" line is what I'd want to see in practice — most observability tools stop at surfacing the failure mode. When Latitude clusters a set of failures, how does that get back into the coding agent: an MCP server, a CLI, or a generated eval/test the agent runs against? And since it's open source, can I self-host so the production conversation traces stay in my own infra, or does evaluation route through your hosted backend?
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?
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.
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?
Honestly the part that gets me is the signal going back into the editor. i don't need another dashboard to ignore. running cc across a repo per client and the dream is catching the dumb stuff before the client does. Imho this is the right tool for people serious about AI agents!
Solving one of the most difficult parts when shipping AI agents!!! How to extract bugs, fixes and improvements from your traces...
This team rocks 🚀🤘
Congrats on the launch, Cesar! The "cluster conversations into failure modes" piece is the part I'd get the most from. One question from running agents that deliberately hand off to a human: how does Latitude tell a real failure apart from a correct escalation? In our setup the agent is supposed to stop and route anything sensitive — refunds,
account changes — to a person, so a "drop-off" there is it doing its job, not breaking. Does it learn which escalations are intended vs the agent actually giving up?
The MCP-into-the-coding-agent piece is the clever bit, and underrated in the thread so far. Most observability tools die at the dashboard — signals pile up where nobody looks, so failures just rot. Routing the signal to where the fix actually happens (the editor) is the real unlock; detection was never the bottleneck, action was.
One sharp question on that loop: when you auto-generate an eval per signal and hand it to the coding agent to fix against, how do you keep the agent from overfitting to the eval — patching the specific failing cases rather than the underlying behavior, so the cluster 'closes' but the real issue persists? Curious if there's a held-out/regression check or a human-in-the-loop on the generated evals. That's the failure mode I'd worry about most with auto-fix.
Congrats on shipping this — genuinely needed.
This is a super clean approach to agent observability! Triage is a nightmare when you're just staring at a massive, unorganized stream of logs. Grouping traces into auto-clustered issue datasets makes finding where a trajectory went wrong way faster.
How does Latitude handle automated regression testing once a fix for a specific trace issue is pushed?
My Claude-Gmail agent ghosted me at an approval gate mid-campaign and I spent way too long not knowing why, reconnecting everything, before giving up. "most tools give you logs, Latitude gives you issues" hits different when you've lived it. following.
For agent systems with non-deterministic outputs, how do you define failure in a way that's consistent enough to monitor reliably at scale?
How does Latitude differentiate a genuine failure from an agent that's thinking out loud through a messy but ultimately correct reasoning path?
While most agent tools stop at dumping logs, auto-building an eval from each failure cluster looks totally spot on! One thing I'd poke at - how do you stop those auto-evals from overfitting to the exact transcripts that triggered them instead of the general failure mode? Thanks!
The phrase all the ways your agents fail is ambitious is failure detection here pattern based on known anti patterns or does it learn failure signatures from your own agent's history over time?
the "issues not logs" framing resonates. i've lost hours scrolling through agent execution traces trying to find why something broke, only to realize the actual failure happened 6 steps earlier. how do the evals work here, do you define failure criteria upfront or does it infer patterns from the traces?
About Latitude on Product Hunt
“Fix what's breaking in your AI agent”
Latitude launched on Product Hunt on June 23rd, 2026 and earned 365 upvotes and 49 comments, placing #4 on the daily leaderboard. 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.
Latitude was featured in Developer Tools (515.4k followers), Artificial Intelligence (473.1k followers), GitHub (41.3k followers) and Data & Analytics (5.7k followers) on Product Hunt. Together, these topics include over 208.1k products, making this a competitive space to launch in.
Who hunted Latitude?
Latitude was hunted by fmerian. A “hunter” on Product Hunt is the community member who submits a product to the platform — uploading the images, the link, and tagging the makers behind it. Hunters typically write the first comment explaining why a product is worth attention, and their followers are notified the moment they post. Around 79% of featured launches on Product Hunt are self-hunted by their makers, but a well-known hunter still acts as a signal of quality to the rest of the community. See the full all-time top hunters leaderboard to discover who is shaping the Product Hunt ecosystem.
Want to see how Latitude stacked up against nearby launches in real time? Check out the live launch dashboard for upvote speed charts, proximity comparisons, and more analytics.
fmerian
Hey there, it's Cesar, founder of Latitude.
Until now, companies have focused on collecting quantitative data about their products: user counts, churn rates, conversion. Qualitative insight was reserved for corporates who could afford to hire an agency. But agents changed that. We have the single most valuable source of knowledge about our product sitting right in front of us, and we're not using it. No one at your company talks to your users as much as your agent does. Latitude exists to tap into that.
Latitude does 3 things:
1. See what your agent really does in production
Latitude clusters thousands of conversations into one clear picture: what people ask for, and where they hesitate, escalate, or drop off.
2. Catch what's breaking before users do
When your agent keeps failing the same way, Latitude collapses those moments into one signal: the problem, how often it fires, and why. It detects issues automatically, or you set your own. Either way, you hear about problems first, and evals are created automatically for each signal.
3. Fix it without leaving your editor
The MCP server brings your signals, traces, and searches straight into your coding agent. Turn real failures into a dataset and verify the fix worked before you ship.
Latitude is open source and MIT licensed. Try it at latitude.so