The Live Decision Broker
The proposed ALI — ANDIP Live Intelligence component that turns a conversational request into a bounded, evidence-aware plan for action.
A control point between the question and the answer
The broker keeps the primary voice agent responsive while specialist work proceeds under explicit operating rules.
The Live Decision Broker receives intelligence requests from conversational agents and determines how each request should be fulfilled.
It sets deadlines, builds task plans, assigns priorities, enforces budgets, and decides when available evidence is sufficient to produce a useful response. The broker is not a second customer-facing voice; it is the proposed coordination layer for live supporting intelligence.
Depending on the request, it may answer from approved internal context, call an authorized operational system, delegate targeted research, verify information in parallel, seek a policy-controlled recommendation, or route the matter for human approval.
Useful now, qualified always
The broker can return an incremental result when the deadline arrives. It preserves source status, confidence, open questions, and authority boundaries rather than presenting an unfinished investigation as certainty.
Match the work to the question
These are conceptual routing paths for the proposed broker. Latency labels are qualitative expectations, not measured performance claims.
| Path | Typical latency expectation | Evidence requirement | Typical example |
|---|---|---|---|
| 1 · Internal lookup | Immediate | Current, approved internal context | Read a published cancellation rule |
| 2 · Authorized API lookup | Seconds | Authorized system response with timestamp | Check live inventory or account status |
| 3 · Specialist research | Bounded | Relevant sources with task-specific notes | Investigate an unexpected competitor offer |
| 4 · Parallel verification | Bounded | Convergent evidence from independent paths | Compare rate, conditions, and availability |
| 5 · Policy recommendation | Bounded | Evidence plus applicable policy and eligibility | Suggest an allowed service recovery option |
| 6 · Human approval | Asynchronous | Named authority or recorded approval | Request a non-standard commercial concession |
Classify first. Route deliberately. Converge with a contract.
The proposed tree makes the broker's choices visible without implying a published API or completed implementation.
Conceptual broker routing tree
Proposed decision flow
Text alternative: the request enters the broker, is classified, and is routed to one or more handling paths before converging on Explain, Offer, Escalate, or Qualify. If time runs out, the broker returns what it has with uncertainty stated plainly.
Rules that keep live work bounded
A capable broker must be disciplined about both what it can do and what it cannot claim.
Classify the request before selecting tools. Preserve relevant conversation context while isolating each conversation's data, permissions, and working memory from every other interaction.
Set a deadline, rank tasks by customer impact, and enforce a bounded budget for calls, agent work, and external research. A lower-priority task must not consume the resources needed for a live response.
Return the first useful qualified result when appropriate. If a source fails or time expires, fall back to approved internal context, explain the gap, and avoid turning absence of evidence into a guess.
Record source identity, freshness, and relevance. Distinguish corroborated evidence from a single observation, and expose uncertainty whenever evidence is incomplete, conflicting, stale, or outside the permitted scope.
Evidence, inference, and action stay separate
Every recommendation should preserve the distinction between factual evidence, analytical inference, and proposed business action.
{
"request_id": "conversation-scoped-id",
"question": "Compare the advertised rate",
"context": {"dates": "provided by agent", "authority": "read-only"},
"deadline": "conversation-bounded",
"budget": "policy-defined",
"allowed_paths": ["lookup", "api", "verify"]
}{
"contract": "qualify",
"evidence": [{"finding": "conditions differ", "source": "authorized lookup"}],
"inference": "The offers are not directly comparable",
"proposed_action": "Explain the difference; no discount committed",
"uncertainty": ["external availability not confirmed"],
"authority_required": false
}The same control logic, different conversations
These illustrative flows show how routing can adapt to the domain without changing the underlying discipline.
Classify: commercial and consequential. Paths: authorized availability lookup, targeted rate-condition research, and parallel verification. Return first: a qualified comparison of dates, room type, taxes, cancellation terms, and availability. Withhold: any discount or parity commitment until eligibility and business authority are confirmed.
Classify: operational, with potential account impact. Paths: isolated account-context lookup, documentation retrieval, and specialist troubleshooting in parallel. Return first: the known symptoms, safe next diagnostic step, and source-backed status. Withhold: unsupported root-cause claims, entitlement changes, or remediation promises pending authority and verification.
A broker is useful because it knows where to stop
The proposed component is designed to make uncertainty visible, not to hide it behind fluent language.
Routing intelligence is not business authority. The broker can recommend a next step, but permission must come from the applicable policy, system, or human decision-maker.
- It will not invent a comparison. Missing prices, conditions, or availability remain missing.
- It will not commit the business. A recommendation is not a discount, refund, booking change, or contractual promise.
- It will not block the conversation indefinitely. Deadlines produce a partial result, fallback, or escalation.
- It will make uncertainty explicit. Conflicting, stale, or incomplete evidence is labelled rather than guessed through.
See the broker in the wider system
Explore the proposed architecture, the operating model, and the documentation direction for ALI — ANDIP Live Intelligence.