ANDIP LIVE
Architecture

How ANDIP LIVE is structured

A provider-neutral intelligence layer that sits behind a live conversation. The voice platform keeps speaking; ANDIP LIVE coordinates time-bounded specialist work, verifies evidence, applies business policy, and returns qualified information before the caller loses patience.

01 — Design Principles

Five constraints shape every component

Real-time intelligence is not a background automation problem with a faster timeout. The architecture is shaped by the fact that a person is waiting on the other end of the line.

The conversation never blocks

Supporting work runs beside the call, not in front of it. Partial, qualified results are delivered as they become available instead of holding the response until every task ends.

Every request is bounded

Requests carry a deadline, a permission scope, and a cost constraint. Work that cannot finish inside its budget returns what it has, labelled with its own uncertainty.

Evidence is separated from inference

Verified facts, analytical inference, and proposed business action are kept distinct at every layer so the speaking agent can be precise about what it actually knows.

Recommendation is not authority

A recommendation is produced by the intelligence layer. Permission to commit the business comes from policy and, where required, from a human approver.

Context stays isolated

Information from one customer, organisation, or conversation is never exposed to another. Requests are traced back to the conversation that originated them.

Failure has a defined path

When a research task fails or times out, the system continues through a fallback rather than blocking indefinitely or inventing a comparison.

Scope of this page

Everything on this page describes proposed or under-development architecture. Diagrams are original conceptual illustrations of the intended design, not screenshots of a running system. Distributed execution and real-time performance remain engineering objectives that require implementation and reproducible validation.

02 — Architecture A

Full system view

Eight layers, from the person on the call down to the distributed workers that perform supporting work. The voice path stays thin; the intelligence path carries the complexity.

End-to-end system layers

Conceptual — proposed architecture

Full ANDIP LIVE system architecture across eight layers A customer speaks to a primary voice agent. The voice agent connects through a voice integration interface to the Live Decision Broker. The broker coordinates specialist agents, which work through an evidence and policy layer. All intelligence work executes on the ANDIP distributed infrastructure, which reaches approved external systems through direct APIs, optional browser verification, and authorised sources. VOICE PATH INTELLIGENCE PATH EXECUTION PATH CUSTOMER A live conversation with a real, time-bounded expectation PRIMARY VOICE AGENT Listening, speaking, turn-taking, and the primary conversation VOICE INTEGRATION INTERFACE Context, request, deadline, permissions, and update delivery LIVE DECISION BROKER Classification, prioritisation, routing, budget control, partial results SPECIALIST AGENT COORDINATION Parallel and targeted supporting work with bounded scope EVIDENCE AND POLICY LAYER Source status, confidence, eligibility, and action authority ANDIP DISTRIBUTED INFRASTRUCTURE Workers, task state, isolation, and resource controls APPROVED EXTERNAL SYSTEMS Business systems, approved data sources, and permitted verification QUALIFIED UPDATE DIRECT APIS Business systems and approved data OPTIONAL BROWSER Permitted verification only EXTERNAL SYSTEMS Authorised sources PROPOSED INTEGRATION
Voice path and live information flow Intelligence and infrastructure Policy, approval, and external authority Major control components

Why the voice path stays thin

The primary voice agent must remain responsive at all times. Placing research, comparison, and policy evaluation inside the speaking loop would make the conversation's latency a function of the slowest external system. The architecture therefore keeps the voice path limited to listening, speaking, and exchanging structured requests and updates.

Everything that can be slow — retrieval, verification, comparison, policy evaluation, and distribution — belongs to the intelligence path, where deadlines and partial results can be managed explicitly.

Why the evidence layer is separate

A response is only useful if the agent can be precise about its status. Separating evidence and policy from retrieval allows every returned item to carry its source, its timestamp, its confidence, and whether any action built on it is actually authorised.

This separation is what allows the system to say "this is verified", "this is probable but unconfirmed", and "this needs approval" — three very different statements that a single fluent answer tends to blur together.

03 — Architecture B

Dual-lane execution

Two connected lanes allow the voice experience to continue while supporting work progresses under a deadline. This is the core timing model of ANDIP LIVE.

Conversation lane and intelligence lane

Conceptual — proposed architecture

Dual-lane execution model with a conversation lane and an intelligence lane The conversation lane proceeds from the customer question to the primary agent, then a partial update, then the response. The intelligence lane runs from the Live Decision Broker through parallel tasks to the evidence and policy layer, and feeds the conversation lane at the partial update step. A return arrow shows the intelligence lane reporting back into the primary agent. CONVERSATION LANE CUSTOMER QUESTION Unexpected request PRIMARY AGENT Clarify and acknowledge PARTIAL UPDATE First useful evidence RESPONSE Explain or act INTELLIGENCE LANE LIVE DECISION BROKER Set deadline and task plan PARALLEL TASKS APIs, data, specialist agents EVIDENCE + POLICY Verify, rank, authorize

Design principle: return useful, qualified information as it becomes available. Do not wait for every background task.

How the conversation continues

The primary agent acknowledges the request, clarifies what is actually being asked, and keeps the caller engaged. The agent is never waiting on a silent blocking call — it is speaking while work proceeds beside it.

How updates arrive

The intelligence lane reports incrementally. A first useful result may arrive quickly and be spoken immediately, with a later, more complete result delivered as a refinement rather than a correction.

What happens at the deadline

When the deadline is reached, the broker returns what has been verified so far and labels the remainder as unresolved. The agent can then explain the limit honestly instead of stalling the conversation.

04 — Architecture C

Background and live intelligence

Two complementary sources of knowledge feed one shared contextual layer. Prepared knowledge handles predictable questions; live work resolves the exception.

Two modes converging on a common knowledge layer

Conceptual — proposed architecture

Background intelligence and live intelligence converging on a shared contextual knowledge layer Background intelligence periodically refreshes approved business information, producing a time-stamped knowledge layer. Live intelligence investigates only what the current call needs, under a deadline. Both paths write into a common contextual knowledge layer, which the Live Decision Broker reads when a request arrives. MODE A BACKGROUND INTELLIGENCE Refresh approved data before calls begin 1 Business policies and offer rules 2 Product, inventory, and pricing snapshots 3 Approved competitor observations 4 Time stamps, sources, and expiry rules MODE B LIVE INTELLIGENCE Investigate only what the current call needs 1 Targeted external verification 2 Current operational system lookup 3 Parallel specialist comparisons 4 Deadline-aware partial results COMMON CONTEXTUAL KNOWLEDGE LAYER Time-stamped, source-attributed, expiry-aware, conversation-scoped Live Decision Broker reads before deciding
A deliberate limit

Live customer conversations cannot depend on completing an unrestricted internet search every time a question arises. ANDIP LIVE therefore combines precomputed intelligence with targeted real-time verification. The objective is not to promise instantaneous access to every piece of information on the internet, but to deliver the most relevant, current, and trustworthy available context within the constraints of a live conversation.

05 — Architecture D

From information retrieval to policy-controlled recommendations

Four inputs are combined, qualified, and checked against authority before anything is returned. A recommendation does not equal permission to commit the business.

Decision support inputs and outputs

Conceptual — proposed architecture

Decision support architecture combining market evidence, internal state, business rules, and customer context Four inputs — market evidence, internal state, business rules, and customer context — feed a decision intelligence component that combines, qualifies, checks, and verifies authority. It produces four outputs: explain, offer, escalate, and qualify. Escalate routes to human approval. MARKET EVIDENCE Verified external facts INTERNAL STATE Pricing and availability BUSINESS RULES Authority and eligibility CUSTOMER CONTEXT Current need and history DECISION INTELLIGENCE COMBINE QUALIFY CHECK AUTHORITY EXPLAIN Relevant verified explanation OFFER Permitted business option ESCALATE Recommendation needs approval QUALIFY State uncertainty explicitly A recommendation does not equal permission to commit the business.
Verified explanation Permitted option Requires authority Explicit uncertainty

Four inputs

Market evidence
Verified external facts, with source and retrieval time recorded.
Internal state
Current pricing, inventory, and operational availability from business systems.
Business rules
What the business permits, who may approve it, and which conditions must hold.
Customer context
The current need, relevant history, and the specific conditions of this conversation.

Four outputs

Explain
A verified explanation the agent can state with confidence.
Offer
A permitted business option that has passed eligibility and policy checks.
Escalate
A recommendation that requires human approval before it can be presented.
Qualify
An explicit statement of what remains uncertain, and why.
06 — Architecture E

Distributed supporting execution

A live interaction may trigger several supporting tasks, but those tasks do not all need to execute on the same server as the voice application.

Deadline-aware distribution across a worker pool

Conceptual — proposed architecture, clearly labelled as planned

Distributed execution of supporting workloads across an ANDIP worker pool The Live Decision Broker splits a request into a real-time intelligence deadline track and an ordinary background track. Both are scheduled onto a pool of ANDIP workers with isolation and resource controls. Workers perform database queries, structured API calls, market comparisons, document analysis, pricing calculations, and authorised browser verification. Results return to the evidence and policy layer. LIVE DECISION BROKER Assigns deadline class, priority, and resource budget REAL-TIME INTELLIGENCE DEADLINE Strict upper bound · partial results required · highest priority ORDINARY BACKGROUND EXECUTION Relaxed bound · may complete after the call · lower priority ANDIP WORKER POOL — PLANNED DISTRIBUTED INTEGRATION Isolation, task state tracking, and per-task resource controls Database queries Structured API calls Market comparisons Document analysis Pricing calculations Authorised browser checks Policy evaluation Result aggregation EVIDENCE AND POLICY LAYER Verified, ranked, and authorised before returning to the agent
Deadline-bound live work Background and infrastructure work Authority check

The distributed integration is planned. Workloads may include database queries, structured API calls, market comparisons, document analysis, pricing calculations, and authorised browser-based verification. Browser automation is an optional capability rather than a mandatory dependency for every conversation.

Deadline class Live Strict bound, priority scheduling, partial results expected
Deadline class Background Relaxed bound, may complete after the conversation ends
Control Per-conversation Permissions, cost limits, and identifiers travel with the request
07 — Reading These Diagrams

A consistent visual vocabulary

The same colour carries the same meaning across every diagram on this website, so a reader can move between them without relearning the notation.

Diagram notation used throughout the ANDIP LIVE website
Element Meaning Appears in
Teal Live communication paths, the primary voice agent, and positive or verified states Architecture A, B, C, E
Blue Distributed infrastructure, the Live Decision Broker, and system components Architecture A, B, C, D, E
Amber Decision points, policy checks, approval requirements, and milestones Architecture A, D, E
Navy Major control components and shared layers Architecture A, C, D, E
Slate Explicit uncertainty and items that remain unresolved Architecture D
Dashed connectors Return paths carrying qualified updates back toward the conversation Architecture A
On mobile and smaller screens

Wide diagrams scroll horizontally rather than shrinking into unreadable miniatures. Where a diagram is not practical at a small size, the surrounding text describes the same structure in prose so the page remains fully understandable without it.

08 — Engineering Reality

What this architecture does not yet claim

ANDIP LIVE is presented as a proposed product entering its engineering and validation stage. The architecture above describes intent, not measured behaviour.

  • No latency, throughput, or cost figure on this website is a measured result. Those numbers require reproducible test evidence that does not yet exist.
  • The distributed execution model is planned. Worker orchestration, isolation, and scheduling behaviour remain engineering objectives.
  • Provider-neutral integration is a design goal. No voice-platform integration is complete or announced.
  • Evidence quality and policy evaluation depend on industry-specific integrations and data authorisation that have not been established.
  • Performance will be judged by time to first useful result, end-to-end intelligence latency, evidence verification quality, task completion and failure recovery, and cost per assisted conversation — none of which has been published.
Read the roadmap for the sequence

The order in which these objectives will be tested is described on the roadmap page, and the planned first demonstration is described on the community alpha page.

Where to go next

Live Decision Broker

How live requests are classified, bounded, routed, and returned.

How It Works

A step-by-step conceptual workflow with illustrative data.

Documentation

Component reference, lanes, evidence, and integration concepts.

Technology

Relationship to voice providers and the wider ANDIP platform.

Architecture is the part that must be right first

ANDIP LIVE is inviting technical review, research collaboration, and early community alpha interest while the architecture is still being validated.

Discuss a technical partnership See the development path

Development status

Architecture and Early Engineering

Community alpha

Q1 2027 — planning target

Target launch

Q2 2027 — subject to validation