eval_suite — AgentTeamsModule¶
Generate framework-neutral behavioral evaluation specifications for agent teams.
Builds a suite of expected behaviors that agent teams should exhibit during execution, derived from the team manifest. Used by behavioral_drift to verify that a recorded execution trajectory matches the specification. The output is deliberately framework-agnostic (no Inspect AI, OpenAI Evals, or framework-specific DSL terms).
Source:
agentteams/eval_suite.py
Constants¶
EVAL_SUITE_SCHEMA_VERSION¶
Source:
agentteams/eval_suite.py
Current schema version for eval-suite artifacts.
Type: str
WORKER_GOVERNANCE_TRIAD¶
The standard governance agents every workstream expert must coordinate with.
Type: list[str]
Value: ["primary-producer", "adversarial", "reference-manager"]
RETURN_TO_ORCHESTRATOR¶
Source:
agentteams/eval_suite.py
The literal edge label every governance scenario checks for in the expert's body — matches the Phase 0 canonical-scenario governance predicate documented in orchestrator.agent.md (Workflow 1, steps 6–8).
Type: str
Value: "Return to Orchestrator"
Functions¶
build_eval_suite(manifest)¶
Source:
agentteams/eval_suite.py
Build a framework-neutral evaluation suite from a team manifest.
Args:
manifest(dict[str, Any]) — Team manifest fromanalyze.build_manifest().
Returns: dict[str, Any] — Eval-suite dict conforming to agentteams/schemas/eval-suite.schema.json. All keys below are required by the schema:
- artifact_type: "eval-suite"
- eval_suite_schema_version: Current schema version
- project_name: The manifest's project_name (empty string if absent)
- framework: The manifest's framework (empty string if absent)
- generated_from: Always "manifest"
- scenarios: List of behavioral scenario dicts (routing, handoff, governance expectations)
Behavior Notes:
- Pure function; no I/O or external calls
- Generated deterministically from the manifest (no randomness)
- Scenarios include:
- Routing scenarios — Verify that orchestrator knows all experts; agent count matches components
- Handoff scenarios — Expected agent chains for each component; return-to orchestrator mediation
- Governance scenarios — Workstream experts coordinate with the governance triad
Typical Usage¶
from agentteams import analyze
from agentteams.eval_suite import build_eval_suite
from agentteams.behavioral_drift import detect_behavioral_drift
# Build manifest
description = {"name": "my-project", ...}
manifest = analyze.build_manifest(description)
# Generate eval spec
eval_suite = build_eval_suite(manifest)
# Later: verify a recorded execution against the spec
trajectory = {...} # from Phase 1 replay substrate
findings = detect_behavioral_drift(trajectory, eval_suite)
if findings:
print(f"❌ {len(findings)} behavioral divergences found")
else:
print("✓ Execution conforms to spec")
Framework Neutrality¶
The eval-suite is designed to be framework-agnostic: it contains no terms from Inspect AI, OpenAI Evals, or any other concrete eval framework. This allows:
- Adapters to translate the neutral spec into framework-specific formats
- Deterministic testing of the spec itself
- Reusability across eval frameworks without re-derivation
Framework-specific adapters are provided by agentteams.eval_adapters; this module remains neutral and adapter-free.
The contract is enforced by the FRAMEWORK_COUPLED_TOKENS constant — a tuple of the terms an eval-suite must never contain (inspect_ai, inspect-ai, @task, openai.evals, oaieval, evals.elsuite, Eval(, Solver(). Tests scan every generated suite for these tokens to catch a framework-specific term leaking into the neutral spec.
Adapter Integration¶
To convert the neutral suite into a runnable framework artifact, pass it to an
adapter in agentteams.eval_adapters — that reference documents the
write_inspect_ai_module / write_openai_evals_definition entry points and their
code examples, so they are not duplicated here.
The end-to-end pattern:
- Build neutral suite with
build_eval_suite(manifest). - Convert through target adapter in
agentteams.eval_adapters. - Execute with your selected eval runtime/tooling.
See also¶
model_routing— the sibling cost/capability contract built from the same manifest.