Skip to main content
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

1

Ingestion

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.
2

Processing

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.
3

Storage

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.
4

Presentation

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:

Intents

Conversations are clustered into named intents, so you can see what users are actually trying to do and how that shifts over time.

Rules

Each response is judged against the plain-English rules you write, flagging where your agent stepped outside its SOPs.

Metrics

Latency, cost, success rate, and error categories are aggregated across every agent and tool you run.

Suggestions

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 and POST /capture-event.