Execution Ledger and Run Costs

The execution ledger is the Botlit concept for a single, searchable record of everything the agents in a workspace have done. The illustration shows an Executions page whose subtitle states the scope plainly: every agent, app and workflow run. Four summary tiles across the top carry the totals for the selected window, covering run count, tokens consumed, spend and a ninety-fifth percentile latency figure, so the health of the fleet reads at a glance before anyone opens a row.

The problem is that agent work is invisible by default. A reply appears in a channel, a workflow finishes, a delegated task completes, and none of it leaves a trace a finance or operations team can inspect. Without one, a failure is noticed only when someone complains, and a cost increase is noticed only on an invoice. The design answers that with a ledger rather than a dashboard: status filters for completed, failed, timed-out, cancelled and running work sit beside a time-range control, a search field in the top bar narrows the view to one agent, and the table underneath lists each run with its identifier, the kind of run, the agent or bot responsible, a status badge, duration, token count, cost, the model used and the start time. The sample rows span a chat turn, a channel message, a workflow and a delegated agent-to-agent run, including one failed run that consumed no tokens and cost nothing.

In the design, the selected run opens a detail rail on the right. It repeats the run identifier and status, restates duration, tokens and cost as tiles, then breaks the run down further into input and output tokens, tool calls and the number of retrieved chunks that were injected. A model section names the model, its provider and a note that it runs on a workspace key, and collapsible input and output sections show the question that started the run and the beginning of the answer it produced.

The concept ties the rest of the product together. The run identifier shown here is the same one that appears on a tool loop, the retrieved-chunk count matches what a grounded chat reply reported, and token counts are the unit a daily token budget policy measures against. Failure rates, cost per run and retrieval results of this kind are also the evidence the operations findings concept cites when it flags a regression.