Agentproof

Problem Statement
Architecture
Agent Pipeline
Validation Flow

The gate itself is a UiPath coded agent written with the Python SDK, packaged and published to Orchestrator. It runs end to end as a job on UiPath Automation Cloud.
Behavioral contracts let each test case assert intent (contains_intent, does_not_contain), sentiment, response length, format compliance, and safety.
An LLM-as-judge scores each response against its contracts, catching semantic drift that a string match never could.
A severity-weighted drift score weights regressions by severity, so a critical policy failure counts far more than a cosmetic one:

$$ \text{drift} = \frac{\sum_{r \in R} w_{\text{severity}(r)}}{\sum_{t \in T} w_{\text{severity}(t)}}, \quad w = {\text{critical}:3,\ \text{high}:2,\ \text{medium}:1,\ \text{low}:0.5} $$

with thresholds of $ \text{drift} < 5\% $ for PASSED, between $ 5\% $ and $ 15\% $ for DEGRADED, and above $ 15\% $ for FAILED.

Native validation uses processes.invoke to start a target agent as a job, polls it, and reads its output, with no external endpoints required.
UiPath Agent Evaluations wire the agents under test to the platform's own uipath eval framework, with behavioral eval sets and evaluators, so they're testable with first-party tooling.
The control panel is a FastAPI app on Vercel with a cinematic /live deployment-gate experience, a per-tenant dashboard, and HTML reports. It's backed by Neon Postgres, with HMAC-signed sessions so each tenant sees only their own runs.
Secrets such as LLM keys and the database URL are read from UiPath Assets at runtime, so the agent runs cleanly on the platform.
The whole thing was built with Claude Code, through UiPath for Coding Agents, described in plain English and running in production.

🧗 Challenges I ran into

Track 3 names UiPath Test Cloud, but Test Cloud is built for deterministic automations, not coded agents. Creating test sets and test-case definitions for a coded agent hit hard walls: the API rejects packages without Studio test cases, and the toolchain has no test entrypoint type. Rather than fake it, I leaned into the platform's actual agentic-testing path, Orchestrator jobs plus UiPath Agent Evaluations, and made the integration genuine. I treated the constraint as a point of view, not a checkbox.
Making AgentProof run as a job surfaced everything you can't see locally: a localhost endpoint that was unreachable from the UiPath runtime, which I fixed with native job-to-job invocation, plus missing package dependencies and secrets that had to move from .env into UiPath Assets.
The UiPath eval evaluator format was undocumented and finicky. It routes on a "version": "1.0" field and nests configuration under evaluatorConfig. Getting a green uipath eval run meant reverse-engineering the evaluator factory.
Real-database edge cases appeared once I left mocks behind. Postgres returns Decimal, which broke the float math in the drift score until I coerced types at the boundary.

📚 What I learned

Behavioral testing is a different discipline from functional testing. "Did it return 200?" and "did it behave correctly?" are unrelated questions, and the second is the one that reaches customers.
An LLM-as-judge is only as trustworthy as its contracts. Vague criteria produce vague verdicts. Severity weighting and explicit thresholds are what turn a score into a decision.
"Native to the platform" is a high bar, and worth clearing. Running as a real job, rather than a script calling an API, is the difference between a demo and something an enterprise could actually trust.
Owning a constraint beats hiding it. The honest reframe of the track ended up being the sharpest part of the story.

🚀 What's next

Wider contract libraries, CI/CD webhook triggers so the gate fires automatically on every agent change, and richer trend analytics across an entire tenant's fleet of agents, so behavioral regressions get caught the moment they're introduced, for every agent, before anything ships.