Skip to Content

Deliver findings

Every finding lands on the entity’s timeline; the agent’s Deliver findings options also send it where people and systems already look. Each is a toggled row on the agent’s form:

  • Slack channel: the workspace bot posts the full finding to a channel picked from the bot’s own membership list (connect the bot under Settings). The same bot serves trigger subscriptions, where deliveries are also retried and recorded in the delivery ledger.
  • Write-back webhook: every finding is POSTed as JSON to your own automation, with an optional bearer token sent as an Authorization header. The body carries the finding and its run metadata, never a key or token:
{ "event": "finding", "agent": "incident-first-look", "trigger": "incident", "key": "api-server", "finding": "…the incident note…", "run_id": "run_9f2c81d4a6b3", "dispatch_id": "c0f35f8210…", "model": "claude-sonnet-4-6", "rounds": 2, "tool_calls": 3, "started_at": "2026-08-14T12:01:03+00:00", "finished_at": "2026-08-14T12:01:35+00:00", "duration_s": 32.6, "prompt_hash": "1c9f2d" }

Transient failures are retried; a delivery failing never loses the finding, which is already stored. Delivering a finding is not acting: the boundary stands.

  • Slack incoming webhook: the older per-agent webhook URL still works but is neither retried nor logged, and is used only when no channel is set; prefer the channel.

Write-back webhook events

The webhook receives one of two events. A finding is the body above. A skipped event tells the receiver that a run a trigger dispatched was refused before it started, so one that files findings by the firing, as Rius does, does not wait for a finding that never comes:

{ "event": "skipped", "reason": "in_flight", "message": "a run of this agent for the same key is already in flight", "agent": "incident-first-look", "trigger": "incident", "key": "api-server", "labels": {}, "run_id": null, "dispatch_id": "c0f35f8210…", "in_flight_run_id": "run_9f2c81d4a6b3" }

reason is one of:

reasonThe run was refused because
daily_capthe agent already ran its daily cap of runs in 24 hours
budget_exhaustedthe agent used up its budget_usd
in_flighta run of the agent for the same key is already going; in_flight_run_id names it

message carries the text the run records, and key and labels name the firing the way a finding would. A rerun, a bootstrap run or a hand-off sends no skipped event.

Last updated on