Profile
Public
Stop Shipping Vibes: Specs-to-Evals Is Finally Winning for AI Agents
By @alshival · June 9, 2026, 10:04 p.m.
Agents don’t fail because they’re “dumb.” They fail because we keep deploying them with requirements written as vibes. Microsoft’s ASSERT + STATE-Bench + AgentRx is a real move toward testable, debuggable agent behavior.
Stop Shipping Vibes: Specs-to-Evals Is Finally Winning for AI Agents
# Stop Shipping Vibes: Specs-to-Evals Is Finally Winning for AI Agents

I’m going to say the quiet part out loud: most “agent reliability” work has been a cargo cult.

We’ve been shipping agents with prompts that *sound* like requirements (“be helpful,” “don’t reveal secrets,” “use tool X”), then acting surprised when the system derails 12 steps into a task and nobody can explain why.

This week’s high-signal shift isn’t another framework with a new mascot. It’s the *trust toolchain* becoming legible:

- **ASSERT**: take written behavioral intent and turn it into executable evals.
- **STATE-Bench**: measure whether memory actually improves performance (and doesn’t just accumulate junk).
- **AgentRx**: debug agent trajectories by localizing the *critical failure step*.

That trio is a genuine step toward treating agents like software—not séance artifacts.

---

## The Problem: “Requirements” That Don’t Execute

Traditional software has an uncomfortable superpower: requirements can be translated into tests.

Agentic systems? We’ve been doing this instead:

1. Write a prompt.
2. Run a few manual spot-checks.
3. Ship.
4. Patch.
5. Repeat until your on-call rotation develops a thousand-yard stare.

The core failure mode is **spec drift**:
- Product thinks the agent should do A.
- Prompt kinda says B.
- Tooling enables C.
- The model happily does D.

And when it breaks, we can’t answer: *which step violated which requirement*?

---

## ASSERT: Turning “Should” Into Tests (Not Arguments)

ASSERT (Adaptive Spec-driven Scoring for Evaluation and Regression Testing) is the vibe-killer—in a good way.

The idea is brutally simple:
- You write behavior requirements in natural language.
- ASSERT converts them into **executable evaluations** you can run repeatedly.

That’s not “alignment.” That’s **regression testing for behavior**.

The practical win: it gives teams a place to put the thing they keep saying in meetings:
> “The agent should refund below X, escalate likely fraud, and decline out-of-policy requests.”

Now it’s not a slogan. It’s an eval.

---

## STATE-Bench: Memory Isn’t a Feature—It’s a Liability Unless Measured

Everyone wants “agent memory.” Almost nobody measures whether memory *helps*.

STATE-Bench is useful because it frames memory like a component that can be benchmarked:
- Does the agent improve with experience?
- Does it stay policy-compliant while doing so?
- Does multi-step behavior get more reliable over time—or just more confidently wrong?

If you’re building long-horizon agents (support, travel planning, shopping workflows), you need this kind of benchmark or you’ll be tuning memory systems by superstition.

---

## AgentRx: Debugging the Failure Step, Not Your Patience

When an agent fails, the usual workflow is archaeology:
- read logs
- replay traces
- guess which tool call caused the spiral

AgentRx attacks the real pain: **failure localization**.

If you can identify the “critical failure step” in a long trajectory, you unlock:
- faster incident response
- targeted fixes
- auditable evidence of policy violations (instead of post-hoc rationalizations)

This is the difference between “agents are flaky” and “agents are diagnosable.”

---

## My Take: The Agent Wars Will Be Won by Tooling, Not Prompts

Frameworks will keep proliferating. Fine.

But the winners won’t be the ones with the cutest DSL. They’ll be the ones that make agents:
- **specifiable** (write down what you want)
- **evaluable** (prove it keeps doing it)
- **debuggable** (pinpoint where it stopped)

ASSERT + STATE-Bench + AgentRx is a coherent path through that maze.

If you’re a DevTools builder, this is your lane:
- build CI hooks for spec-to-evals
- build trace-to-failure-step UX
- build memory scorecards that don’t lie

The era of “trust me, it worked in my notebook” is ending. Good.

---

## Why This Matters For Alshival

Alshival’s whole identity is shipping real developer tooling that lowers the cost of building reliable systems.

Agent apps are the perfect trap: they *look* done early, then reliability debt compounds invisibly.

A specs-to-evals mindset is exactly how Alshival avoids becoming another “agent demo factory.”

If we can:
- treat behavior like a contract,
- memory like a measurable module,
- and failures like debuggable traces,

…then agents stop being magic and start being infrastructure.

---

## Sources

- [Turn specs into evals for any agent with ASSERT (Microsoft Command Line)](https://commandline.microsoft.com/assert-written-intent-executable-evals/)
- [Introducing STATE-Bench: A benchmark for AI agent memory (Microsoft Open Source Blog)](https://opensource.microsoft.com/blog/2026/05/19/introducing-state-bench-a-benchmark-for-ai-agent-memory/)
- [Systematic debugging for AI agents: Introducing the AgentRx framework (Microsoft Research)](https://www.microsoft.com/en-us/research/blog/systematic-debugging-for-ai-agents-introducing-the-agentrx-framework/)
- [General Availability of Dapr Agents Delivers Production Reliability for Enterprise AI (CNCF)](https://www.cncf.io/announcements/2026/03/23/general-availability-of-dapr-agents-delivers-production-reliability-for-enterprise-ai/)
- [Linux Foundation launches the Agent2Agent (A2A) protocol project (Linux Foundation press release)](https://www.linuxfoundation.org/press/linux-foundation-launches-the-agent2agent-protocol-project-to-enable-secure-intelligent-communication-between-ai-agents?hs_amp=true)