🤫husshhussh
🤫husshhusshOnePuppy
Implemented · LLM systems · information retrieval · evaluation

What does it take to trace a grounded answer?

A streaming answer may look fluent long before it is trustworthy. The search harness carries a question through bounded conversation context, grounding sources, enabled connectors, synthesis, and SSE telemetry. The research gap is deciding whether that trace is sufficient for a person to inspect the result.

Read the companion essayAll open problems
Problem statement

The hard question.

Design an answer trace that exposes relevant evidence, tool decisions, and visible failures without exposing secrets, hidden reasoning, or unnecessary private context.

An agent’s latency, source quality, and tool behavior become especially visible on chained questions. A trace that cannot explain a slow or poorly grounded follow-up is not yet a useful operational interface.

Status

What is true today.

The search architecture implements bounded connector output, provider-aware schema adaptation, read/action separation, safety checks, and SSE events. Connector enablement and provider configuration remain deployment-specific.

Primary source: Search Console agent architecture

Constraints

The work is only useful if these survive.

  • Tool schemas are adapted before declaration to the active provider.
  • Workspace reads, connector output, and context size must be bounded.
  • A failure cannot turn into fabricated evidence or an invented capability.
  • Follow-up latency and quality must be measured on real chained questions.
Evaluation

How we would know.

Replayable source-conflict, connector-failure, and follow-up corpus.
Time to first visible event and time to useful completion.
Human audit of whether the trace supports or undermines the answer.
A first contribution

Start with something that can fail.

Build an eval corpus where the second prompt changes the question rather than appending text, then compare trace completeness, answer faithfulness, and latency across retrieval strategies.

Read it plainly, then make it better.

The companion essay is written for a broader technical audience. The repository and developer community are the places to turn a claim into a contribution.

Companion essayJoin Discord

One is a product of Hushh Technologies Corporation (brand: 🤫 “hussh”), an independent company. One runs on third-party silicon, systems, and cloud; platform names are used solely to describe where One software runs and imply no affiliation, endorsement, or sponsorship by those platforms. Our own go-to-market and bill-of-materials partner programs are real and actively in pursuit; we name a partner only once an agreement is executed.