Agents that say I don't know before they say I think.

The problem​

The team's prior RAG stack had become an embarrassment by inches. It returned cosine-near passages with confidence the model had not earned, glued them into prose without attribution, and never said "I don't know" — because the architecture had no slot for the answer. Customer support engineers were spending more time fact-checking the agent than they would have spent answering the question themselves.

The harder cost was the second-order one: support tickets the agent had touched were now harder to audit, because the agent's reasoning trail was a generation prompt and a similarity score. There was no record of which gnoses the answer leaned on, which it didn't, and which had been silently dropped because they were too inconvenient.

The approach — retrieval, then refusal​

Gnostikon-backed retrieval changes the agent's contract with the user. Three commitments shape that contract:

• Every shipped claim ships with provenance. The agent links to the gnoses it leaned on, the confidence each carried, and the revision pair the codex was on at the time of the call. Reviewers walk the trail; they do not interrogate the model.
• The pinned ethos gates the candidate set. If scientific_rigor forbids speculation, the retriever will not surface a gnosis flagged as speculative — even if it is a perfect cosine match. The retrieval layer obeys the mandate.
• Refusal is a first-class outcome. When the codex has not validated a claim, the agent says so. The platform exposes the reason: low confidence, missing references, conflicting gnoses, or — most often — no relevant gnosis at all.

The agent stopped sounding confident about things it had no business knowing. Our QA cycle dropped a full day because we stopped having to chase ghosts.

MCMarina C. — Engineering lead, support_v4 agent

Shape of a retrieved answer​

A response from a Gnostikon-backed agent is structured: a plain-language answer, a list of supporting gnoses with their confidence bands, a citation chain that resolves to source paragraphs, and — when relevant — a list of conflicts the platform surfaced but did not resolve.

The format is the same whether the agent shipped an answer or refused. A refusal carries the candidate gnoses the retriever considered, the reason each one failed validation, and the suggestion of which scope or ethos would have admitted them. A refusal is a structured response, not an empty one.

Operations & telemetry​

Each query produces a single op_id that captures every retrieval, every validation, and the final disposition. The trail makes it possible to ask, weeks later, why a specific response shipped — and whether the codex would still ship it today.

Outcomes across one cohort​

• −74%
  Hallucinations measured against an independent eval suite.

  A blind eval of 1,200 production queries scored on factual grounding showed Gnostikon-backed retrieval cutting unsupported claims by nearly three quarters versus the prior cosine-similarity stack.

• 92%
  Of shipped answers carry full provenance.

  Each cited gnosis links back to its origin record — paragraph, document, recording offset, or commit. The remaining 8% refused outright instead of fabricating.

• 18%
  Of queries refused as under-validated.

  Refusals trended stable across cohorts, which is the right signal: the agent was not learning to say "yes" under pressure. Refused queries became Aletheia tickets the team triaged.

• 0
  Audit findings on agent claims this quarter.

  When a regulator asked for evidence behind a flagged response, the operation log carried the gnoses, the ethos, and the revision pair. The case closed in twenty minutes.

Implementation playbook​

Four decisions worth making early when you wire a RAG agent to a Gnostikon backend.

1 · Pin the ethos in the agent definition, not in the prompt.​

Prompt-injected ethos drifts with every prompt edit. A pinned ethos is a versioned object; the agent inherits it by reference. When the rules change, the change is auditable.

2 · Make refusal a UI affordance, not a fallback string.​

Surface refusals with the same care you give shipped answers — same layout, same citation slot, same provenance block. Users learn to read a refusal as a useful response. Prompt-style fallbacks teach them the agent is broken.

3 · Log the candidate set, not just the chosen one.​

The gnoses the retriever considered and rejected matter as much as the ones it shipped. Future audits ask "why this and not that" — answer both halves of that question in the operation log.

4 · Treat low-confidence shipped answers as a triage queue.​

A shipped answer with confidence below the team's working threshold is not a bug — it is a human-review prompt. Route them to an Aletheia ticket queue; let the team converge on whether to amend the codex or tighten the ethos.