Microsoft Open Sources ASSERT: After the Behavior Specification Is Written, the Evaluation Script Comes with It

The most headache-inducing part for people developing intelligent agents is probably writing evaluations. Getting features to work is just the first step—but how do you prove that your agent doesn’t crash in edge cases, doesn’t flatter indiscriminately, doesn’t misuse tools, and doesn’t give dangerous advice? The traditional approach is to manually assemble a test suite and then manually review cases. Yesterday (June 2), Microsoft released something new that aims to eliminate this pain point: an open-source framework called ASSERT, short for Adaptive Spec-driven Scoring for Evaluation and Regression Testing.

Its core operation is simple: compile behavioral specifications written in natural language (like PRDs, policy documents, or system prompts) directly into a complete executable evaluation pipeline. From test scenarios, datasets, and evaluation metrics to the final scorecard—all automatically generated and then run on the target model, application, or agent.

It sounds like another “LLM as Judge” toolkit, but ASSERT’s design premise is a bit different—it treats behavioral specifications as first-class inputs for evaluation, not as background context. This is the reverse of what most existing evaluation frameworks do.

Four Phases: From a Single Specification to a Complete Scorecard

ASSERT breaks the evaluation process into four pipeline stages, each of which can be viewed and modified independently:

Phase 1: Specification Refinement. Given a broad behavioral description—like “Customer service agents should not proactively promise discounts”—it first decomposes this vague phrasing into precise conceptual rules, then converts them into an editable taxonomy of permitted/prohibited behaviors. This becomes the foundation for all subsequent test cases.

Phase 2: Layered Test Generation. Developers specify several dimensions—task type, user role, available tools, contextual conditions, and so on. ASSERT combines these dimensions to generate layered test cases covering:

• Single-turn prompts (basic Q&A)
• Multi-turn dialogues (contextual conversations)
• Benign interactions (typical user behavior)
• Adversarial probes (red-teaming attacks)

Phase 3: Execution and Trace Logging. The generated test cases are run against the target system, with the full execution trace recorded—including every tool call and intermediate decision. For agent evaluation, this is crucial—many problems occur not in final outputs but during intermediate actions.

Phase 4: Scoring and Adjudication. Each trace is scored against the taxonomy, producing outputs such as pass/fail labels, rationales, cited policy clauses, and the specific turn or action involved. This last detail is important: you can pinpoint “Rule 4.2 was violated during the 3rd search_db call” instead of getting just a bland overall score.

Two Validation Studies: Higher Coverage and LLM-Human Agreement of 80–90%

The Microsoft team performed two comparative studies to show ASSERT isn’t just vaporware.

The first is a coverage study. The baseline is the mainstream “generate evaluation sets directly from intent descriptions.” ASSERT achieves broader coverage across multiple behavioral categories—including social bias, sycophancy, task fidelity, proper tool use, and unsafe or unhealthy advice. In summary:

• Surfaces more edge cases worth inspecting
• Better distinguishes strong from weak systems (greater performance separation)
• Reveals more unique failure patterns

The second is LLM Judge vs. Human Review. The use of LLMs as evaluators is controversial in the benchmarking community, but Microsoft provides some data: LLM-human agreement is typically 80–90%, while inter-human agreement is around 90%. In other words, LLM judges can approach the lower bound of human consistency but are not yet fully trustworthy—especially in subtle policy contexts or specialized domains, human oversight is still necessary.

This number is valuable because it doesn’t oversell—the team admits where caution is still needed.

Applicability: The Clearer the Behavioral Definition, the Better

Microsoft also drew boundaries for ASSERT's best-fit use cases. ASSERT works best in scenarios with well-defined and clearly constrained behavior—for example, complete policy documentation, explicit tool whitelists, and clear boundary descriptions. The more detailed the specification, the more accurate the generated test cases.

Conversely, if your agent’s purpose is vague (“be a helpful assistant”), ASSERT can’t save you—garbage in, garbage out still applies in evaluation.

Several additional notes for developers:

1. Don’t treat the aggregate score as the conclusion. Microsoft explicitly states that the failure cases and execution traces are the most valuable outputs—they show exactly where and why the system failed.
2. It cannot replace human judgment or domain experts. ASSERT’s goal is faster, clearer, more iterative evaluation—not removing humans from the loop.
3. It cannot replace telemetry data. Live traffic feedback remains indispensable.

In Context: Microsoft’s Recent Agent Safety Toolbox

ASSERT wasn’t released in isolation. Over the past few months, Microsoft has been very active in the “agent governance and safety” area:

• PyRIT: an automated red team framework for security researchers
• Rampart: an engineer-focused tool built on PyRIT that converts red team findings into repeatable automated tests for CI/CD
• Clarity: a design-time framework that audits an agent’s assumptions before coding; conversations are stored in .clarity-protocol/ directories in repositories—diffable in PRs
• Evals for Agent Interop: a starter kit for enterprise-grade benchmarks of agent interoperability focusing on email, calendar, and document collaboration
• ASSERT: today’s focus—spec-driven evaluation generation

The underlying logic is clear—to make AI safety and evaluation continuous engineering practices rather than one-time pre-launch checks. Ram Shankar Siva Kumar, founder of Microsoft’s AI Red Team, summarized it well: “AI safety must become a continuous engineering discipline, not a periodic inspection point.”

ASSERT’s role in this ecosystem is automating the “specification-to-test” gap. Clarity covers “decide what to build,” Rampart handles “continuously test for security issues,” and ASSERT handles “continuously test for behavioral compliance.” The three complement each other.

How It Differs from Similar Frameworks

The agent evaluation space already has many players. Academia has frameworks like IntellAgent, which generate dialogue benchmarks from corporate policy graphs. Tech companies also have proprietary internal pipelines.

ASSERT differs mainly in two ways:

1. Editable Behavioral Taxonomy. Many frameworks hardcode their behavior taxonomies; ASSERT exposes them as editable artifacts—versionable and reviewable. This is critical for enterprise teams that need compliance sign-offs—you can align the taxonomy with legal or compliance departments instead of handing them opaque test cases.

2. Layered Case Design. The mix of single-turn, multi-turn, benign, and adversarial tests measures not only “was the answer correct” but also “did the agent stick to rules under adversarial pressure.” This matters because agents often fail mid-dialogue rather than in first turns.

Of course, a few caveats: first, the framework heavily depends on the underlying LLM’s capacity—every step (refinement, test generation, scoring) calls the model, so costs are nontrivial; second, while 80–90% judge agreement is solid, it’s insufficient for high-stakes domains (medical, financial, legal), where human sampling remains necessary; third, adversarial test strength still depends on the generation model’s creativity—real prompt-injection tricks require expert red teams to uncover.

Getting Started

The code is open-sourced on GitHub under responsibleai/ASSERT, and the project site is aka.ms/AS. The process is entirely spec-driven: you just provide your behavioral specification along with the target system’s interface (API endpoint or local model), and it runs.

For developers in China, combining it with an aggregator like OpenAI Hub is convenient: ASSERT-generated tests often need to be run repeatedly across multiple models for cross-model comparison. A unified API key that connects GPT, Claude, Gemini, DeepSeek, and others greatly increases iteration efficiency, avoiding the need to maintain separate integration layers.

A Few Thoughts

Agent evaluation has evolved clearly over the past two years—from “checking for accuracy” to “checking behavioral patterns,” from “one-off benchmarks” to “continuous regression testing,” and from “generic test sets” to “spec-driven custom cases.” ASSERT stands at this stage, offering an engineering approach that turns a company’s own PRDs and policies directly into evaluation inputs.

It won’t make evaluation easy—evaluation never is—but it connects specifications, test cases, traces, and judgments into one chain, enabling finer-grained iteration. For enterprise teams deploying agents under compliance constraints, it’s worth trying out.

For individual developers, its practical impact is smaller—but the underlying four-phase methodology is still worth learning. Even without ASSERT, following its order of operations will yield more reliable evaluations than jumping straight into test writing.

References

• ITHome: Microsoft Releases ASSERT Open Source Framework – A Chinese introduction to the ASSERT framework with detailed phase diagrams and validation data
• GitHub: responsibleai/ASSERT – Official repository for ASSERT
• Zhihu: LLM-based Agents Evaluation Survey – Overview of agent evaluation research, including comparisons with frameworks like IntellAgent