ANDIP LIVE technical reference

Overview

ANDIP LIVE is a proposed real-time intelligence infrastructure designed to support conversational AI agents while they interact with customers. It does not replace existing voice platforms; it operates as an intelligence and decision-support layer connected to them.

The primary voice agent remains responsible for listening, speaking, understanding the customer's request, and maintaining a natural conversation. Behind the scenes, ANDIP LIVE coordinates specialized supporting agents that retrieve information, investigate market conditions, verify claims, calculate available offers, assess business rules, and return actionable context to the conversational agent.

The engineering problem is not speech. It is coordination under a deadline: several time-bounded lookups must produce a trustworthy answer while a person is still on the line.

Status and terminology

This documentation uses status words precisely. They are not decorative.

System components

Eight components appear repeatedly across the architecture. Each has a single clear responsibility, which keeps the voice path thin and the intelligence path controllable.

Primary Voice Agent

The customer-facing conversational system supplied by a voice provider. It listens, speaks, manages turn-taking, and decides how and when to communicate results to the customer. ANDIP LIVE does not replace it.

Voice Integration Interface

The boundary through which a conversational system submits requests and receives updates. It carries context, the request itself, the deadline, the permission scope, and the delivery contract for results.

Live Decision Broker

The central routing and control component. It classifies requests, plans and bounds work, sets priorities and budgets, and decides when available evidence is sufficient.

Specialist Agent Coordination

Schedules and supervises parallel and targeted supporting work — for example a rate-condition comparison, an availability check, or a documentation lookup.

Evidence and Policy Layer

Attaches source status, retrieval time, confidence, eligibility, and action authority to every returned item, and separates permitted options from escalations.

ANDIP Distributed Infrastructure

The parent platform layer that manages workers, task state, isolation, and resource controls, and that allows supporting work to run away from the voice application.

Background Knowledge Preparation

Periodically refreshes approved business information into a time-stamped knowledge layer that conversational agents can consult without a live deadline.

Monitoring and Cost Visibility

Tracks execution status, resource consumption, and cost per assisted conversation, and exposes failure states for operational review.

See the architecture page for diagrams showing how these components connect, and the platform page for the capability view.

Live Decision Broker

The broker receives intelligence requests from a primary conversational agent and determines how each request should be fulfilled. It is the component that turns an open question into bounded, scheduled, accountable work.

Responsibilities

• Classification. Determine whether the request is a known lookup, an operational query, a commercial comparison, or a consequential action requiring approval.
• Planning. Decide which tasks are necessary and which are unnecessary, avoiding agent creation when a cheaper path answers the question.
• Bounding. Attach a deadline, a permission scope, and a cost constraint to every task before it starts.
• Prioritisation. Give an active conversation a different service priority from background research that may finish several minutes later.
• Partial delivery. Release verified findings incrementally so the agent can speak before every task has completed.
• Sufficiency. Decide when the available evidence is good enough to produce a useful response, and when it must instead be qualified.

Handling paths

Timing classes are qualitative descriptions of intent. No latency measurement has been published, and the community alpha is the first point at which reproducible figures are planned.

Conversation and intelligence lanes

ANDIP LIVE separates two connected lanes so that the voice experience continues while supporting work progresses under a deadline.

Conversation lane

1. Customer question. An unexpected request arrives mid-conversation.
2. Primary agent. Clarifies and acknowledges without stalling.
3. Partial update. The first useful evidence is delivered and spoken.
4. Response. The agent explains, offers a permitted option, or states what remains unresolved.

Intelligence lane

1. Live Decision Broker. Sets the deadline and the task plan.
2. Parallel tasks. Authorised APIs, internal data, and specialist agents work concurrently.
3. Evidence and policy. Results are verified, ranked, and checked against authority.
4. Return path. Qualified findings re-enter the conversation lane as partial updates.

Background intelligence

Background intelligence is preparation before the conversation. Supporting agents periodically refresh approved business information so that predictable questions can be answered without a live deadline.

Live intelligence handles the exception: when a customer introduces something the prepared layer cannot answer, the request moves into the bounded live path described above. Both modes contribute to a common contextual knowledge layer, which the broker reads before deciding how to respond.

Specialist agent coordination

Specialist agents are not independent customer-facing voices. They are an invisible workforce coordinated to help the primary agent respond accurately and efficiently. Each is scoped to a narrow responsibility so that its output can be assessed on its own terms.

Coordination rules

• No specialist may commit the business to any action.
• Every specialist output carries its own source, timestamp, and confidence.
• Specialists receive only the context required for their task, scoped to one conversation.
• Tasks that exceed their deadline are cancelled or returned as incomplete, never silently extended.

Evidence and policy

A recommendation is not the same as permission to commit the business. This layer exists to keep that distinction enforceable rather than aspirational.

Decision 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.

Decision outputs

Distributed execution

A live customer interaction may trigger several supporting tasks, but those tasks do not all need to execute on the same server as the voice application. ANDIP provides the proposed foundation for coordinating multiple agents across available computing resources.

What ANDIP provides

• Coordination of multiple agents across available computing resources
• Management of execution environments
• Task tracking and result collection
• Control of resource consumption
• Worker isolation and task state

What ANDIP LIVE adds

• Short response deadlines tied to a live conversation
• Priority scheduling that favours active calls
• Asynchronous updates delivered incrementally
• Per-conversation context isolation
• Rapid information delivery within a strict bound

Workload classes

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. The distributed integration is planned, and real-time performance remains an engineering objective requiring implementation and reproducible validation.

Reliability and latency goals

Real-time intelligence requires a different engineering approach from traditional background automation. The platform must prioritise live requests, avoid unnecessary agent creation, and enforce response deadlines.

Measurement objectives

Reliability behaviours

• Deadline enforcement. Work that cannot complete in time returns partial results and an explicit uncertainty statement.
• Fallback path. If a research task fails, the conversational system continues operating rather than blocking indefinitely.
• Context isolation. Conversation-specific context is preserved so information from one customer or organisation is not exposed to another.
• Traceability. Requests carry explicit permissions, cost constraints, deadlines, and identifiers that allow supporting work to be traced back to the originating conversation.
• Result metadata. Results include timestamps, source references where applicable, confidence or evidence-quality indicators, and operational status.

Developer integration concepts

ANDIP LIVE is intended to expose a simple interface that voice-platform developers can integrate with their existing applications. The platform should support provider-neutral integration patterns rather than binding its core design to a single commercial voice service.

Conceptual request shape

{
  "conversation_id": "string — identifies the originating conversation",
  "question": "string — what the customer actually asked",
  "context": {
    "industry": "string — for example hospitality",
    "relevant_conditions": "object — dates, product, or account scope"
  },
  "deadline": "bounded by the broker",
  "permitted_actions": ["explain", "offer_eligible_benefit"],
  "budget": "constrained per assisted conversation"
}

Conceptual response shape

{
  "status": "partial | complete | unresolved",
  "evidence": [
    {
      "claim": "string",
      "source_type": "string",
      "confidence": "assessed indicator",
      "retrieved_at": "timestamp"
    }
  ],
  "recommendation": {
    "type": "explain | offer | escalate | qualify",
    "requires_approval": true
  },
  "uncertainty": ["string — what could not be confirmed"],
  "operational_status": "string — for monitoring and traceability"
}

Planned management capabilities

In future versions, developers may define reusable specialist agents, configure decision policies, connect approved company data, monitor execution, and evaluate business outcomes through a unified management interface. The objective is to make advanced multi-agent assistance available to smaller engineering teams without requiring them to build a distributed intelligence infrastructure from scratch.

Architecture roadmap

The architecture will be validated in stages, and each stage requires reproducible evidence before the next is treated as established.

• Now — Architecture and integration contractsDefine request, evidence, policy, and update schemas.
• Build — Broker and parallel executionPrototype one voice-agent request with incremental results.
• Q1 2027 — Community alphaA narrow, reproducible demonstration introduced through relevant developer communities.
• Validate — Reliability, latency, security, and costTest failure recovery and evidence quality against explicit objectives.
• Q2 2027 — Target launchSubject to successful technical validation and operational readiness.

Roadmap dates are planning targets and may change as technical validation progresses. See the roadmap page for the full sequence.

Known limitations

Documenting what is not yet known is part of documenting the architecture honestly.

• Nothing described here is implemented, released, or available for integration.
• No latency, cost, reliability, or concurrency figure has been measured or published.
• Provider-neutral integration is a design goal, not a completed capability.
• Distributed execution, worker isolation, and priority scheduling remain engineering objectives.
• Evidence quality and policy evaluation depend on industry-specific integrations and data authorisation that have not been established.
• Some external research cannot complete within a live conversation. This limitation is designed into the product rather than hidden by it.
• Interfaces shown in this documentation are illustrative and will change.