> ## Documentation Index > Fetch the complete documentation index at: https://docs.usehone.dev/llms.txt > Use this file to discover all available pages before exploring further. # Architecture > A plain-English tour of how Hone works: from ingestion, through processing and an analytical store, to the dashboard where signals surface. You do not need to know how Hone is built to use it, but a mental model helps when you are deciding what to send and reading what comes back. Hone moves your telemetry through four stages: it arrives, it is normalized and routed, it is stored for fast analysis, and it is presented as signal. ## The path an event takes Your agent sends telemetry to Hone. There are three ways in: the Conversations SDK from your application code, the MCP wrapper around an MCP server, or an existing OpenTelemetry exporter pointed at Hone. All of them land at the ingestion edge. Incoming telemetry is normalized into a common shape, checked against your API key, and routed onward. Raw, differently shaped payloads become uniform events that the rest of the system can reason about. Events are written to two stores. A durable record keeps history for retention and compliance. An analytical (OLAP) store keeps the same data in a form built for fast aggregation, so dashboards answer in real time even over large volumes. The dashboard reads from those stores behind authentication, and renders the health views, conversation intelligence, and signals you act on. ## Why two stores Splitting storage is the key architectural choice. The durable store answers "what exactly happened, and can I still see it later." The analytical store answers "across millions of events, what is the trend, the percentile, the rate." Keeping both means Hone can show a sub-second dashboard and still hold the ground-truth record behind it. The analytical store is also what lets alerting work in plain English. A condition you describe in words is compiled into a query the analytical store can run on a schedule, which is only practical because the data already lives in a form built for exactly those questions. ## What Hone does with your events after they land Once events are stored, classifiers read the raw text and turn it into higher-level signal: Conversations are clustered into named intents, so you can see what users are actually trying to do and how that shifts over time. Each response is judged against the plain-English rules you write, flagging where your agent stepped outside its SOPs. Latency, cost, success rate, and error categories are aggregated across every agent and tool you run. Surfaced issues are distilled into prioritized, evidence-backed recommendations for improving your agent. ## Where the SDK fits Everything you send shapes what these stages can produce. The event tree you build with `parent_id` is what makes the trace view meaningful. The `checkpoint.*` metadata you attach is what draws per-tool timelines. The metadata keys you allowlist become the dimensions you can filter and chart on. A little care at ingestion pays off across every view downstream. For the exact fields the ingestion edge expects, see [POST /capture-session](/api-reference/capture-session) and [POST /capture-event](/api-reference/capture-event).