Achilles — Query Engine: Stack and structure

Backend

stack — libraries

Framework / streaming

FastAPI StreamingResponse · SSE Pydantic v2

Models → Models in RAG

chat-client · tool-calling RRF-rerank ← KS → Knowledge Store

Conversation storage → Data model

SQLAlchemy 2.0 · async asyncpg Alembic Redis · exact cache → Cache & Workers

structure — files · achilles/query_engine/

query_engine/      module = its own package
├── *.py           service (orchestrator + SSE) · models · schemas · constants
├── routes/        HTTP surface: conversations · feedback · chat/models
├── rag/           body of search_knowledge: cache_gate → retrieve → augment · citations
└── conversation/  conversation storage (store over the ORM) + window budget (budget)

Why rag/ is its own folder

The retrieval route is a self-contained layer over the service: it calls the KS primitives as the search_knowledge tool, assembles the context, and streams the grounded generation. The search primitives themselves and their fusion live in Knowledge Store, not here.

Frontend

Query Engine has no frontend of its own. The conversation and answer UI is rendered by the surfaces (Web App · Slack · Telegram · Mattermost · Extension · MCP) as thin clients of one shared API: a single SSE answer stream, one conversation schema for all of them. Each surface owns its stack and chat shell (assistant-ui) — for the web that is Web App. Sessions and surfaces →

The tool-calling harness is a shared layer, not ours. The chat-client with a tool under the engine is one per platform, shared with Agent Engine; its home lives on a separate page, Tool-calling harness. Query Engine takes the degenerate parameterization — a single search_knowledge tool and one call without a loop.