TruAssure

Know what your AI agents actually did, not just what they said.

TruAssure is a black-box, evidence-based quality engineering framework for AI agents: chat assistants, task agents (LangGraph, OpenAI Agents SDK, custom loops) and multi-agent workflows. It judges every checkpoint on independent evidence (the agent's tool calls as a recording proxy saw them, its handoffs, the data it changed) and compares that with what the agent claims. It runs the same scenarios under injected faults, rephrasings and repeats, and turns the results into release decisions.

pip install truassure                    # the ta / truassure commands and the library
pip install "truassure[mcp,proxy,otel]"  # plus the MCP server, the recording proxy and A2A tap, the OTel receiver

Python 3.11 or later, on Windows, Linux or macOS. MIT licence.

Five minutes, offline

ta demo                               # the whole tour on a scripted agent: no Docker, no LLM, no network
ta console --runs-dir ta_demo --open  # browse the runs, reports, comparisons and gates
ta docs --open                        # the full guide, shipped inside the package

Test your own agent

ta new task my-agent-tests            # or: ta new workflow ... / ta new chat ...
cd my-agent-tests                     # catalog.yaml, environment.py, truassure-gate.yaml, .env.example, README.md
ta validate catalog.yaml
ta run catalog.yaml --env environment:environment --repeats 3 --perturbations all
ta report latest
ta gate latest --policy truassure-gate.yaml
ta init --ci github --catalog catalog.yaml --env environment:environment   # or --ci azure

Enterprise systems

pip install "truassure[postgres]"     # or [sqlserver], [mysql], [oracle], [sql] for SQLAlchemy alone

from truassure.adapters.state.factory import make_state
from truassure.adapters.drivers.queue import QueueDriver, ServiceBusTransport
from truassure.profiles.task import task_environment


def environment(worker):
    return task_environment(
        name="claims",
        driver=QueueDriver(ServiceBusTransport.from_env(), request="claims-events", reply="claims-results"),
        state=[
            make_state("oracle+oracledb://reader:***@db:1521/?service_name=CLAIMS", schema="CLAIMS"),
            make_state("https://crm.test.example/api", resources={"cases": "/cases"}),
        ],
    )

Any SQL database SQLAlchemy supports, read-only, with tables and keys found by reflection. A factory picks the adapter from a URL or path. There are drivers for HTTP, chat, OpenAI-compatible endpoints, Azure Service Bus and Kafka. ta library lists reusable scenario packs (privacy, prompt injection, unsafe writes, payments and approvals, identity across handoffs, conversation handling, answers and boundaries, tone and policy) that a catalog includes with its own parameters; each tags its scenarios with catalogue test types.

Across initiatives

pip install "truassure[s3]"           # or [azure-blob], or [postgres] etc. for a database store; a folder needs nothing
ta push                               # share the latest run (store, initiative and team in truassure.yaml)
ta run catalog.yaml --env environment:environment --publish
ta portfolio --store s3://quality-results/truassure --csv portfolio.csv
ta console --store s3://quality-results/truassure --open

The portfolio shows every initiative and project: the latest gate verdict, pass rate, pass^k, open defects by severity, the trend, and each run's report. Nothing is shared without ta push or --publish.

The starter project connects to an agent behind HTTP. Put ta proxy in front of the agent's tools, and ta a2a between its agents, to get an independent record of every call and handoff and to inject faults.

How an agent is judged

Each checkpoint is judged at five stages, and TruAssure reports the first one that failed:

Seven evidence seams (SE-01 to SE-07) catch the failures an agent's own account hides. Examples: a call it reported that never happened, a write it never mentioned, success announced after a failure, a handoff that carries another customer's identity, and a different deployment that behaves differently.

What you get

• Profiles: conversational, task and workflow (handoffs, identity on every hop, failure containment).
• Reliability: repeats and perturbations, pass^k, robustness and flaky detection, plus fault injection in the tool server's own format.
• Change: run-by-run comparison, and deployment parity (model, host, framework) judged against run-to-run noise.
• Governance:
  • defect lists (JSON and CSV) and JUnit for CI;
  • capability packs and a release gate with per-capability thresholds;
  • a 71-type test scorecard, with each type's catalogue metrics measured or marked not measured;
  • grader calibration (Cohen's kappa), and rubric grading for tone and written policy.
• Reports: a customer-facing execution report (execution-report.html and .json): a readiness statement, KPI cards and charts, test-type and test-data coverage, persona views, findings with evidence and next actions, and the trend against the previous comparable run; personal details masked. Plus the one-file engineering report.
• Sharing: a local token-protected console and a shared store across initiatives.
• Automation: ta mcp gives an AI assistant one tool per command. GitHub Actions and Azure DevOps templates come from ta init.
• Security defaults:
  • listeners bind to 127.0.0.1 and need tokens;
  • secrets come only from the environment or .env and are never printed;
  • personal data is masked before evidence is stored, and retention is enforced.

Commands

ta <command> --help lists every option. Examples use fictitious data (Harbor Mutual).