Etherforce Observability

Every agent request that runs inside Ishvana goes through Etherforce, the dispatch layer between app surfaces and the Divinity Engine. Before v1.2.0 this area described model routing and external-provider usage. As of May 1, 2026, the panel observes local handler dispatch instead: which divinity/<handler> ran, which agent surfaced it, how long it took, whether it hit cache, and what findings or items came back.

The panel has six tabs. Most authors only open Dispatches and Analytics when investigating a result; the other tabs exist so engine behavior is inspectable instead of mysterious.

The six tabs

Handlers Every registered Divinity Engine handler, its owning agent, engine version, and input contract.

Dispatches The live invocation log: handler id, scope, timing, cache status, errors, findings, and items.

Analytics Throughput, latency percentiles, cache hit rate, and failure trends over recent dispatches.

Skills Reusable writing instructions and style guides attached to supported local handler surfaces.

Tool Registry Every registered local agent tool, grouped by owner, with invocation counts.

Benchmark Handler-revision fixture runs for catching output drift before release.

Handlers

The Handlers tab is the catalog for the Divinity Engine. Each row shows the handler id, owner, engine version, description, input schema, and whether it supports streaming. This is the same registry that powers source-handler badges across the app.

Use it when you want to answer “what can the engine actually run?” or “which agent owns this finding?”

Dispatches

The Dispatches tab is the live log. Every handler invocation records:

the agent that surfaced the request,
the divinity/<handler> id,
the scope reference, such as project, document, scene, or lore entry,
applied parameters,
cache hit or miss,
duration and timing metadata,
success or error state,
finding and item counts.

Click a dispatch to inspect the envelope. Chat bubbles, council sessions, analysis panels, and editor findings can all point back to this record when they expose a dispatch id.

Analytics

Analytics aggregates the recent dispatch log. It shows total dispatches, average and percentile latency, cache hit rate, failures, throughput over time, and per-handler timing trends.

This is where you go when a scan feels slow or a handler starts failing. The point is local diagnosis, not cloud spend management.

Tool Registry

The Tool Registry tab lists the local tools agents can use around handler dispatch: Legendry lookup, document read, scene metadata read, research bookmark access, monitored feed lookup, Wikipedia helpers, and similar backend capabilities.

Each tool row includes its owner, description, parameter count, and invocation count. If a response lacked context you expected, this tab helps confirm whether the relevant lookup tool ran.

Skills

The Skills tab shows reusable writing instructions defined for the project. They are not an LLM prompt budget surface anymore; they are project rules that supported local handlers and authored-library renderers can apply when producing findings or advice.

Benchmark

The Benchmark tab runs handler-revision fixtures. Pick a handler, select fixtures, capture a baseline, and compare later runs against that baseline. Results are reported as pass, improved, or regressed so engine changes can be checked before release.

See Legendry Bench for the current benchmark workflow.

How the tabs relate

Handlers tells you what exists. Dispatches tells you what ran. Analytics tells you how the recent run history behaves. Tool Registry tells you which local capabilities agents used. Skills tells you which project instructions are available. Benchmark tells you whether a handler’s output drifted between revisions.

What’s next

Etherforce The conceptual overview of Etherforce as the Divinity Engine dispatch layer.

Legendry Bench Handler-revision benchmarks for deterministic lore and consistency checks.

Agent Overview Per-agent success rates that complement Etherforce's handler metrics.