coSTAR: Automated Testing and Refinement Framework for Production AI Agents

databricks · Tech · 2026 · source Agentic: yes · promotional bias: low · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Production AI agent testing and refinement

Databricks was developing agents that generate code, create data/AI assets, and perform long-running tasks, but early development resembled coding without tests: manual run-review-fix loops were slow, subjective, regression-prone, and unable to provide confidence across agent changes or infrastructure changes.

Constraints:

Agent runs can take minutes or tens of minutes.
Agent outputs are non-deterministic and must be judged by properties, not exact strings.
Traces can be thousands of lines long.
Human expert judgment is required for subjective quality.
Agents depend on MCP tools and infrastructure that change independently.

Architecture

Databricks built coSTAR, a coupled Scenario-Trace-Assess-Refine methodology on MLflow. Scenario definitions act as fixtures, MLflow traces capture execution, agentic judges score targeted trace properties, human-aligned judge loops calibrate judges against golden sets, and coding assistants refine agents until trusted judges pass. The same judges run in CI/nightly builds and on sampled production conversations.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  scenario-definitions["Scenario definitions"] --> test-harness["Test harness"]
  test-harness --> agent-under-test["Agent under test"]
  agent-under-test --> mcp-tools["MCP tools"]
  test-harness --> mlflow-traces["MLflow traces"]
  mlflow-traces --> agentic-judges["Agentic judges"]
  mlflow-traces --> golden-set["Golden Set"]
  human-experts["Human experts"] --> golden-set
  golden-set --> judge-alignment-loop["Judge alignment loop"]
  judge-alignment-loop --> agentic-judges
  agentic-judges --> coding-assistant["Coding assistant"]
  coding-assistant --> agent-under-test
  agentic-judges --> production-monitoring["Production monitoring"]

Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component	Role	Interacts with
`Scenario definitions`	Structured fixtures containing initial state, user prompt, and success criteria.	`Test harness`, `Golden Set`
`Test harness`	Runs scenarios against the agent under test and records MLflow traces.	`Scenario definitions`, `Agent under test`, `MLflow traces`
`Agent under test`	Production or candidate AI agent implementation being scored and refined.	`Test harness`, `MCP tools`, `Coding assistant`
`MLflow traces`	Structured recordings of tool calls, intermediate outputs, and artifacts.	`Test harness`, `Agentic judges`, `Golden Set`
`Agentic judges`	Tool-using LLM judges that inspect trace properties rather than the whole trace blob.	`MLflow traces`, `Judge alignment loop`, `Coding assistant`, `Production monitoring`
`Judge alignment loop`	Refines judges against human-scored golden examples.	`Agentic judges`, `Golden Set`, `Human experts`
`Golden Set`	Human-assessed examples used as ground truth for judge alignment.	`Human experts`, `Judge alignment loop`, `MLflow traces`
`Human experts`	Domain experts who manually score outputs and remain final arbiters of agent changes.	`Golden Set`, `Judge alignment loop`, `Coding assistant`
`Coding assistant`	Reads judge failures, diagnoses root causes, patches the agent, and reruns tests.	`Agentic judges`, `Agent under test`, `Human experts`
`MCP tools`	External tools and infrastructure dependencies whose changes are caught by the same tests.	`Agent under test`
`Production monitoring`	Runs judges on sampled live conversations for drift, failures, and cost regressions.	`Agentic judges`

Data flow

Engineers define scenarios with initial state, prompt, and expected outcomes. A harness runs the agent and persists an MLflow trace. Agentic judges inspect targeted trace properties using tools. Human-labeled golden sets align judges. Once trusted, judge failures feed a coding assistant that patches the agent and reruns the scenario suite; the same scoring infrastructure monitors CI and production traffic.

“coSTAR runs two coupled loops: one that aligns judges with human expert judgment so they can be trusted, and one that uses those trusted judges to automatically refine the agent until it passes all test scenarios.”article, stated

“Each scenario bundles the setup, the input, and the success criteria in one place, just like a test fixture.”article, stated

Why this architecture

coSTAR decouples expensive agent execution from cheap scoring by persisting traces. It also treats judge reliability as a first-class problem: judges must be aligned with human experts before automated agent refinement can be trusted.

“A key architectural decision: we decouple execution from scoring. The test harness produces traces; the judges (which we'll introduce next) score them.”article, stated

“Refining the agent is only as reliable as the judges driving it.”article, implied

Models used: MLflow agentic judges · Coding assistant · Agents under test such as Genie Code and MLflow Assistant

Scale

Databricks agents can generate thousands of lines of code and create new data and AI assets.
“These agents can perform long-running tasks, generate thousands of lines of code, and create new data and AI assets among other things.”article, stated
Automated test suites reduced verification time from two weeks to hours.
“the automated test suites have reduced the time to verify changes from 2 weeks down to hours.”article, stated
Several suites grew to hundreds of scenarios per agent.
“Several test suites have grown to hundreds of test scenarios per agent”article, stated

Alternatives considered (roads not taken)

Manual run-review-fix loops

Rejected because: They were equivalent to manual QA without tests and failed predictably.

“Early on, our development loop looked like this: run the agent, manually review its output, spot a flaw, tell a coding assistant to fix it. Repeat.”article, stated

Dump full traces into a judge prompt

Rejected because: Full traces are expensive, fragile, hard to debug, and can degrade judgment quality.

“For our agents, a single trace can be thousands of lines long. Stuffing it into a judge's context window degrades judgment quality.”article, stated

Trust judges without alignment

Rejected because: Wrong or drifting judges can greenlight bad agent behavior.

“judges who approve poor outcomes give a false sense of security.”article, stated

Patterns

`eval-driven-development` (evaluation)

Scenarios, traces, judges, and CI/production monitoring form the agent test suite.

“CI runs scenarios + judges on every change”article, stated

`llm-as-judge` (evaluation)

Databricks uses agentic judges that inspect trace properties with tools.

“we use MLflow’s agentic judges: judges that are themselves agents, equipped with tools to explore the trace selectively.”article, stated

`human-in-the-loop-gate` (workflow)

Human experts provide golden labels and remain reviewers/final arbiters for proposed agent changes.

“The engineer is still the reviewer and final arbiter of the proposed changes to the agent”article, stated

`observability-tracing` (operations)

MLflow traces record every tool call, intermediate output, and artifact for later scoring and debugging.

“Each execution is captured as a MLflow trace: a structured log of every tool call, every intermediate output, and every artifact the agent produces.”article, stated

Tradeoffs

Use agentic judges with trace tools

Chose targeted trace exploration over putting whole traces in judge context.

Rationale: Targeted tools reduce fragility and improve debuggability for long traces.

“An agentic judge that calls targeted tools is like a focused unit test. Dumping the full trace into a judge is like dumping program state into an assertion.”article, stated

Automate refinement but keep human final review

Chose coding assistant patches plus engineer arbitration over fully autonomous shipping from judge results.

Rationale: Automation saves effort, but humans still approve changes.

“this automated iteration saves considerable human effort in analyzing and improving the agent.”article, stated

Gotchas (what bit them)

Slow agent executions make naive iteration expensive.

Root cause: A single run can take tens of minutes.

Resolution: Persist traces so judges can be revised and rerun without rerunning scenarios.

“A single agent execution can take tens of minutes. There's no iterating the way a sub-second test suite allows.”article, stated

The coding assistant can overfit to a narrow scenario suite.

Root cause: A small test suite lets an implementation pass known cases but fail novel ones.

Resolution: Feed production failures back into eval and expand coverage over time.

“If the test suite doesn't cover enough cases, the coding assistant will engineer an agent implementation that aces those specific inputs but fails on novel ones.”article, stated

Infrastructure changes can break agent behavior even when the agent code is unchanged.

Root cause: Agents depend on MCP tools with independent teams and release cycles.

Resolution: Run judges nightly as integration/regression tests against the full stack.

“When a tool team ships a change that causes an agent to start failing its judges then we catch the error immediately, before it reaches customers.”article, stated

Evaluation

coSTAR evaluates agents with scenario suites, MLflow traces, deterministic checks, operational metrics, agentic LLM judges aligned to human-scored golden sets, CI/nightly regression runs, and production monitoring.

Metrics: Judge pass/fail · Latency · Token usage · Tool call counts · Judge alignment to human labels · Production judge pass rate · Scenario coverage

“We track token usage and tool call counts on production conversations. A quality-neutral change that triples cost is still a regression.”article, stated

Outcomes

Verification time dropped from two weeks to hours.
Teams shipped improvements faster.
Several suites reached hundreds of scenarios per agent.
Integration tests caught dependent infrastructure regressions before production.
The same judges monitor sampled production conversations.

Databricks adopted coSTAR across Genie capabilities, internal productivity agents, customer-facing agents, AI Dev Kit, and the OSS MLflow Assistant.

“We have adopted this methodology across several agents that we have released in the Databricks platform”article, stated

“Integration tests flagged changes in dependent infrastructure which allowed us to prevent regressions in production.”article, stated