Achilles — Query Engine

Orchestrator of the user conversation — not just RAG. The turn is led by a chat model chosen by the user; it holds the search_knowledge tool (when the base is non-empty) and decides on each message whether to reach into the base. Small talk — it answers from itself; a knowledge question — it calls search and builds the answer on what it retrieved, with streaming and citations. Retrieval itself (search and the ACL pre-filter) belongs to Knowledge Store; Query Engine does not do it — it invokes it as a tool.

Architecture

Four pillars of the module

⟨ ⟩

Dialog

Query Engine is a conversation orchestrator, not just RAG. It holds the state; surfaces are thin clients.

conversations messages retrieval_trace access_counter

✦

Model decides

The turn is led by a chat model AI — one tool in hand.

search_knowledge

↩ Small talk — answers from itself, no citations

⇲ To the knowledge — calls search_knowledge

▸▸▸

RAG route

One call — five steps. The ownership boundary runs along the belt.

◇ exact cache? → skips the belt

Embed › Retrieve › Rerank › Augment › Generate

KS·2 QE·3

Grounding

The answer contract — three promises.

✓ Only from what was retrieved — not from the model's memory

¶ A citation per record — for every claim

∅ An honest “not found” over a guess

↻one optional call without a loop ⤳Agent Engine bypasses Query Engine ⇉answer: answer + citations, streamed

API

POST/api/v1/conversations
GET/api/v1/conversations/{id}
POST/api/v1/conversations/{id}/messages · SSE
PATCH/api/v1/messages/{id}/feedback
GET/api/v1/chat/models

Workzone Design

Detailed design decisions for the module.

RAG route Dialog Grounding and citations Boundary with Knowledge Store Protection and privacy Data model Stack Tests

Wireframes Surfaces

The module has no frontend of its own — the conversation and answer are rendered by the surfaces as thin clients of one shared API. The chat screens (grounded answer, answer states) live in Web App; the grounding contract itself lives in the workzone, Grounding.