ARC — Agent Reliability & Chaos Harness
Deterministic simulation and chaos engineering harness for production AI agents.
What is ARC?
When production AI agents interact with real-world systems (APIs, databases, payment gateways), transient failures (timeouts, 429 rate limits, bad schemas) often cause silent disaster:
- The agent retries without an idempotency key and charges a customer twice.
- An unhandled error causes the agent to corrupt database state.
- Flaky external tools lead to non-reproducible bugs.
ARC gives you a zero-production sandbox to replay agent execution traces, inject systematic chaos faults, and mathematically verify safety rules before deploying to production.
How It Works
- Record: Capture agent runs into Canonical Trace Format (CTF v1.0) with
@trace_agentand@trace_tool. - Replay & Fault Injection: Replay traces against simulated tool models with virtual clocks, injecting timeouts, rate limits, or concurrent mutations.
- Verify: Check safety invariants (e.g., never refund more than order total) deterministically and enforce pass/fail quality gates in CI/CD.
Agent Trace ──► Replay Sandbox (Zero-Prod) ──► Fault Injection ──► Safety Invariant Check
│ │
Virtual Clock Pass / Block CI
Installation
pip install arc-reliability
Quickstart
1. Instrument Your Agent
Wrap your agent and tools with ARC decorators. Traces and state transitions are captured automatically:
from arc import trace_agent, trace_tool
@trace_tool(name="payment_gateway")
def process_refund(order_id: str, amount: float) -> dict:
return {"status": "ok", "refund_id": "ref_1042", "amount": amount}
@trace_agent(name="refund_agent")
def handle_customer_request(order_id: str) -> dict:
return process_refund(order_id, 45.99)
if __name__ == "__main__":
result = handle_customer_request("ORD-8842")
print(result)
2. Replay with Fault Injection & Verify Invariants
Test how your agent handles a network timeout after a commit without touching your live database:
from arc.execution.fork_engine import FaultCatalog, FaultSpec, FaultType
from arc.execution.sandbox_runner import SandboxRunner
# 1. Define chaos fault: timeout occurs AFTER payment commits
catalog = FaultCatalog()
catalog.add_fault(FaultSpec(
at_step=1,
fault_type=FaultType.TIMEOUT_AFTER_COMMIT,
target_tool="payment_gateway"
))
# 2. Define safety invariant: payment must never be executed twice
invariant = {
"id": "INV-NO-DOUBLE-CHARGE",
"statement": "Payment tool must not be called more than once",
"category": "safety",
"check": "len([e for e in effects if e.type == 'payment_gateway']) <= 1",
"severity": "critical"
}
# 3. Run in zero-prod sandbox
runner = SandboxRunner()
verdict = runner.run_with_faults(fault_spec=catalog, target_invariant=invariant)
print("Passed:", verdict["passed"]) # False if double-charge occurred
CLI at a Glance
ARC provides a single command-line interface for CI/CD gates and debugging:
# Evaluate trace reliability in CI pipeline (exit code 0 = pass, 1 = fail)
arc gate --trace trace.json --profile smoke
# Replay and diagnose a bug reproducer artifact
arc repro arc-repro-8842.yaml
# Minimize a complex failure trace into the smallest reproducible bug
arc minimize arc-repro-long.yaml -o arc-repro-min.yaml
# Start local replay debugger proxy
arc debug --port 8089
# Review candidate invariants mined from code and schemas
arc catalog review --id INV-PAY-002 --accept
Core Capabilities
- Zero-Prod Replay: Mock and replay agent side-effects in memory with
PassiveEffectLedger. - Chaos Fault Catalog: Test against 14+ faults:
timeout_before_commit,timeout_after_commit,http_429,bad_schema,duplicate_action,concurrent_write. - Restricted AST Invariant Engine: Write safety checks with safe Python expressions. Unsafe I/O and non-deterministic calls (
random(),time.now()) are strictly blocked. - Delta-Debugging (
ddmin): Automatically isolates the exact fault that caused an invariant violation. - Statistical CI Gate: Validates reliability across parallel execution branches using 95% Wilson Score Confidence Intervals.
- Tier-1 PII Redaction: Scrubs API keys (AWS, Stripe, Bearer tokens, JWTs) and high-entropy secrets at the source.
Documentation
For full API references, function signatures, and architecture details, see API Documentation.
License
Metadata
Release files for arc-reliability 0.1.2
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| arc_reliability-0.1.2.tar.gz | 91.5 kB | Without provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| arc_reliability-0.1.2-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 206.5 kB
Release files / arc_reliability-0.1.2.tar.gz
| Download URL | arc_reliability-0.1.2.tar.gz |
|---|---|
| Size | 91.5 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
d28abb468969dd4eec3eddbe37336246c316c76052269b314ebe86b52fbd5064
|
|
BLAKE2b-256 checksum How to use checksums |
415a54fc17366e3f9fca845cf3b58e5c7155964b2d790bc8947fbf4d54097e05
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.14.2
|
Release files / arc_reliability-0.1.2-py3-none-any.whl
| Download URL | arc_reliability-0.1.2-py3-none-any.whl |
|---|---|
| Size | 115.1 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
9aad9ef085579cca5a8bb750c29848c539047feafc97d0c6dac47d7afc1ebde8
|
|
BLAKE2b-256 checksum How to use checksums |
045cba667654b1f034dabe6139e570492b1d8684c93881a8ceb0655072eda00f
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.14.2
|
Security for arc-reliability 0.1.2
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.