The Intelligence Layer Behind the Conversation
ANDIP LIVE is a proposed provider-neutral intelligence layer for voice AI: coordinating evidence, policy, specialist work, and incremental recommendations while the primary voice agent keeps the conversation moving.
Support the voice provider; strengthen the decision
ANDIP LIVE does not replace voice providers. It is designed to make their conversational agents more informed without taking ownership of the primary call.
The conversation remains here
Listening, speaking, turn-taking, and the primary relationship
- Receive audio and understand the caller's request
- Manage turn-taking, clarification, tone, and response delivery
- Decide how to communicate an answer in the live conversation
Structured intelligence works behind it
Research, verification, policy-aware recommendations, and operational signals
- Accept a bounded request with context, deadline, permissions, and budget
- Coordinate specialist agents and external lookups under that request
- Return qualified evidence and recommendations incrementally
The provider remains responsible for the customer-facing voice experience. ANDIP LIVE is a proposed supporting layer, not a new voice, speech, or turn-taking provider.
Nine proposed capabilities for time-bounded intelligence
These capabilities describe the intended platform surface. Each remains proposed or under development.
Primary Voice Agent Integration
Provide a structured handoff between a voice agent and supporting intelligence without moving the call itself.
Live Decision Broker
Classify requests, set bounds, prioritize work, and assemble useful results against a live deadline.
Specialist Agent Coordination
Route bounded subtasks to research, operations, policy, and other specialist workers.
Evidence Verification
Attach source references, timestamps, and evidence-quality signals before a recommendation is returned.
Business Policy Evaluation
Evaluate proposed actions against supplied eligibility, authority, and business-rule constraints.
Background Knowledge Preparation
Prepare approved, time-stamped context before calls so predictable questions need less live work.
Incremental Intelligence Delivery
Return a first useful signal and subsequent evidence rather than waiting for every task to finish.
ANDIP Distributed Execution
Use the parent platform's available execution resources while preserving task and worker boundaries.
Monitoring and Cost Visibility
Expose operational status, resource consumption, latency signals, and cost estimates for review.
How the components work together
A conceptual stack separates the live voice path from intelligence coordination and distributed execution.
Capability stack and integration surfaces
Conceptual
Conceptual architecture. Integration surfaces and execution behaviour remain subject to engineering validation.
A bounded request in; qualified progress out
The proposed contract makes the live deadline and operating constraints explicit before supporting work begins.
- Request intakeQuestion, conversation context, deadline, permissions, and budget are supplied by the calling system.
- Plan and prioritizeThe broker chooses bounded work, avoids unnecessary agent creation, and records the active task state.
- Incremental deliveryStatus updates and first useful evidence can arrive before every background task completes.
- Qualified recommendationResults carry timestamps, source references, confidence or evidence-quality signals, and operational status.
{
"request": {
"question": "Can this offer be extended?",
"context": "conversation-scoped facts",
"deadline": "live-request boundary",
"permissions": ["read:policy"],
"budget": "bounded"
},
"updates": [
{"status": "working", "timestamp": "..."},
{"evidence": [], "confidence": "qualified"},
{"operational_status": "complete"}
]
}Conceptual delivery sequence
Not a published API
Illustrative sequence only. The shape describes a design contract, not a released endpoint.
Controls for live work and accountable execution
These are platform priorities and design guarantees to validate during engineering, not claims about released performance.
- Live work first. A request attached to an active conversation is prioritised over background preparation when resources compete.
- Strict deadlines. Supporting tasks operate against an explicit time boundary and can return a qualified partial result.
- Only necessary agents. The broker should create or route work only when the request justifies it.
- Conversation isolation. Context is scoped per conversation so one caller's information is not silently reused for another.
- Defined failure fallback. A failed task reports its status and limitation, allowing the voice agent to explain uncertainty or continue with a safer response.
- Visible operations. Cost, latency, resource consumption, and task status are intended to remain inspectable.
Honest answers for an early platform
ANDIP LIVE is in Architecture and Early Engineering. The answers below separate direction from release status.
No. The architecture is intended to support voice providers. They keep listening, speaking, turn-taking, and the primary conversation; ANDIP LIVE supplies supporting intelligence.
Offline operation is not a completed capability. Some background knowledge could be prepared ahead of time, but live verification and business-system access may require connected systems.
The project is in Architecture and Early Engineering. The community alpha is a target for Q1 2027 and the target launch is Q2 2027; these are planning targets, not released-product claims.
Provider neutrality is an architectural goal. Specific integrations, compatibility details, and support commitments remain under development and will require technical validation.
Not by itself. Recommendations should remain subject to supplied permissions, business policy, and the authority of the connected system.
Trace the proposal from architecture to participation
Read the system view, inspect the broker concept, review the documentation direction, or follow the community alpha path.