> ## Documentation Index > Fetch the complete documentation index at: https://docs.erdo.ai/llms.txt > Use this file to discover all available pages before exploring further. # Your attention feed > One feed carries everything that wants your attention — narrative digests, quick judgment calls, blocked-decision escalations, and judge re-screens — plus a way to steer work mid-run. # Your attention feed As Erdo runs more work on your behalf — building pages, running experiments, watching your data — the question stops being "what are the agents doing?" and becomes "what actually needs me?". Nine times out of ten the answer is nothing, and the interface's job is to make that legible without you reading a log. So everything that wants your attention queues into **one** place — the **Activity** feed — rather than reaching you from several directions at once. There is no separate approvals inbox here, no decisions panel there, no "pick A or B" somewhere else: one stream, ranked by how much a decision hangs on it, with a single budget on how often it is allowed to interrupt. Items come in three shapes, because they do three genuinely different jobs. ## Digests — the narrative channel A **digest** is editorial and asks nothing of you. "Built ten landing pages across five personas; two look unusually strong; nothing needs you." It exists so you can get an innate feel for whether the work is healthy — the daily-standup read, not an event log — and it projects rather than merely reports: what the work is doing, why, and what it will do next. Digests are marked read as soon as they've been on screen, so the feed reflects what you've actually seen. ## Choices — buying your judgment A **choice** is Erdo asking for your *judgment*, not your permission. Where a human comparison is worth more than a machine's — early rounds, new territory, taste-heavy calls — the feed asks for it in the cheapest possible form: pick your top five of these ten, A-or-B five times, rank these three ideas. You answer in seconds by tapping options. Two things make a choice more than a convenient survey. First, every answer is recorded as a labelled comparison — you are the most expensive and most trusted judge Erdo has, so your verdict both steers the live decision *and* scores the cheaper automatic judges against it, sharpening them over time. When a choice is tied to a running [experiment](/experiments), picking an option marks that option's variant as beating the ones you didn't pick, and those comparisons flow into the experiment's calibration record. Second, choices are rationed by the same interrupt budget as everything else, so Erdo has to spend its questions where your judgment actually moves the outcome — it can't nag. ## Seeing the work, not a description of it A choice between landing pages is only as good as what you can see when you decide, so the feed carries the work itself rather than a summary of it. When a choice's options map to pages Erdo has built, each option renders as a **live preview** — the real page running its real code, motion and interactivity included, not a stale screenshot — laid out side by side as a comparison grid on desktop and a swipeable carousel on your phone. You pick by looking, and tapping a preview opens the full page in a new tab. Because the preview is the actual page, comparing rendered work also produces sharper labels for the automatic judges than comparing descriptions ever could. The previews reference the same pages that Erdo publishes and experiments with — the feed adds no new way to run code and no new place for it to reach. A page shown here is rendered exactly as it is, without the traffic-splitting that a live visitor would see, so the card always shows the specific variant you're weighing. For a candidate that isn't a published page yet, Erdo can attach a small self-contained snippet, rendered in the same locked-down sandbox everything else on Erdo runs in. Previews load only as they scroll into view, so a long feed of live pages stays light. Digests can carry evidence the same way: when a number tells the story — leads by variant this week, cost per booked meeting — the digest attaches a **chart or table** drawn with the same components you see elsewhere in Erdo, rather than spelling the figures out in prose. It's shown only when seeing the shape changes what you'd conclude, so the narrative channel stays a narrative and doesn't turn into a dashboard. ## Escalations — a blocked question, already half-answered An **escalation** is a question the work is blocked on — but never a bare question. It arrives with Erdo's **proposed answer**, a **safe default**, and an **expiry**. The workstream keeps doing what it still can while it waits; you either accept the proposal in one click or give a different answer. And if you don't respond by the expiry, the safe default is applied automatically and the work continues — a stalled decision never silently halts a workstream. This is guidance, not a hand-off: Erdo has done the thinking and needs only your confirmation or correction. ## Judge re-screens — a standard moved under live work When a [judge](/judges) is updated — its rubric edited, or the shared principles it reviews against revised — every *future* page automatically gets built to the new standard. But pages already serving live traffic in a running experiment were screened under the old one, and a **judge re-screen** item is how the gap surfaces: Erdo re-runs the changed judge over the live variants, and if a judge with a trusted track record now finds blocking issues, one item per affected experiment appears in the feed naming the variants and the top findings. Nothing is changed automatically — the variants keep serving, because a moving standard is not a mandate to churn live pages. The item proposes the response instead: an iterate bet on that experiment, so any fix goes through the same build-and-screen path as every other change. Judges still earning their calibration don't raise these items at all; their re-screen verdicts land quietly in the calibration ledger. ## Severity and the interrupt budget Every item carries a severity, and severity governs one thing: whether it may interrupt you. * **FYI** and **Needs attention** wait quietly in the feed until you look. * **Urgent** is the only level allowed to break through — and the number of open urgent items is capped per organization. When the budget is full, a new urgent item is automatically downgraded to *Needs attention* rather than piling onto an alarm you're already ignoring. The cap is deliberate. Interfaces that run one person over many processes — flight decks, control rooms, on-call rotations — all converge on the same rule: an alert that fires too often stops being an alert. Capping urgency on the feed as a whole keeps the loudest channel meaningful. ## Held items — deferral you can see Severity does more than decide whether something interrupts you; it decides *when* it reaches the top of the feed. Only **urgent** items land in **Needs you** the moment they're raised. A **Needs attention** or **FYI** choice or escalation is still something you can act on, but it isn't worth breaking your attention for right now — so instead of surfacing immediately it is **held**, and the feed shows a single collapsed row beneath the urgent band: *"3 items waiting."* The same control-room lineage that caps urgency is behind this — a mistimed non-critical alert costs more in lost focus than the delay costs in latency, so the disciplined move is to queue it to a natural breakpoint and let you choose when to look. The count is the point. Deferral must never read as silence, so the number of waiting items is always visible even while their detail is folded away. Two things surface a held item in full: you **expand the row** whenever you want to act, or a **digest arrives for its workstream** — held items ride along with the next narrative update for the work they belong to, so they reach you at the moment you're already reading about that workstream rather than as a standalone interruption. Approvals are never held: an approval is a block you deliberately put yourself in front of, so it always surfaces at once. ## When one failure floods the feed A single root cause can trip many workstreams at once — one broken integration, one bad deploy, one upstream outage — and naively the feed would light up with a dozen urgent items that are really one problem wearing many hats. Control-room history has a name for this failure: the alarm avalanche, where a hundred annunciators fire in seconds and the one fault behind them becomes *harder* to see, not easier. So when the number of open urgent items in a short window crosses a threshold, the feed switches to **overview-first**. The individual alarms collapse behind **clusters** — one row per workstream and kind, *"5 escalations · Lead engine"* — under a synthesized headline that names the shape of the storm: *"12 urgent items across 4 workstreams — likely common cause."* You see the pattern before any single item, expand a cluster only when you want the detail, and the quiet board above the feed is already showing you which workstreams are involved. The clustering is plain grouping, computed the same way every time — there is no guesswork on the read path, so the same storm always renders the same way. ## What surfaces first — ranked by decision, not by clock A feed sorted newest-first buries the one escalation that needs an answer under a wall of completed runs, so the Activity feed is ordered by **decision-value** instead. Anything you can act on right now — an open choice, an escalation waiting on you, a pending approval — rises to the top under a **Needs you** heading, ahead of everything that is merely news. Within that band the order follows urgency: a higher-severity item outranks a lower one, and among items of equal severity the one whose safe default fires soonest comes first — an escalation auto-resolving in two hours sits above one that has until tomorrow, because the sooner it resolves itself the sooner the choice leaves your hands. Below **Needs you** come the digests you haven't read yet, and below those the rest of the timeline in the usual reverse-chronological order. Nothing is hidden; the ranking only decides what you see first. (The interrupt budget already caps how much can pile up, so ordering never has to compensate for volume.) ## The quiet board — state at a glance The feed reports *change*; a small always-on **board** above it reports *state*. It carries one cell per active workstream, and it follows the control-room principle that darkness means normal: when every workstream is healthy and inside its budget, the board collapses to a single muted "all quiet" line with nothing to read, so "is everything OK?" is answerable at a glance without parsing anything. Only the exceptions light up — a workstream that is over its spend envelope, or one carrying an open urgent item — and only those show detail. Each cell links straight to its workstream, so going from "something needs me" to the place you can act on it is one click. ## Following — scoping the feed to what you own The feed works because every item is about *your* money, *your* leads, *your* workstreams — ownership already did the filtering that engagement-ranking never solved for social media. **Following** narrows that one more turn: when you follow a workstream, its digests, choices, and narrative events populate your feed's default view, and the workstreams you don't follow fade into the background. You follow a workstream from its detail page or from its cell on the quiet board, and Erdo follows for you the ones you clearly care about — the workstream you just created, and any you drop a steering note into. An **All** toggle switches back to the whole organization whenever you want the wider view; if you follow nothing, you see everything, so the scoping only ever narrows a feed you'd otherwise have to narrow by hand. One channel is never scoped away: **urgent** items always break through, whether or not you follow the workstream that raised them, and org-level alerts that belong to no single workstream always show. Following quiets the ambient, narrative surface — never the alarm. A crisis on a workstream you weren't watching still reaches you. ## Steering notes — reaching in mid-run The feed is mostly Erdo talking to you; **steering notes** are you talking back without stopping anything. On a [Workstream's](/workstreams) page you can drop a note the moment an idea occurs — a hunch, a constraint, a correction ("the client hates countdown timers"). The note lands in the workstream's event log, and the agents pick it up on their next pass and treat it as new evidence: updating what they're building, dropping ideas the note rules out, spawning ones it suggests. Because Erdo's loops always reconcile against a consistent, written state rather than firing one-shot event chains, steering needs no special ceremony — a note from you is just evidence that happened to arrive from a human instead of from the data. Steering costs you seconds; carrying it out costs you nothing. ## Ask about any item — introspection in one click Every item in the feed carries an **Ask** button. Press it and Erdo opens the owning [Workstream's](/workstreams) thread — where that workstream's full context is already loaded — with a reference to the item pre-filled in the message box ("About attention item …"). You finish the sentence and send. Nothing is sent on your behalf; the prefill is a starting point, not an action. This is deliberate: the deep-explainability layer is chat, which you already have, so "why did the critic block this?" or "what would change your mind about page B?" is one click away rather than a database query. An item with no workstream opens a fresh thread instead. Feed items also carry **actor chips** — the workstream that produced the item, and, where a choice is tied to one, the [experiment](/experiments) it scores — so you can click straight through to the thing itself. The surface stays simple no matter how involved the engine underneath gets; easy introspection is what keeps that simplicity honest rather than opaque. ## Programmatic access The feed is also readable and answerable over **MCP**, the **REST API**, and the **CLI** — the same items you see in **Activity**, org-scoped and RBAC'd. This is how a headless caller reviews what needs a human and responds without opening the app. Responding takes one of three actions. **Answer** a choice or escalation with your pick; when the choice is tied to a running [experiment](/experiments), your answer is recorded as a comparison attributed to `human:` — the option you chose beats the ones you didn't, and those comparisons score the cheaper [judges](/judges) against you. **Acknowledge** marks an item read without deciding it, and **dismiss** clears it from the feed. ```bash theme={null} # read the feed erdo attention list --open # only items still needing you erdo attention list --status urgent needs_attention erdo attention list --engine-actions # only the engine's own autonomous actions # respond erdo attention respond --answer '{"choice":"b"}' erdo attention respond --ack erdo attention respond --dismiss ``` ### MCP tools | Tool | What it does | | ----------------------------- | --------------------------------------------------------------------------------------------------------- | | `erdo_list_attention_items` | List feed items (filter by status, or engine-actions only). | | `erdo_respond_attention_item` | Answer a choice/escalation, acknowledge, or dismiss an item. | | `erdo_list_activity_feed` | Read the ranked attention feed, with optional catalog and automation history, plus urgent cause-clusters. | ### REST Base URL `https://api.erdo.ai`. `Authorization: Bearer ` + `X-Organization-ID`. | Method | Path | | ------ | --------------------------- | | `GET` | `/v1/attention` | | `POST` | `/v1/attention/:id/respond` | `GET /v1/attention` takes optional `statuses`, `engine_actions_only`, `limit`, and `offset` query parameters. `POST /v1/attention/:id/respond` takes `action` (`answer`, `acknowledge`, or `dismiss`) and, for `answer`, the `answer` body. ## The whole feed over the API `GET /v1/attention` returns attention items alone. But **Activity** is more than attention items — it can merge attention items, [approvals](/approvals), workstream narrative events, catalog updates, and automation history into one ranked stream. The default is deliberately narrower: the things a person may need to understand or decide, not a log of every successful background operation. `GET /v1/activity/feed` exposes it, so a headless caller reads the same feed a person sees in the app — already ranked, already clustered — instead of fetching each source separately and rebuilding the ordering itself. The default view matches the app's: **attention items, approvals, and workstream events**. Individual job executions, heartbeat executions, and catalog batches are operational history, so they do not crowd the attention feed unless you ask for them. Repeated automation failures still surface as one deduplicated escalation after Erdo's repair attempts; hiding raw executions does not hide sustained breakage. In the app, shared threads, upcoming schedules, and automation suggestions are also hidden by default; select **Shared threads**, **Jobs**, or **Heartbeats** in the type filter to see them. Pass `categories` — a comma-separated subset of `attention`, `approval`, `workstream`, `catalog`, `job`, `heartbeat` — to change the mix; naming `catalog`, `job`, or `heartbeat` opts that history back in. The attention and workstream sources appear only when the engine is enabled for your organization. The response carries the same ordering described above under **What surfaces first**: items you can act on right now lead, sorted by severity and then by which safe default fires soonest, followed by the digests you haven't read, then the rest of the timeline newest-first. Each item carries `needs_action` so you can render a "Needs you" band without re-deriving it, and its `severity`, and — for attention items — a `slug` you respond to. When a storm trips [overview-first mode](#when-one-failure-floods-the-feed), the individual urgent items are marked `clustered` and the response's `urgent_clusters` carry the grouped rows — one root cause behind N alarms — each with a `summary`, a `count`, and the member `item_ids`, alongside a one-line `flood_summary`. The feed endpoint is **read-only**. To act on an item you respond exactly as you would to an attention item or an approval on its own: `POST /v1/attention/:id/respond` to answer, acknowledge, or dismiss a choice or escalation, and `POST /v1/approvals/:id/decide` to approve or reject an approval. `scope` accepts `following` or `all` (default `all`); because an API token is org-scoped and carries no per-user follow set, `following` behaves as `all` for a token and is meaningful only for a user-scoped credential. For one [Strategy](/strategies) or workstream, pass `workstream_slug`. This is an exact operating view: it includes only that workstream's attention, approvals, and narrative events. Urgent and standalone items from elsewhere do not break through, and unscopable catalog/job history is omitted. ```bash theme={null} erdo activity # the ranked feed: needs-you first, then clusters, then recent erdo activity --categories attention,approval,workstream,catalog,job,heartbeat # include all operational history erdo activity --limit 50 --json # raw response for a script erdo activity --workstream brickell-lead-strategy ``` | Method | Path | | ------ | ------------------- | | `GET` | `/v1/activity/feed` | `GET /v1/activity/feed` takes optional `limit` (default 20, max 100), `offset`, `categories`, `scope`, and exact `workstream_slug` query parameters. Its MCP mirror is `erdo_list_activity_feed`.