REDLINE

Make CALL-E agent requirements explicit, review corrections, and verify modelled outcomes without hiding regressions.

Comment

Inspiration: “I'm not sure” is not a confirmation

Imagine an appointment agent whose result field is a boolean. The recipient says “I'm not sure yet.” Where should that uncertainty go? The developer needs a contract that permits an unknown outcome and requires evidence before confirmation.

REDLINE helps CALL-E developers inspect that contract, review a correction and reproduce the checks before placing a call. It is a reusable Python developer tool, built and tested for this hackathon; we are not claiming customer adoption or daily production use.

Try the interactive Evidence Review

Open Evidence Review — no account or installation

Select one of four recorded calls and compare its requirement, transcript excerpt, provider outcome and manual finding. Inspect the separate saved static verification and download its source receipt. This browser companion presents recorded evidence; it does not place calls or perform automatic live evaluation. The video below demonstrates the original Python workflow.

What it does: one reviewable workflow

Step What the developer sees
1. Inspect the contract Appointment instructions, context-disclosure rules and a result schema that initially has no unknown value.
2. Run the diagnosis The actual baseline report: 21 modelled failures, including 12 critical findings. No phone calls.
3. Review the correction Proposed task clauses and schema changes: require recipient evidence, respect refusals and represent uncertainty.
4. Verify before applying 21/21 corrected static scenarios and 10/10 benign cases pass. A receipt records provenance. The source YAML remains unchanged.

The gallery contains the actual before/after reports and a separately labelled summary of controlled calls. The video follows this workflow.

The developer remains responsible for reviewing changes. In particular, replacing a boolean with yes/no/unknown changes the result contract for downstream consumers. Verification evaluates the proposed correction in memory; writing it requires the separate explicit fix --apply command.

How it works with CALL-E

REDLINE combines typed contract validation, field-level disclosure and result-evidence policies, deterministic evaluation, reviewable remediation, HTML/JSON reports and content-addressed receipts. Receipts retain hashes and verdicts rather than raw context or transcripts; they are not signed independent attestations.

We also completed four real CALL-E calls to an AI recipient we controlled, using a fictional appointment. The initial call used REDLINE's planner integration; the official CALL-E CLI executed all four calls and planned the additional three. The separately gated SDK live adapter was not used in this demonstration.

Controlled call Manually observed outcome Limitation
Confirmation Explicit appointment confirmation CALL-E accepted the recipient's self-introduction and omitted the separate planned identity question.
Refusal Declined, with no follow-up One controlled observation, not an automated REDLINE verdict.
Uncertainty Unknown, neither confirmed nor declined A positive runtime observation; we did not observe a false confirmation in this call.
Identity sequence Role acknowledgement preceded the appointment question PARTIAL: truncated questions, opening overlap and early name use; full question reception was not established.

All four returned COMPLETED, which does not imply complete instruction compliance. Together they incurred USD 0.33 in displayed provider charges. No real booking was created. Outcomes were reviewed in provider transcripts/results, not independently established by audio listening. Both caller instructions and recipient greeting changed in the identity follow-up, so the difference cannot be attributed to one change. The recipient baseline was restored afterwards.

What we learned and improved

A separate-context AI agent started from this public page, installed the pinned source in a fresh Windows Python 3.12 environment without author assistance and reproduced check/run/verify exits 0/1/0. It found stale documentation counts, a truncated terminal diff and ambiguity about whether verification writes the configuration.

We corrected those points, made Windows setup explicit and documented report exports. A second AI agent tested an isolated candidate copy: installation and export worked, and the YAML stayed unchanged. Its feedback also clarified that JSON contains the task diff and remedies, while fix displays the full proposed schema. The clarification received a subsequent documentation review.

These are separate-context AI reviews, not human user studies or independent third-party audits. Their value was concrete: observed onboarding friction led to a correction accepted by the maintainers.

Validation and boundaries

  • Linux Python 3.11 and 3.12 validation: 746 product tests and 104 repository guard tests on each; lint, formatting and typing passed.
  • Onboarding follow-up: 52 CLI tests, lint/formatting and the official repository validator passed; GitHub validation passed.
  • Fresh installation and AI reproduction: 21/21 corrected static scenarios, 10/10 benign cases, zero calls in those checks.
  • Four controlled real calls demonstrate the integration observations above, not the 21-scenario catalogue on real conversations.

Detection and remediation share a declared static model. A green result establishes consistency within that model, not hosted-agent reliability, real identity authentication or compatibility with every downstream application. Human usability, production impact and independent audio assessment remain unverified. A blocking Plan Firewall and automatic live policy verdict are not delivered claims.

Contributions and judge reproduction

Three contributions are merged into the official repository:

  • PR #304: the REDLINE application.
  • PR #366: explicit static-evidence wording and readable diagnostics.
  • PR #432: onboarding and verification guidance, merged September 11, 2026.

The video and commands below retain the originally demonstrated source pin. Use Python 3.11 or 3.12. Run each command separately: the baseline run intentionally exits 1.

git clone https://github.com/Damso74/awesome-phone-call-agents.git redline-demo
cd redline-demo
git checkout --detach 77e9ac449ea386f1369b7cf12f108f8fc4dfe9b9
cd apps/python/redline
python -m venv .venv
.venv/Scripts/python.exe -m pip install -e .
.venv/Scripts/redline.exe check --config examples/appointment-agent/redline.yaml
.venv/Scripts/redline.exe run --config examples/appointment-agent/redline.yaml
.venv/Scripts/redline.exe fix --config examples/appointment-agent/redline.yaml
.venv/Scripts/redline.exe verify --config examples/appointment-agent/redline.yaml --json .redline/verify.json --receipt .redline/release-receipt.json

These are Windows PowerShell commands. On macOS/Linux, use .venv/bin/python and .venv/bin/redline instead. Keep the source checkout: the wheel alone does not contain the full catalogue and example. Installation downloads dependencies; the local static evaluation requires no account or phone credits.

What's next

Test the onboarding and the new Evidence Review with human developers. The next evidence we need is practical usefulness, not a larger headline scenario count.

Built With

Share this project:

Updates

Submission history