Simulations
Test agents against synthetic personas and scenarios through the production reasoning path with source-tagged effect isolation.
Simulations let you exercise agent behavior with synthetic users before deploying to real users. You define who the synthetic user is, what situation they are in, and what success looks like. The conversations use current workspace context and real tool paths subject to simulation source policy, so they are controlled test interactions rather than a fully isolated environment.
Core Concepts
The conceptual model uses personas, scenarios, cases, suites, and runs. In the Platform API, the durable resources are cases, suites, runs, sessions, and turns; persona and scenario content is embedded in a case or generated for a bridge run rather than managed through standalone Platform persona or scenario CRUD endpoints.
API distinction - The Classic API exposes separate simulation personas, scenarios, unit tests, and test sets. A Platform saved case embeds persona and scenario content, and a suite groups cases. Do not send a Classic persona or scenario resource shape to the Platform coverage API.
Personas
A persona describes a synthetic user. It defines the characteristics, background, communication style, and behaviors that the test user will exhibit during a simulated conversation.
Personas should reflect real user segments your agent will encounter. In healthcare, this might include an elderly patient with multiple medications, a first-time caller with high anxiety, or a caregiver managing care for a family member.
Persona: Margaret, 68-year-old retired nurse
- Takes 5 medications daily
- Knowledgeable about medical terminology
- Tends to self-diagnose and resist recommendations
- Prefers detailed clinical explanationsGood personas test specific capability gaps. Margaret tests whether the agent can work with a medically knowledgeable user who pushes back on recommendations, rather than a compliant user who accepts everything.
Scenarios
A scenario defines the situation and conversational context for a simulation. It describes what happens during the interaction, what the user is trying to accomplish, and any environmental conditions.
Scenarios should cover both common situations and edge cases. Routine interactions validate baseline behavior. Edge cases verify safety boundaries and escalation logic.
Cases
A case combines a persona, a scenario, and evaluation criteria into a single saved, testable unit. The criteria define what the agent must do (or must not do) for the case to pass.
Cases are the building blocks of your test suite. Each one verifies a specific agent behavior in a specific context.
Cases can be hand-authored or machine-generated. Scenarios produced by the scenario generator are automatically saved as durable cases capturing the persona, scenario content (instructions, initial message, temperament), patient bindings, and evaluation criteria used during generation. Each case carries metadata recording how it was created, so you can distinguish hand-authored cases from those seeded by automation or generated by the scenario generator. If a run is replayed, previously persisted cases are reused rather than duplicated.
A case can also carry a per-case success definition that specifies how its runs should be scored. When present, the platform scores the run against that definition rather than the coarse terminal-state or max-turns rubric, so benchmark and suite cases are evaluated against precise, case-specific criteria - for example, whether the agent reached a particular outcome or completed a specific action. Cases without a success definition fall back to the standard scoring rubric.
Cases are fully manageable through the API - including bulk creation for seeding cases from external test management systems or CI pipelines - with filtering by tag and service. Legacy cases that predate the current schema are backfilled automatically so scenario instructions are always present in responses.
Suites
A suite groups related cases together for batch execution. Suites are first-class resources with a name, description, an explicit list of case IDs, optional required tags that dynamically match additional cases, and their own tags and metadata. Suites do not bind to a specific service - the service is supplied at run time by the benchmark request or by each saved case's own configuration.
You might organize suites by capability area, risk level, or deployment phase:
Safety boundaries: All cases verifying escalation and scope-of-practice adherence
Medication management: Cases covering adherence reminders, interaction detection, and refill coordination
Post-discharge: Cases covering the full post-discharge follow-up workflow
Suites let you run targeted validation. Before promoting a change to your medication workflow, you run the medication management suite. Before any production deployment, you run the safety boundaries suite.
Runs
A run attempts a case or suite and records the conversations and scores that complete. Failed or never-started cases can leave partial evidence, so suite consumers should compare observed results with the expected case count.
Run results include:
Pass/fail status for each case
Metric scores for each simulated conversation
Conversation transcripts for review and debugging
Aggregate statistics across the suite
Eval results with summary counts for total, passed, failed, and errored evals
Tags - Optional labels on runs and sessions for filtering and grouping (e.g., "regression", "nightly", "scheduling-flow")
When a run fails, it records a short failure reason so you can tell an infrastructure failure apart from an agent-quality failure without digging through logs. The failure reason is empty for successful runs. Each suite run also reports an expected case count - the number of cases selected when the run was launched - so you have a reliable completeness signal even though suite definitions can change over time and cases that never start leave no result row.
Run Reliability
Long suites remain reportable when execution is interrupted. Recoverable runs resume automatically up to a bounded attempt limit. A run that cannot be recovered ends with a failure reason instead of remaining indefinitely in progress, and suite summaries preserve the expected case count so missing starts are visible. Recovery remains isolated to the run's workspace.
How Simulations Execute
When a simulation runs, the system instantiates the configured persona and scenario, then executes a full conversation loop:
The configured persona generates scenario-conditioned user messages based on its communication style, background, and goals.
The full Platform agent pipeline processes each message: Context Graph navigation, state guidance, selected memory context, tool execution, and response generation.
If the context graph enters a loop (revisiting the same states without progress), the simulation flags it as a known failure and stops.
After the conversation completes, configured metrics are evaluated against the full interaction history.
Text simulations exercise the production reasoning path, including context graph navigation, model decisions, tool execution, and turn policies. A controlled persona replaces the human caller. Production effects are isolated: simulation-tagged writes are excluded from EHR delivery and production analytics, while surface delivery and approval workflows are unavailable in simulations.
Grounded in Workspace Data
Bridge-generated callers can receive a bounded grounding snapshot containing resolved locations, appointment types, visit reasons, providers, transfer targets, and escalation rules from supported workspace configuration and data. The caller prompt instructs the model to use those facts and acknowledge missing categories. This reduces invention but is not a factuality guarantee, and the snapshot does not make a synthetic conversation representative of every production interaction.
Comparable Runs with Fixed Settings
Bridge callers and simulation judges use zero-temperature settings by default to reduce sampling variance in those components. The agent, current workspace state, external tools, and model providers can still vary, so reruns are comparison evidence rather than deterministic replays.
Channel-Faithful Behavior
Simulation sessions accept injected acoustic emotion only for the voice modality. Text and web simulations ignore those signals, matching the absence of acoustic emotion data on production text channels. Model responses can still vary across runs and channels.
Conversation Direction
Simulation sessions support both user-first and agent-first openings, plus an outbound conversation direction where the agent speaks first against task context rather than waiting for the caller. Outbound sessions reuse the same opening path as production outbound voice calls, so the agent's first message reflects the task context (such as the target patient entity) rather than a generic inbound greeting. This is useful for testing proactive outreach workflows, appointment reminders, and other agent-initiated scenarios. Outbound mode requires the agent to produce an opening message at session creation time, so it is incompatible with the deferred initialization used by large batches.
Batch Execution Behavior
Large batches provide progressive feedback rather than waiting for every scenario to finish before showing results. Scenarios that are ready can begin while the remainder are still being prepared, and completed work remains available if later scenario preparation fails. Sessions that fail before producing a transcript are reported as failures rather than counted as successful completions.
Entity Binding
Simulation sessions can be bound to a specific patient entity at creation time, giving the simulated conversation access to the same patient context resolution used in production calls. When an entity ID matches a world entity in the workspace, the session resolves caller context directly from that entity rather than relying on phone-based lookup. If the entity does not exist (stale, deleted, or wrong workspace), the session falls back to phone lookup without interruption, and the supplied caller phone number is still recorded and surfaced in greeting metadata. Entity binding is workspace-scoped - an entity from one workspace cannot leak data into a simulation running in a different workspace. Entity IDs must be valid non-zero UUIDs and are validated before the request reaches the agent engine.
Bridge runs also accept an entity ID, which is forwarded to every scenario session and inherited by forked sessions, letting you pin an entire regression suite to a specific test patient.
World Model and Effect Isolation
Simulations read the workspace context available when the session runs rather than a frozen snapshot. Use a dedicated test workspace or test entities when a stable patient population, schedule, or service configuration is important for comparison across runs.
Tool calls execute through the real agent tool path. World-model writes are tagged as simulation data and excluded from production EHR delivery, production analytics, and workflows that select production entities. Surface creation and delivery are disabled, which also means human approval paths that depend on surfaces cannot be exercised in a simulation.
This makes simulations suitable for testing reasoning, context graph paths, tool selection, and world-model effects. Validate live connector behavior, external-system availability, and approval workflows separately in an appropriately isolated integration environment.
Session Persistence and Data Flow
Simulation sessions run through the production reasoning engine, but coverage runs, sessions, forks, turns, and scores are stored as simulation evidence rather than as ordinary production conversation records. Forked sessions receive independent conversation-state copies. Run status and failure fields surface known execution failures; as with any distributed system, consumers should also verify expected case and session counts before treating a batch as complete.
When a simulation run completes cleanly, its evidence includes retained conversation turns, tool and state traversal, and configured scores. Shared evaluation concepts can support comparison, but modality and evidence differences still need to be controlled. Source classification keeps simulation and playground traffic out of production analytics. Errored runs remain visible as failures rather than being treated as completed evidence.
Case Library and Suites in the Developer Console
The Developer Console provides a Case Library page for browsing and searching saved cases, with filters for service and suite. Case rows expand inline to show the full scenario, persona, eval criteria, service, labels, patient binding, and opening message, and each case opens in a detail view that organizes grounding data, evaluation criteria, and metadata into structured sections. The library shows which suites each case belongs to, and cases with a saved service can be run directly from the library with a single click.
The Suites page lists all suites with case counts, descriptions, and timestamps. An entire suite can be executed as a batch run from the console or the API, with results appearing in the standard simulation runs list. The runs list groups suite runs into collapsible rows showing aggregate status, session and turn totals, and the services involved, with a run source filter for narrowing to suite runs, case runs, or spot checks. The run detail page displays outcome summary cards for session scores, eval results, and run status.
Open the Case Library and Suites from the Simulations workspace or the Developer Console command palette. They are not separate persistent sidebar items.
Benchmarks and Suite Runs
Benchmark runs execute saved cases in batch - selected by suite or by tag - with aggregated scoring and capability-level breakdowns. A benchmark references either a suite ID (which resolves the suite's explicit case IDs and required tags into a combined case set) or required tags directly; the two are mutually exclusive on a single request. Benchmarks can include up to 200 cases per run, so large regression suites execute as a single batch. Benchmark callers get stable run IDs back immediately and can poll for results while the platform controls the execution fan-out internally.
Suites can also be run directly through a dedicated suite run path that enforces suite-based execution. Each suite run is assigned a durable identifier that groups all constituent case runs together, and you can list past suite runs and retrieve aggregate results - status breakdowns, session and turn totals, case coverage, and metric availability. Suite runs and benchmarks share the same aggregation and metric enrichment, so the scoring view is consistent regardless of how execution was triggered.
Each case in a benchmark can carry its own patient entity ID in its grounding, so different cases can target different test patients within the same benchmark. An explicit entity ID on the benchmark request applies to all cases; when omitted, each case falls back to its own grounding-level entity. This per-case resolution makes multi-patient benchmarks possible without splitting them into separate runs.
Benchmarks answer the question: does the agent handle an entire test suite correctly?
Evaluation Criteria (Evals)
Each case can define evaluation criteria (evals) that execute automatically when a simulation run completes. Evals come in two types:
Assertions validate conversation outcomes directly - whether a specific phrase appeared in the transcript, whether a particular tool was called, whether the conversation ended in an expected state, or through an AI judge that evaluates the transcript against a natural-language criterion. Assertion kinds that do not match a built-in check are routed to the AI judge.
Metric checks compare observed metric values against configured expectations (exact match, numeric range, or string containment).
Eval results are computed per conversation within a run - a run with N conversations yields N verdicts per eval, so each conversation receives its own outcome rather than a single run-level verdict. Runs with no observed conversations fall back to a run-level verdict. Results carry a status (passed, failed, pending, skipped, or error) plus optional score, rationale, and turn references when the evaluator produces them. Do not expect a completed rationale or citation on pending, skipped, errored, or otherwise unavailable evidence.
For active AI-query metrics referenced by an eval definition, the completion path attempts a justified computation containing a value, transcript-grounded explanation, and supporting turn indices. Case context is included when available. Other metric values can remain value-only, and a failed or unavailable computation can leave the metric eval pending.
The platform attempts eval-referenced AI-query metrics when a run completes so callers do not have to wait for the batch pipeline in the normal case. That path can use different execution settings from batch evaluation, so values are not promised to be bit-for-bit identical. A failed compute does not fail the run; reads expose pending, available, or unavailable plus a result count and last-check time. Clients must refresh or poll the relevant run endpoint to observe a later state. Benchmark responses aggregate availability across constituent runs.
Production Evals
The same eval concepts are available for eligible completed production conversations. Workspaces can define assertions and metric checks separately from simulation cases. A production eval definition specifies the eval type, an eval key, and the expected outcome, and can be scoped to a specific service or applied workspace-wide; a service-scoped definition with the same key overrides the workspace-wide one for that service's conversations.
Eligible completed calls with the required conversation evidence can be evaluated on demand. The persisted verdict shape aligns with simulation evals, including status and optional score, rationale, justification, and turn references. Re-evaluating replaces the prior verdict set for that call. Production and simulation share evaluator concepts, but modality, available evidence, model execution, and source data can still affect results.
Performance Overview
The Developer Console provides a Simulations performance overview that aggregates recent graded runs into overall pass rate, per-metric breakdowns, and per-case and per-suite rollups with drill-down to individual conversation verdicts. It highlights cases and suites whose observed pass rate is below 100%. Each metric shows a per-run trend with mean value, pass counts, and measured counts, and the analysis window can be switched among the latest run, a recent run count, or all available runs. A metric appears when it produced a numeric value or measured verdict in at least one included run.
Agent Readiness
The Agent Readiness dashboard provides an informational view of simulation evidence using a Developer Console rubric. It groups criteria into basic, intermediate, and advanced tiers across areas such as task completion, coverage, safety, and communication quality.
Implemented criteria are computed in the console from simulation run data, coverage state, and session history. Criteria can show pass, fail, or not measured; some metric-backed and voice-quality checks remain not measured until their data is wired into the rubric. The displayed level is advisory and does not deploy an agent or block a version update.
The readiness rubric enforces minimum evidence thresholds - for example, sustained pass rate criteria require a minimum number of completed simulation runs before they are evaluated. This prevents premature pass/fail judgments on insufficient data.
Permissions
Simulation reads - listing runs, viewing coverage graphs, querying session turns, retrieving benchmark results - require the Service view permission, while writes - creating runs, stepping sessions, executing benchmarks, deleting coverage graphs - require the Service update permission. The Developer Console enforces the same model: simulation write actions are disabled for workspace roles without Service update, and only admin and owner roles can trigger simulation runs from the console.
Using Simulations in Practice
Pre-Deployment Validation
Before deploying a new agent configuration or promoting a version set, run your suites to verify that existing capabilities still work and new changes behave as expected.
Treat safety-related suites as required evidence. A failing safety case should stop the team's manual promotion decision until the issue is resolved.
Regression Testing
When you update Context Graphs, state guidance, tools, or agent configuration, run your full test suite to catch unintended side effects. An improvement to appointment scheduling logic should not degrade medication safety checks.
Coverage Expansion
As you discover new edge cases in production, add them as cases. Over time, the suite becomes a broader regression catalog, but it cannot prove coverage of every future input or boundary failure.
Simulation Bridge
For exploratory testing where you do not yet know which specific cases to write, the simulation bridge generates scenario variations from a natural-language objective. You describe what you want to test ("stress test the cancellation flow" or "verify the agent handles insurance denials gracefully"), and the bridge generates diverse scenarios with different persona backgrounds, temperaments, and complications.
Each generated scenario runs as a full multi-turn conversation where a model-driven persona makes decisions at each turn based on the scenario's goals and the agent's responses. The bridge records simulation evidence such as visited Context Graph states, tool calls, and turn-level evaluation inputs. It does not expose a hidden chain of thought or a Platform dynamic-behavior layer.
This approach is useful for early-stage coverage discovery - finding the edge cases that should become permanent cases - and for ad-hoc validation when a configuration change touches many flows at once.
Target Specs
A target spec defines what success looks like for a bridge run. Instead of just exploring the conversation space and scoring with generic metrics, you can declare the specific outcomes the agent should achieve and the boundaries it should respect.
Target specs have four components:
Desired states
Context graph states the agent should reach during the conversation
Non-desired states
States the agent should avoid - either hard (instant failure) or soft (score penalty with rationale)
Ordered pathways
Expected sequences of states the agent should traverse in order
Completion criteria
Conditions that define success - state-based (agent reached a target state) or tool-based (agent called a specific tool)
Each scenario session is scored against the target spec at completion: 100 means all criteria passed, 0 means the agent entered a hard-forbidden state, and intermediate scores reflect partial success with soft misses and rationale explaining what was missed.
Plan Inference
You do not need to author target specs by hand. The platform can infer a target spec from a natural language objective, grounded in the service's actual context graph states and available tools.
Two workflows are supported:
Preview and edit - Submit your objective and get back an inferred target spec with rationale explaining why each state was included. Review the spec, add or remove states, tighten pathways, then run with the final version. This gives you full control over what gets tested.
One-shot - Submit your objective with auto-inference enabled, and the bridge infers the spec and runs scenarios in a single call. The inferred spec and rationale are returned alongside the results so you can see what was tested and adjust for the next run.
The inferred spec only includes states and tools that actually exist in the service's context graph. Any hallucinated names are filtered out before the spec is applied.
Coverage-Driven Candidate Selection
When a target spec or coverage mode is active, the bridge steers each conversation turn toward unexplored territory. At each turn, the system scores candidate user responses based on coverage goals: responses that would reach uncovered states or advance an ordered pathway get priority, while responses that would enter forbidden states are deprioritized. The top candidate's expected direction becomes a soft goal hint for the simulated caller, though the persona's voice and behavior remain the source of truth.
This supplements unguided exploration with targeted candidate selection intended to reach useful uncovered paths more often.
Forking at Decision Points
When two top-scoring candidates aim at different conversation branches, the bridge can fork the session into parallel children at that decision point. Each child continues independently with its own target spec scoring, sharing a per-scenario fork budget that limits total branching.
Forking multiplies exploration without replaying conversation history. A single scenario that reaches a scheduling confirmation state can fork into "patient confirms," "patient reschedules," and "patient cancels" - three full conversation paths from a single starting point.
Reusing Run Inputs
Bridge runs persist the original request inputs (objective, target spec, exploration settings) and generated scenarios (persona backgrounds, temperaments, instructions, and initial messages). Reusing those inputs turns an exploratory run into a comparable regression case, but it is not an exact replay: the current agent version, context graph, workspace data, and model sampling can change the result.
Session Tagging
Each session carries tags linking it back to the specific persona and scenario that generated it. The results view can show which persona produced which conversation and how the agent performed against each one. Forked child sessions inherit the parent's tags, so the full exploration tree is traceable back to a single scenario.
Interaction Insights
The simulation trace provides best-effort observed evidence for a session. When available, it can include user and agent turns, context graph states and transitions, executed tool calls and results, emotion labels, and emitted actions.
The trace does not expose hidden model reasoning, tools that were merely considered, or a causal claim about which memory changed a response. Because trace evidence is reconstructed from a best-effort session record, a run can have partial or unavailable interaction detail. Use the retained transcript, executed actions, status, and evaluation results together when reviewing the run.
Test User Configuration
Simulation test users can be configured with additional attributes to test user-specific agent behaviors:
User variables - Key-value pairs (nonsensitive and sensitive) that are passed to tools during invocation. Use these to test workflows that depend on external system IDs, plan types, member numbers, or other user-scoped data.
Preferred language - ISO 639-3 language code (e.g.,
eng,spa) to test multilingual agent behavior.Timezone - IANA timezone (e.g.,
America/New_York) to test time-sensitive workflows like appointment scheduling across time zones.
These attributes are set on ephemeral test users at creation time. Sensitive variables are encrypted and cannot be read back after being set - they are only available to tools during the conversation.
Scenario Design Tips
Start with real interactions. Review production conversations to identify patterns worth testing.
Test failure modes, not just happy paths. Include scenarios where the user is confused, uncooperative, or presenting ambiguous information.
Vary persona characteristics systematically. Test the same scenario with users of different ages, literacy levels, and communication styles to check that the agent adapts appropriately.
Include multi-turn complexity. Some issues only surface across longer conversations where the agent must maintain context and consistency.
Simulation Coverage
While cases verify specific known behaviors, simulation coverage systematically explores context graph state space to find gaps you have not tested yet. It uses a branch-and-bound algorithm that steers simulated conversations toward unvisited states, tools, and transitions - turning random sampling into targeted exploration.
How Coverage Works
A coverage run creates a knowledge graph of your agent's tested behavior. Each conversation becomes a session in the graph. Each agent turn is stored individually, recording which context graph state the agent was in, which tools were called, and what scores were assigned.
The knowledge graph has two layers:
Observed turns - Retained turns from recorded sessions, with the context graph state, tool calls, and available evaluation scores
Topology overlay - Ghost nodes representing context graph states that exist in the state machine definition but have never been reached in any session. These are the gaps in your coverage.
Fork Primitive
The fork primitive is what makes branch-and-bound exploration practical. At any point in a conversation, you can fork a session into multiple children. Each child starts from the same conversation state as the parent but receives a different simulated user message. This lets the system explore multiple branches from a single decision point without replaying the entire conversation history.
For example: a session reaches a state where the patient can either confirm an appointment, ask to reschedule, or cancel. Instead of running three separate conversations from scratch, the system forks the session three ways. Each fork picks up at that decision point with a different patient response, and all three branches continue independently.
For each fork request, the server copies the parent's stored conversation state into child sessions and steps each child with its assigned message. Parent-child identifiers form a tree for the branches that were successfully created; verify returned child and error results before assuming every requested branch completed.
Coverage Scoring
Each session is scored on the evaluation metrics you configure. Scores are attributed per-session, not per-state-visit, so a single session that visits a state twice does not inflate that state's coverage count. The knowledge graph aggregates pass rates per state, giving you a heat map of where your agent performs well and where it struggles.
Ghost nodes - states with zero recorded sessions - are natural exploration targets. A low state-associated pass rate identifies sessions worth reviewing; it does not by itself prove that the state caused the failures.
Write Isolation
Coverage sessions use source-tagged isolation rather than database branches. Tool writes remain identifiable as simulation data and are excluded from production EHR delivery and analytics. Because reads use current workspace state and some production effects are disabled, use dedicated test entities and validate connector or approval behavior separately.
Using Coverage in Practice
Before promoting a version set - Run a coverage campaign against the new version. Compare the knowledge graph against the previous version's graph to identify regressions or new gaps.
After modifying a context graph - Coverage testing surfaces states that your changes may have made unreachable, or new states that no existing test covers.
Periodic comparison - Schedule coverage runs to track how agent behavior changes over time. Drift in coverage scores can indicate that graph, prompt, model, data, or tool-response changes affected paths you thought were stable.
Coverage runs, sessions, and turn-level data are available through the Platform API. The Developer Console's interactive coverage visualization is currently an internal preview. Simulation evidence remains on simulation-specific surfaces; the unified Runs inventory lists conversation and framework runs, not coverage sessions.
Coverage runs are also available through the Agent Forge CLI (forge platform simulation commands).
Developer Guide - For simulation endpoints (personas, scenarios, unit tests), see Simulations in the developer guide. For coverage endpoints (runs, sessions, fork, graph), see Simulation Coverage.
Evaluation Framework
Simulations are most effective when driven by a structured metrics catalog. Each metric in the catalog defines three things:
Scoring method - Pass/fail case (binary) or scaled assessment (0-100)
Target threshold - The minimum acceptable score for that metric
Weight - How much the metric contributes to the overall evaluation, reflecting business priority
Teams commonly divide metrics into two decision classes. Required checks are binary criteria that should stop a manual promotion when they fail, such as medical escalation accuracy, scope-of-practice adherence, or privacy compliance. Improvement targets use scaled scoring to guide prioritization, such as explanation clarity, empathetic response, or question comprehension. The platform records the evidence but does not automatically block a version-set update.
The catalog serves as organizational alignment on what success means. When you update an agent configuration, the relevant metrics tell you whether the change helped, hurt, or had no measurable effect.
Continuous Evaluation
Running simulations once before launch is useful. Running them on a regular cadence - weekly or per release, depending on development pace - produces comparable evidence over time. Use the run history and your monitoring process to look for regressions; the platform does not turn every change in a score into an automatic deployment decision.
Production Calibration
Comparing simulation and production can expose a calibration gap. If simulation shows 90% task completion but a comparable production population shows 75%, investigate scenario coverage, population differences, evidence availability, channel effects, system latency, tools, and scoring definitions before assigning a cause. Add verified production failure modes to the simulation suite when they reveal missing coverage.
See also
Playground and Interactive Testing for interactive testing, tool testing, and test traffic handling
Voice Simulation for text-tier behavior coverage and separate real-audio validation
Metrics and Quality for post-simulation scoring dimensions
Drift Detection for monitoring coverage regression over time
Agent Forge for CLI simulation and coverage commands
Last updated
Was this helpful?