Skip to main content
ZombieMutex

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

Voice agent engineering

Project 01 / 05

Engineering implementation

Voice Agent Workflow Orchestration

I built a voice-agent workflow gateway that turns appointment requests into authenticated API operations, with tenant-scoped access, idempotent updates, and recovery when a response disappears after a commit.

I built the integration around the uncomfortable question: how does a natural-language request become an authorized business action?

Execution architecture

From conversational request to a validated backend action.

  1. 01

    Caller speaks or types a request

  2. 02

    Speech/LLM adapter interprets intent (integration seam)

  3. 03

    Tool proposal validated against typed schema

  4. 04

    API checks authenticated principal and booking ownership

  5. 05

    Transactional appointment update or explicit escalation

  6. 06

    Outcome event recorded with correlation ID

What I built

  • Implemented a Node.js appointment API with verified first-party credentials and tenant-scoped booking access.
  • Implemented operation-ID deduplication, request fingerprint conflicts and recovery after simulated lost responses.
  • Tested unauthorized access and concurrent duplicate submissions against the API.

The actual trust boundary

Transcript and model output are untrusted. The backend decides which identity can change which booking, not the model or a caller-supplied customer ID.

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

  • Cross-tenant changes must be denied even when the intent is valid.
  • Repeated logical actions must not double-book or double-charge.
  • Timeout means the outcome is unknown; reconcile before retrying a write.
  • Uncertain identity requires a human handoff, not an optimistic guess.

The operational tradeoffs

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

  • Tenant-scoped unique operation keys and fingerprints are the persistence boundary for ambiguous writes; retrying a timeout without reconciliation can duplicate a side effect.
  • Tool-schema versions and model/prompt versions have independent compatibility risks. A canary rollout needs representative call outcomes, not just fluent transcripts.
  • A trace needs to distinguish accepted side effects, denied actions and human escalation without exposing the conversation or credentials.

Engineering judgment

The agent can ask good questions. It cannot grant itself permission to answer them on behalf of someone else.

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