First, understand the real question.
A prompt may contain an intended outcome, an assumption, a deadline and an unstated constraint. The proposed intake stage identifies the desired result and asks a concise clarification when a missing detail would change the answer. It can acknowledge a concern without validating an incorrect claim.
Context should be used with permission and a defined purpose. A future memory feature would need explicit controls for what is retained, corrected and deleted; this demonstration stores no conversation memory.
Route around the task and its boundaries.
Research, drafting, coding and numerical analysis need different capabilities. The intended gateway would choose from approved models and tools, rather than forwarding every prompt to every provider. Sensitive information would stay within its authorised boundary. Local, private and external processing choices require an explicit data-handling design.
Provider access, authentication, budgets, rate limits, fallbacks, logging and retention must be agreed before live use. No gateway is connected on this public site.
Compare evidence, not just confident language.
Review should look for unsupported claims, missing constraints, contradictory evidence and changes over time. A sourced response should identify the source and relevant date. If retrieval is unavailable, the response should say so rather than invent a citation.
Different models may repeat the same error. Consensus is a signal to examine, not a substitute for independent evidence. A response can preserve unresolved disagreement instead of forcing a false certainty.
A complete example.
Question: “Will faster broadband fix our slow applications?”
Clarify: Which applications are slow, for whom, at which times, and what does “slow” mean?
Check the premise: Access bandwidth is one possible bottleneck. Wi-Fi, packet loss, latency, application design, remote servers and endpoint capacity may also matter.
Evidence needed: A repeatable task, a wired comparison, latency/loss observations and application timing. These have not been measured by the demo.
Considered answer: Do not buy capacity on the assumption alone. Establish a baseline, isolate the slow segment and compare a targeted change. Upgrade access when evidence shows it constrains the required workload.
Prepared example, not a diagnosis or a live measurement.
Return a result people can assess.
The intended response format prioritises the conclusion, relevant evidence, material assumptions, uncertainty and next step. Review stages show a concise account of checks and findings, not private internal reasoning traces.
For financial, medical, legal or other consequential questions, the system should recognise its limits, use appropriate sources and preserve human professional judgement. An answer does not itself authorise a tool action.
Evaluate before expanding.
A live implementation needs representative tasks, known-answer examples, adversarial inputs and a way to record failures. Compare correctness, supported citations, privacy boundaries, latency and cost. A pleasing response or a second model’s approval is not sufficient evidence of quality.
Start with a bounded use case and clear success criteria. Decide who can approve tools, who reviews exceptions and how the system stops safely.
Discuss a bounded pilot ↗