WAIL

Runtime Control for AI, Agent & MCP Execution

Website · PyPI · Getting Started · Architecture · Runtime Control · Evidence Model · Why WAIL · Telemetry

WAIL is an on-prem execution control and governance layer for AI models, agents, and MCP tools.

An AI request can return HTTP 200 yet still behave poorly: latency rises beyond its baseline, streaming stalls, or a tool call degrades. Detecting a problem is not the same as deciding what to do next — or proving what actually happened.

WAIL wraps your existing clients and MCP sessions to observe execution, assess runtime degradation, and make supported observe, retry, or reroute decisions. Standard provider rerouting can apply to a subsequent execution. Separately, Continuous Governance Assurance & Enforcement (CGAE) governs authority changes during active execution, including intervention in affected in-progress model, agent, and MCP operations.

WAIL links observations, authorization and policy changes, decisions, enforcement actions, and verified outcomes through cryptographically signed evidence and an authoritative ledger.

No gateway. No replacement agent framework. Your application retains orchestration and business logic. Governance and audit workflows are supported where enabled. CGAE is a core WAIL capability that provides continuous governance control and enforcement throughout the execution lifecycle.

Free Developer tier. No signup or credit card required. Python 3.12.

pip install wail-runtime

Quick Start

Wrap your existing AI client with WAIL.

from openai import OpenAI
import wail

client = wail.wrap(OpenAI())

Use it exactly as you normally would.

response = client.responses.create(
    model="gpt-4o-mini",
    input="Explain what WAIL does."
)

print(response.output_text)

After each request, WAIL prints a runtime summary.

WAIL AI Runtime Control Layer
────────────────────────────────────────

Plan               Developer
Provider           openai
Model              gpt-4o-mini

Duration           2,220 ms
TTFT               1,981 ms
Throughput         3.97 tok/s
Mean Token Gap     4 ms

Active Signals     0
Runtime Severity   NONE
Risk Score         0.00
Dominant Surface   NONE

Decision           OBSERVE
Trace              SAVED · 01M1BQ593...

Every measured execution can also generate signed runtime evidence that includes:

Continuous Governance Assurance & Enforcement (CGAE)

CGAE is a core WAIL capability, not a separate product, gateway, or execution authority. It maintains governance control throughout the lifecycle of model, agent, and MCP execution — including changes that occur after an execution has started.

CGAE enforcement includes:

Runtime recovery and governance enforcement are distinct: subsequent-execution provider rerouting does not limit CGAE intervention in an already-active execution. Evidence distinguishes an attempted intervention, a local stop, and independently verified remote cancellation.

Architecture

WAIL Architecture

WAIL operates around the execution path rather than replacing it.

For direct model execution, WAIL observes and controls provider requests.

For agent and MCP execution, WAIL can represent the active workload as an Agent Run containing connected agent, model, and MCP tool execution units.

Delegation, call, and join relationships preserve how execution moved through the run.

What WAIL Does

Runtime Control Loop 

Runtime measurements
        ↓
Baseline + anomaly detection
        ↓
Risk / severity evaluation
        ↓
Candidate scoring
        ↓
Runtime decision
        ↓
Intervention when required
        ↓
Recovery application / verification
        ↓
Signed execution evidence

WAIL does not route requests simply because another model, provider, or execution target scores better.

Candidate evaluation informs runtime control; intervention remains driven by observed runtime conditions and control policy.

Agent & MCP Execution

WAIL extends its execution model across existing agent orchestration and MCP sessions without becoming the orchestrator itself.

A WAIL Agent Run can preserve:

A simplified execution graph can look like this:

Coordinator Agent
        │
        ├── delegates ──> Research Agent
        │                       │
        │                       ├── calls ──> Model
        │                       │
        │                       └── calls ──> MCP Tool
        │
        ├── delegates ──> Verification Agent
        │                       │
        │                       ├── calls ──> Model
        │                       │
        │                       └── calls ──> MCP Tool
        │
        └──────────── joins ────────────┐
                                        ▼
                                  Synthesis Agent

The application remains responsible for orchestration and business logic.

WAIL records and evaluates the runtime execution around it.

Agent & MCP Runtime Output

WAIL preserves runtime visibility at both the individual execution level and the Agent Run level.

An MCP tool execution is observed as its own runtime execution:

WAIL AI Runtime Control Layer · 20:37:41
────────────────────────────────────────

Plan              Pro
Execution Type    MCP Tool
Agent             runtime_worker_agent
Tool              wail_probe

Duration          106 ms
TTFT              --
Throughput        --
Mean Token Gap    --

Active Signals    0
Runtime Severity  NONE
Risk Score        0.00
Dominant Surface  NONE

Decision          OBSERVE
Trace             SAVED · 01M46J933...

The complete multi-agent execution is also represented as an Agent Run:

WAIL AI Runtime Control Layer · 20:37:42
────────────────────────────────────────

Plan             Developer
Execution Type   Agent Run
Run              run_222738885...

Agent Units      2
Model Units      1
MCP Tool Units   1
Relations        3

Status           COMPLETED
Signed Evidence  SAVED

This gives WAIL two connected levels of evidence:

Individual Execution
    │
    ├── Model Trace
    └── MCP Tool Trace
            │
            ▼
        Agent Run
            │
            ├── Agent Units
            ├── Model Units
            ├── MCP Tool Units
            ├── Relations
            └── Signed Evidence

Individual model and MCP tool executions remain independently traceable, while the Agent Run preserves how those executions were connected as a single execution graph.

MCP Integration

WAIL wraps an existing MCP client session rather than replacing the MCP transport or server.

from wail.mcp.adapter import wrap_mcp

mcp_client = wrap_mcp(
    session,
    transport="stdio",
    service="mcp",
    env="production",
)

Here, session is an already initialized MCP ClientSession.

Tool calls continue through the wrapped MCP client:

result = await mcp_client.call_tool(
    "inspect_repository",
    arguments={"path": "."},
)

When the call occurs inside an active WAIL execution context, WAIL can preserve the MCP operation as a tool execution unit and associate its trace with the active Agent Run.

MCP Recovery Routes

A backup MCP tool can be configured as an alternate runtime path:

mcp_client = wrap_mcp(
    session,
    transport="stdio",
    routes={
        "primary_tool": "backup_tool",
    },
    service="mcp",
    env="production",
)

When runtime conditions naturally produce a supported recovery decision, WAIL can apply the recovery on the subsequent execution and preserve evidence linking the source execution to the applied recovery.

Agent Run

WAIL creates an execution boundary around existing agent orchestration:

import wail

with wail.execution_run(
    attributes={
        "orchestration": "coordinator_worker",
    }
) as run:
    run_id = run.run_id

Agent Runs do not replace the application's orchestration model.

They provide an execution boundary for connecting agent, model, and MCP tool activity into a common runtime graph and evidence record.

Within a run, WAIL can preserve relationships including:

Coordinator
    │
    └── delegates ──> Worker
                          │
                          ├── calls ──> Model
                          │
                          └── calls ──> MCP Tool

More complex executions can also preserve fan-out and fan-in relationships:

Coordinator
    │
    ├── delegates ──> Agent A ──┐
    ├── delegates ──> Agent B ──┼── joins ──> Synthesis Agent
    └── delegates ──> Agent C ──┘

Model and MCP tool executions associated with these agent units retain their individual runtime traces while also becoming part of the Agent Run graph.

For complete working examples, see:

Runtime Recovery

WAIL distinguishes between a recovery decision, its later application, and verification of the resulting execution.

For supported runtime recovery paths:

Execution N
    │
    ▼
Runtime degradation / failure
    │
    ▼
WAIL runtime decision
RETRY or REROUTE
    │
    ▼
Execution N+1
    │
    ▼
Recovery application
    │
    ▼
Recovery verification
    │
    ▼
Signed evidence

A recovery decision is therefore not treated as proof that recovery actually happened.

WAIL can preserve:

This allows the evidence chain to distinguish:

Decision produced
        ≠
Recovery applied
        ≠
Recovery verified

Signed Agent Evidence

Completed Agent Runs can produce signed Agent Run evidence that preserves the connected execution rather than reducing the run to unrelated request logs.

Depending on execution state and available capabilities, Agent Run evidence can include:

This evidence complements WAIL's per-execution runtime artifacts.

Individual model and tool executions remain traceable while the Agent Run preserves how those executions were related.

Supported Providers

Provider Runtime Detection Runtime Control Runtime Evidence
OpenAI ✅ ✅ ✅
Anthropic ✅ ✅ ✅
Google Gemini ✅ ✅ ✅
OpenRouter ✅ ✅ ✅
Ollama ✅ ✅ ✅
OpenAI-compatible Local LLMs ✅ ✅ ✅

The runtime evidence model remains consistent across all supported providers.

Agent and MCP execution support operates around these runtime integrations; MCP itself is an execution interface rather than an AI model provider.

CLI

Inspect and verify runtime artifacts directly from the command line.

wail traces incidents

wail trace show <TRACE_ID>

wail verify <ARTIFACT_FILE>

Documentation

Learn more about WAIL: