Traccia is a vendor-neutral AI Agent Control Plane built for teams running autonomous agents in production. Observe agent behavior, evaluate performance, govern actions with policies and runtime controls, and maintain an auditable trail of what happened. Built with an open, developer-first SDK and OpenTelemetry, Traccia works across models, frameworks, and existing observability stacks—so teams can control their agents without being locked into a single AI vendor.
We’ve been building Traccia because we kept seeing the same gap with AI agents: once an agent can call tools, make decisions and take actions, a traditional trace can tell you what happened — but not whether that action was acceptable.
With traditional software, an execution usually follows a path defined by the developer. Agents are different. They can reason, choose tools, change their path and take actions we didn’t explicitly define.
That creates a new infrastructure problem for teams deploying agents in production:
What did the agent do? Why did it do it? Was it allowed to? Which policy and permissions applied? And can we prove what happened afterwards?
Traccia is our AI Agent Control Plane — a vendor-neutral layer to observe what agents do, evaluate how they behave, govern what they’re allowed to do, and audit what happened.
We’ve open-sourced the Traccia SDK and built it developer-first, with OpenTelemetry at the foundation. It works across models and agent frameworks, so teams can add observability and governance without being locked into a single AI vendor. We’re still early, and we’re building this alongside developers and teams actually deploying agents.
I’d especially love feedback from people running agents in production:
What are you using today to debug agent behaviour? How are you evaluating agents? And more importantly — how do you control what an agent is allowed to do?
We’re also making it easier to try Traccia during the launch.
@busmark_w_nika Thank you for a great question. Yes — we’ve seen this particularly with MCP-based workflows. An agent can get into a pattern of repeatedly calling tools, sometimes far beyond what was expected, and the workflow can continue consuming time and tokens without actually making progress.
That’s why we have policies around things like maximum tool calls, specific model calls, and other execution constraints. The idea is to detect and enforce those limits at the agent execution layer rather than only discovering the problem after the run is over.
With agents, an “anomaly” isn’t necessarily a failed run — sometimes it’s a run that is technically working but doing far more than it should.
I’m one of the makers of Traccia. If you’ve ever watched an agent take a tool call you didn’t expect and then scrolled a 2,000-span trace trying to answer “was that even allowed?” - that’s the pain that started this.
Full-fidelity traces across models/agent frameworks
Eval path: prompts → datasets → scorers → experiments before you promote
Runtime governance: policies + evidence so “observe” isn’t the end of the story
Who this is for Teams putting agents in production - not demos. If your stack already tells you what happened, but not whether it should have happened, you’re our ICP.
One ask If you run agents in prod, comment with your current stack for:
debugging a bad tool call
deciding promote vs rollback
blocking an action at runtime
Even “we use X and it’s fine/it sucks because Y” helps more than a silent upvote.
Trying Traccia today? Platform is open - use coupon TRACCIAPH for 3 months free. I’ll be in the comments all day and will answer everything personally.
@thisiskp_ Thanks KP! That’s exactly the problem we’re seeing — once teams move beyond a single framework, managing what agents can actually do gets messy pretty quickly. We are actively working in the policy/enforcement layer: giving teams a consistent way to control agent actions across frameworks and tools. Would love to hear what you’re seeing at Netlify as wel !
Traccia
We’ve been building Traccia because we kept seeing the same gap with AI agents: once an agent can call tools, make decisions and take actions, a traditional trace can tell you what happened — but not whether that action was acceptable.
With traditional software, an execution usually follows a path defined by the developer. Agents are different. They can reason, choose tools, change their path and take actions we didn’t explicitly define.
That creates a new infrastructure problem for teams deploying agents in production:
What did the agent do? Why did it do it? Was it allowed to? Which policy and permissions applied? And can we prove what happened afterwards?
Traccia is our AI Agent Control Plane — a vendor-neutral layer to observe what agents do, evaluate how they behave, govern what they’re allowed to do, and audit what happened.
We’ve open-sourced the Traccia SDK and built it developer-first, with OpenTelemetry at the foundation. It works across models and agent frameworks, so teams can add observability and governance without being locked into a single AI vendor. We’re still early, and we’re building this alongside developers and teams actually deploying agents.
I’d especially love feedback from people running agents in production:
What are you using today to debug agent behaviour?
How are you evaluating agents?
And more importantly — how do you control what an agent is allowed to do?
We’re also making it easier to try Traccia during the launch.
3 months free with coupon code: TRACCIAPH
minimalist phone: reduce your screentime
Did there occur any specific cases with AI agents that you could label as anomaly within their process?
Traccia
@busmark_w_nika Thank you for a great question. Yes — we’ve seen this particularly with MCP-based workflows. An agent can get into a pattern of repeatedly calling tools, sometimes far beyond what was expected, and the workflow can continue consuming time and tokens without actually making progress.
That’s why we have policies around things like maximum tool calls, specific model calls, and other execution constraints. The idea is to detect and enforce those limits at the agent execution layer rather than only discovering the problem after the run is over.
With agents, an “anomaly” isn’t necessarily a failed run — sometimes it’s a run that is technically working but doing far more than it should.
Traccia
Hey Product Hunt 👋 We’re live.
I’m one of the makers of Traccia. If you’ve ever watched an agent take a tool call you didn’t expect and then scrolled a 2,000-span trace trying to answer “was that even allowed?” - that’s the pain that started this.
What ships today
Open-source SDK (Python + Node), OpenTelemetry-native
Full-fidelity traces across models/agent frameworks
Eval path: prompts → datasets → scorers → experiments before you promote
Runtime governance: policies + evidence so “observe” isn’t the end of the story
Who this is for
Teams putting agents in production - not demos. If your stack already tells you what happened, but not whether it should have happened, you’re our ICP.
One ask
If you run agents in prod, comment with your current stack for:
debugging a bad tool call
deciding promote vs rollback
blocking an action at runtime
Even “we use X and it’s fine/it sucks because Y” helps more than a silent upvote.
Trying Traccia today? Platform is open - use coupon TRACCIAPH for 3 months free. I’ll be in the comments all day and will answer everything personally.
https://traccia.ai
- Aditya (and the Traccia team)
Netlify
A vendor-neutral control plane for managing AI agents is exactly what dev teams need as multi-framework setups take off. Great build!
Traccia
@thisiskp_ Thanks KP! That’s exactly the problem we’re seeing — once teams move beyond a single framework, managing what agents can actually do gets messy pretty quickly. We are actively working in the policy/enforcement layer: giving teams a consistent way to control agent actions across frameworks and tools. Would love to hear what you’re seeing at Netlify as wel !