AgentX - Evaluate AI agent, pinpoint issues, and fix with one click.

@karimbenkeroum Thank you!

@karimbenkeroum Thank you Karim, really appreciate the support! 🙏

@jared_salois Thanks! And this is a sharp one - model sovereignty is easy to claim and harder to make survive a model bump.

What transfers cleanly is the eval definition, not the score. Your dataset: the cases, the acceptance/rejection criteria, the expected results - is model-agnostic. It describes what "good" means for your task, and that doesn't change when GPT or Claude ships a new version. So you don't rebuild the eval when you switch or update a model, you re-run the same one.

What moves is the result, and that's the point rather than a bug. Swap the LLM, re-run, and the score tells you whether the new model holds up against your existing bar — same cases, same judges, apples-to-apples on quality, cost and latency. Model sovereignty isn't "switch and assume it's fine," it's "switch and get a measured answer."

The one thing you occasionally re-tune is the judge criteria, if a new model's output style shifts enough to need tightening. But that's a small adjustment, not a rebuild - the cases stay.

@jared_salois 
Good point, and thank you!

We don’t assume evals transfer perfectly across models. That’s why this layer matters.

The eval suite should stay focused on the business task, expected behavior, required fields, tool usage, and failure cases - not one model’s wording.

Switching LLMs may still need tuning, but now you can see what changed, which scenarios still pass, and what needs fixing before deploy.

So it’s not magic transfer - it’s controlled comparison instead of guessing.

@luki_notlowkey Build AI agent is just the first step. Making sure it is good enough to use in production is the real hard part. Our goal is to provide the platform that you can confidently deploy your AI agent with peace in mind.

@luki_notlowkey 
Thank you, really appreciate it! 😊

That’s exactly what we’re hearing from agent builders too - the agent layer is moving fast, but the eval / QA layer is still missing.

For GTM, we’re starting with teams already building agents for real workflows: AI agencies, agent builders, and companies moving from prototypes to production. The focus is to make evaluation easy to plug into existing agent stacks, then expand through integrations, templates, and repeatable eval suites for common use cases.

Would love to learn more about the types of agent builders you work with too.

@galdayan Great question Gal. The real evaluation should always handle the complete chain of thoughts and sub-processes.

We analyze all the data retrievals, tool uses, multi-step, and multi-agent layer. Check each one and aggregate to summarize the report.

@galdayan Exactly - that’s where things get messy fast.

For multi-step tool chains, we track the full execution path, not just the final output: each tool call, inputs, outputs, step order, and where the chain started to drift.

So if the agent fails 3-4 calls deep, the eval should show whether it was caused by the wrong tool selection, bad parameters, incorrect interpretation of a tool result, or a later reasoning mistake.

That’s the real value of eval-before-deploy: catching hidden failures before they become production issues.

@renchu_song Thank you Richard, really appreciate it!

Yes - AgentX evaluation goes beyond the final output. We evaluate the full execution path: reasoning trajectory, tool / function calls, step selection, final response, and task completion.

For multi-turn interactions, we evaluate the whole conversation as one scenario, checking context retention, decision quality, tool usage, and final business outcome.

The final answer can look right even when the agent took the wrong path, so we want evals to catch that too.

@ozandag 
Great question - handoffs are usually where multi-agent systems get fragile.

We think evals need to look at the workflow boundary between agents, not just each agent in isolation: what context was passed, what task was delegated, whether the receiving agent understood it correctly, and whether the handoff produced the expected next action.

So the failure can be flagged as a coordination issue, not incorrectly blamed on the final agent response.

@crystalmei 
Thank you!

That’s exactly where suggestions need to be tied to the trace, not just the final output.

When a failure spans multiple agent calls, the goal is to identify where the chain started drifting: bad handoff, missing context, wrong tool use, weak instructions, or a downstream interpretation issue.

Then the fix can be targeted to that step, instead of rewriting the whole workflow!

@pooran_prasad_rajanna 

Thank you so much for the support, really appreciate it! 🙏

@moon10 
Thank you, really appreciate it! 🚀

That’s exactly the use case we’re excited about - moving beyond single-purpose agents into workflows!

@xiaosong001 

We don’t see one universal source of truth. It depends on the eval: trace, tool result, final output, required fields, or human rubric.

The key is combining signals to identify where the failure actually started