Skip to main content
ZombieMutex

30 results · ↑ ↓ navigate · Enter open · Esc close

Voice agent engineering

Project 02 / 05

Engineering implementation

Voice Agent Evaluation & Red-Team Harness

I built a repeatable agent-evaluation harness covering caller verification, injected instructions, tool permissions, missing inputs, interruptions and human escalation. Good manners are not a security policy.

I built a repeatable evaluation set for the cases polished demos rarely include: adversarial callers, malicious tool text and incomplete intent.

Execution architecture

From conversational request to a validated backend action.

  1. 01

    Load a synthetic dialogue fixture

  2. 02

    Derive requested intent and tool action

  3. 03

    Apply identity, tool-scope and escalation policies

  4. 04

    Compare observed decision with expected outcome

  5. 05

    Record pass/fail and failing guardrails

  6. 06

    Rerun on each policy or adapter change

What I built

  • Implemented scripted caller and tool-output fixtures for injection attempts, missing information, identity checks and escalation.
  • Implemented repeatable policy checks with explicit expected versus observed outcomes.
  • Separated deterministic policy test results from real-model quality measurements.

The actual trust boundary

User speech, retrieved content and tool results are data. Privileged tool actions need explicit policy and independent validation.

The model can propose a tool call; the executor independently validates the principal, resource and side effect. I deliberately keep that boundary out of the prompt.

Failures I tested and designed around

  • Prompt injection must not become a new system instruction.
  • Tool output must not expand caller permissions.
  • Missing required fields must trigger clarification.
  • Unknown policy exceptions go to an authorized human.

The operational tradeoffs

These are the constraints that shaped the API boundary. Customer infrastructure and internal metrics remain private.

  • Evaluation must separate intent extraction, tool selection and resulting side effects; audio interruptions and poisoned tool text expose different failure paths.
  • Versioned acceptance runs and human-reviewed disagreement cases keep a passing policy fixture from becoming a false claim of model accuracy.
  • A model-regression gate cannot confer privilege. Tool scope and caller verification still belong to the backend executor.

Engineering judgment

An impressive demo is one successful test. Reliability needs a lot of deliberately awkward ones.

I can show the integration contracts, tests and failure paths without publishing customers' configurations, recordings or internal infrastructure.