The ✗ at the bottom of our column is deliberate. It is what makes the rest of it credible.
Keep your observability tool.
This is not a replacement for the thing you use to debug a broken request at two in the morning. It is the layer above it, built for the person who paid for the agent, and it is where their complaints turn into something you can act on.
Different jobs, different audiences.
| Capability | AgentSight | Dev observability |
|---|---|---|
| Built for the client, not the developer | ✓ | ✗ |
| Client dashboard access | ✓ | ✗ |
| White-label / own subdomain | ✓ | ✗ |
| Embeddable in your product | ✓ | ✗ |
| Client→dev tickets on a conversation | ✓ | ✗ |
| Feedback with sentiment | ✓ | ✗ |
| Shareable transcripts | ✓ | ✗ |
| Client-ready PDF reports | ✓ | ✗ |
| Engagement & behaviour analytics | ✓ | ✗ |
| Token & cost tracking | ✓ | ✓ |
| Raw trace data via API | ✓ | ✓ |
| Data export | ✓ | ✓ |
| Trace debugging UI | ✗ | ✓ |
AgentSight records complete OpenTelemetry spans and serves them through its API, so the raw data is there. But the dashboards are built for client visibility, not for stepping through a failing request, and pretending otherwise would waste your time and ours.
If you already run one of these, nothing here asks you to stop.
They watch the request. We watch the relationship.
A trace
Lives as long as a request. Answers “what did this call do, and why was it slow?” Read by the person who wrote the code, usually while something is on fire.
A conversation
Lives as long as your customer’s problem, hours, days, across restarts and deploys. Answers “is this working, and is anyone happy?” Read by the person who paid for it.
The fair objections.
We already have an observability tool.
Keep it. That one is for you; this one is for your client, and it is where a vague complaint becomes a ticket attached to a specific exchange. They solve different problems for different people.
Isn't this just a dashboard on top of spans?
The dashboard is the visible part. Underneath it is a conversation store you can query, with a permission model built so a non-employee can be let into it safely. That access model is the product.
Can we use both?
Yes, and most teams should. Instrumenting for AgentSight does not remove or interfere with any other tracing you run.
Why not just build this ourselves?
You could. The dashboard is a few weeks; the parts that take the time are per-tenant branding, field-level visibility rules, scoped embed tokens with live origin checks, and a ticket model that a client can safely be given. That is the bit that is never worth building twice.
Do you integrate with our existing tool?
Not today. An agent profile can record which platform you use, but that is a stored field, not a live connector, and we are not going to imply otherwise.
Add the layer your client is allowed to open.
- Full dashboard on the free plan
- No card required
- Model spans never carry prompts