thinkingPage.backToThinking

Build case study · Voice AI · Operations

Building Anruvo: Why an AI Phone Agent Needs Deterministic Business Logic

August 13, 2026Damir Andrijanic10 min read

I started Anruvo with a simple observation: service companies do not lose value because nobody can transcribe a call. They lose value when a call is missed, important facts remain incomplete, urgency is judged inconsistently, or the next action never reaches the right person.

That changes the architecture. A useful AI phone agent cannot end at a natural conversation. It must turn the call into a structured operational case, apply the company’s rules, expose uncertainty, and hand the result to a human team without inventing what happened.

This is a transparent look at the system I am building for the German Mittelstand, with SHK as the first specialized industry mode. It covers what is functional, why deterministic logic sits outside the language model, and what remains before a paid voice pilot.

Anruvo architecture transforming an incoming voice call into a rule-validated operational case

Core design decision

The model understands the conversation. Business rules decide what happens next.

A voice model is suited to dialogue and extraction. It is not the final authority for emergency classification, service-area checks, callback priority, appointment eligibility, or a claim that a case was created. Those decisions belong to versioned server-side logic and verified tool results.

The Anruvo control path

01

Conversation

The voice model speaks German, discloses that it is AI, and collects facts required by the active industry schema.

02

Structured intake

A typed tool call submits validated fields and reports missing information explicitly.

03

Decision engine

Versioned rules determine safety handling, priority, eligibility, and the allowed next action.

04

Operational case

The verified result becomes a tenant-isolated case for a human team, with traceable status and recommendation.

1. Start with the operational outcome, not the voice demo

A convincing voice demo can answer naturally. The business outcome, however, is a complete case that the office can act on: caller, location, issue, system details, urgency signals, customer status, and a permitted next step.

The experience is designed backwards from the cockpit. Every question exists because a later rule or employee needs the answer. Missing required fields remain explicit instead of being presented as a finished request.

2. Separate conversation from decision logic

The intake engine is a deterministic API boundary. It receives structured fields and returns a decision, missing information, and a rule trace. Current SHK rules cover gas odor, active water leaks, total heating failure, vulnerable households, service area, opening hours, callback priority, and appointment routing.

This separation makes behavior testable without a real call and prevents a prompt or model update from silently changing an emergency path. The assistant may collect facts, but it confirms a callback, transfer, or appointment only after the corresponding tool succeeds.

3. Turn accepted calls into inspectable cases

The customer cockpit is the operational surface where teams see open and urgent cases, safety answers, the rule-based recommendation, and processing status. A protected workspace reads tenant-isolated organizations and cases from Supabase.

Employees receive a structured summary instead of replaying audio or interpreting a transcript. They can take ownership, complete the work, and inspect why the system assigned a priority.

4. Treat privacy claims as architecture constraints

Anruvo begins with an explicit AI disclosure. Audio recording is not configured, durable transcript storage is not implemented, Realtime tracing is disabled, and the webhook logs only an error class rather than payloads or SIP headers.

These defaults reduce exposure but are not a complete compliance claim. Provider retention, data residency, DPAs, deletion, access control, and lawful basis still require review before a paid pilot.

5. Build the telephony boundary for failure

The SIP entrypoint accepts signed OpenAI Realtime incoming-call webhooks and rejects unsupported events. A German number can connect through a secure Twilio SIP trunk to the OpenAI EU SIP endpoint. The accepted session starts in German and states that it is an AI assistant.

The remaining milestone is a persistent sideband controller. It must execute the structured submit-case tool, run deterministic rules, return the result, and transfer only when a rule and configured human target allow it. A serverless route is not a durable WebSocket worker.

6. Use a narrow industry mode to make the platform real

Anruvo is positioned for service-oriented German Mittelstand companies, while SHK is the first specialized mode. The vertical focus makes fields, urgency, territory, opening hours, and escalation rules concrete enough to test.

Once the pattern works in one demanding workflow, further modes can reuse the platform with their own schemas and decisions. The reusable product is the controlled path from conversation to business action, not a generic prompt.

7. What works now and what comes next

The marketing experience, pilot intake, SHK simulator, deterministic intake API, cockpit preview, protected Supabase workspace, status updates, and signature-verified SIP webhook are implemented. They support honest testing of the product model and non-voice workflow.

Next come the persistent sideband service, end-to-end call execution, transfer and failure tests, observability, retention review, and a controlled pilot with one real business before a broad launch claim.

Current product boundary

Functional SHK simulator and deterministic intake API

Protected workspace with tenant-isolated Supabase data

Signature-verified OpenAI Realtime SIP entrypoint

Persistent sideband controller for live tool execution

End-to-end transfer, timeout, retry, and reconciliation tests

Provider DPA, retention, and production deployment review

The real product begins where the conversation ends

Voice quality matters, but the hard part is deciding what the conversation may cause, proving that the action succeeded, and giving the business a usable result when the model or a dependency is uncertain.

Anruvo is my attempt to build that control system for everyday service operations: conversational at the edge, deterministic at the decision boundary, and human-owned at the point of action.

Building a voice or workflow AI system?

I design the structured outputs, rule boundaries, tool execution, and operational handoff that turn an AI interaction into dependable business software.

Start a conversation