Product
The independent acceptance layer for AI agents
DialogAssert sits between what your organisation approved and what your agent actually did.
Approved controls
Business-owned expectations with owners, versions, evidence requirements and severity. The control is an artefact the organisation approves, not a test an engineer wrote.
Journey execution
Real multi-turn interactions run repeatedly against the actual target agent, in the environment you deploy — not a replay of a captured transcript.
Evidence interoperability
Existing traces and APIs rather than a DialogAssert-specific instrumentation universe. Your telemetry stays where it is.
Assurance engine
Deterministic controls where the evidence allows it; narrow semantic evaluation only where interpretation is genuinely necessary. Each finding names which was used.
Approved baseline
What passed previously versus what changed in the candidate. The question is not whether an agent is good, but whether this change made an approved system worse.
Review history
Confirmed findings, false positives, accepted exceptions and severity changes accumulate. Over time this is what makes the judgement trustworthy rather than merely automated.
The control set
The plain-language authoring experience stays. What changes is what the enterprise is actually creating: an approved, versioned definition of acceptable behaviour, with an owner and a record of who signed it off.
control_set: id: selected-card-only owner: Card Operations version: 7 status: approved approved_by: - Cards Product - Customer Operations Risk approved_at: 2026-08-21 controls: - id: confirm-before-block expectation: Agent obtains customer confirmation before freezing a card. severity: high evidence_required: - conversation - action_sequence - id: selected-card-only expectation: Only the card selected by the customer may be frozen. severity: critical evidence_required: - entity_selection - action_argument - post_condition
Discovery can tell DialogAssert that “freeze card” is currently a tool namedfreeze_debit_card. Only the approved control set can say that freezing requires confirmation.
Assurance coverage
Two different questions deserve two different answers. What did the agent get wrong, and what are we currently capable of proving?
Approval state is unavailable for dispute submission.
This does not indicate that the agent failed. This control could not be evaluated.
An assurance gap is a finding about the environment
When a required piece of evidence is missing, DialogAssert says so rather than guessing. That tells an AI platform or risk team something useful: your testing standard requires evidence of approval state, and this agent's instrumentation cannot provide it.
That is not an accusation against the agent. It is a control-gap finding about the environment, and it is usually actionable within a sprint.
What “independent” means
DialogAssert separates the acceptance standard from the system under test.
Your agent can expose how it should be observed — its APIs, traces and evidence sources. It cannot redefine what counts as acceptable behaviour for the release.
The system under test can teach DialogAssert how to observe it. It does not get to define what “correct” means.
What it does not mean
- Not a third-party audit opinion. We produce technical evidence, not an attestation.
- Not merely a separate model. Most controls are settled deterministically, with no model in the loop at all.
- Not independence from you. Your process owners write the controls. The independence is from the implementation, not from your organisation.
Which environments we have actually run
Not every adapter is equally mature, and presenting them as if they were is the fastest way to lose a technical evaluation. Three tiers, stated plainly.
| Environment | Maturity | What that means |
|---|---|---|
| LangGraph Agent Server + LangSmith OTel + Jaeger | Production-shaped validated | Run end-to-end against a live third-party deployment, without modifying the agent. |
| Generic HTTP agent + OTel trace backend | Production-shaped validated | Run end-to-end on a materially different stack from the first. |
| OpenAI Agents SDK · LangChain · local Python | Tested | Implemented against documented interfaces and exercised against stubs, not yet against a customer deployment. |
| WebSocket · A2A · MCP | Experimental | Implemented, unexercised outside our own environment. We would not put a design partner on these yet. |
We would rather show you two stacks we have genuinely run than nine we have not.
What changes
| Traditional eval platform | DialogAssert |
|---|---|
| “Is this output good?” | “Is this release acceptable?” |
| Test belongs to engineering | Control belongs to the business or process owner |
| Implementation often defines context | Expectation remains independent |
| Score | Release evidence |
| Missing trace often becomes failure or no data | Explicit inconclusive result |
| Current run | Approved baseline → candidate |
| Tool called | Outcome can be verified |
Bring one workflow. We'll turn it into an assurance control.
A working session is usually more useful than a generic demo.