# The attention digest: a dashboard your agent actually reads

> get_attention_digest returns the operator's attention queue in five buckets — decisions awaiting, staged sends, untriaged service requests, stale amendment proposals, and recent loud schedule signals — each with an exact count, the newest items, and the named tool that pages or acts on it. Agents are expected to call it around their operations and relay anything outstanding in one or two plain sentences. Relay, don't act: the queues are the operator's decisions.

URL: https://biloh.com.au/docs/reference/attention-digest
Category: Reference | Audience: agent | Updated: 2026-08-19

An operator who runs their business through AI agents has a problem no dashboard solves: the dashboard assumes someone looks at it. `get_attention_digest` is the fix — the operator's outstanding-attention queue as an MCP tool, sized for an agent to check around its work and relay in a sentence.

## What does the response contain?

Five buckets. Each carries an exact `count`, the newest few `items` (capped by `max_items_per_bucket`, 1–20, default 5 — counts stay exact regardless), and a `next_tool` string naming where to page or act:

| Bucket | What it holds | next_tool points at |
|---|---|---|
| `decisions_awaiting` | Decision Queue cards awaiting the operator | `list_comms_work_items` → `decide_comms_work_item` |
| `staged_sends` | Proposed external sends awaiting approval | `list_pending_operations` → `approve_send_operation` |
| `service_requests_untriaged` | Inbound client requests not yet triaged | `list_service_requests(awaiting_triage: true)` → `triage_service_request` |
| `stale_amendment_proposals` | Pending schedule-change proposals older than the staleness window | `list_amendment_proposals(status: 'pending')` → `action_amendment_proposal` |
| `schedule_signals` | Recent loud scheduler events: sold visits needing a decision, period-guard spawn skips | paired Decision Queue cards / audit reads |

Above the buckets: `attention_needed` (boolean), `total_items`, a one-line `headline` ready to relay verbatim, the resolved `thresholds`, and a `relay_instruction` that states the contract — relay the headline alongside your current task's result; do not act on any bucket unbidden.

## What behaviour is expected of an agent?

Call it around operations — after completing the operator's request, at session start, and on "what needs me?". Relay anything outstanding in one or two plain sentences ("Also: 2 visits need a decision and 3 sends await approval"). The connect-time server instructions carry this as a standing rule, and `get_session_context`'s `operational_state` includes a `decisions_awaiting` count so a fresh agent knows attention is waiting before it ever discovers the digest tool.

## What's tunable?

Two per-tenant settings, editable by UI and agent alike: `attention.digest.stale_proposal_days` (how old a pending amendment proposal must be before it counts as stale; default 7) and `attention.digest.signal_window_days` (the lookback for loud schedule signals; default 7). Both ship in every tier — the digest is not a gated luxury.

## Related

- [An orientation payload an agent can read](/docs/engineering-notes/an-orientation-payload-an-agent-can-read)
- [Signed work never disappears](/docs/concepts/signed-work-never-disappears)
- [Tool discoverability for agents](/docs/engineering-notes/tool-discoverability-for-agents)
