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. Embedded pages receive the same saved read timestamp, so reopening a dashboard does not make a previously read digest look new again. Digests are current projections, and nothing times them out. A fresh projection from the same source and workstream may lower its severity when new evidence supports that change. If the projection’s title, narrative, or structured content changes, it becomes unread again; an unchanged confirmation preserves your read state. A digest you dismissed reopens only when its substantive content changes. A digest leaves the feed when a newer one from the same source replaces it (a monitor’s next run, a workstream’s next projection), when the system that filed it reports the condition gone, or when you dismiss it. State notices, such as an automation paused for dormancy, stay until the condition they describe ends; they are never replaced by another digest and do not reopen just because their wording changes. The API may also exposelast_confirmed_at,
the latest producer confirmation time; older items can omit it.
Managed lookup notices include a lookup_resolution payload with the exact
dataset reference, lookup/action name, job id, unresolved count, and sanitized
outcome summaries (outcome_id, optional lead_ref, completion, answer, and
observed_at). They never include contacts, raw evidence, or provider payloads.
Attention items created by an agent default to its thread’s single workstream,
or to the workstream that owns its reconciliation job. An explicit workstream
slug overrides that default. Standalone monitors remain unlinked. A newly filed,
refreshed or reopened workstream digest replaces its older open digests, keeping
the current projection in your feed. Concurrent updates are serialized, and the
new projection and retirement commit together. This preserves choices, unresolved incidents,
other workstreams’ updates and human dismissals.
Open an item’s full report for its formatted findings, evidence links and tables.
In the feed, Details expands the full report text. Digest context is labeled
with what the work is doing, why, what happens next, and what would change its mind;
unfamiliar evidence fields remain available in the report.
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, 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 can ask for a decision, ask you to do something, or report a problem, and every item says which. A decision carries Erdo’s proposed answer and may include a safe default. The workstream keeps doing what it still can while it waits; you can accept the proposal or give a different answer. Nothing in the feed closes on a timer: an item waits until you handle it or until the check that raised it finds the problem gone. A finding Erdo cannot act on itself — a disapproved business logo that needs a replacement, an ad account that needs reconnecting, a credit balance that needs topping up — has no answer to approve, but it is not a report either: it is something to do, and it is filed under Work with the other items that need you. Its text says what to do; it has no deadline of its own and stays open until the next check finds the problem gone, and you can mark it handled or dismiss it meanwhile. Only a finding filed as a status update while something is still pending (a review Google has not finished, say) is a report with nothing to do. The one deadline that exists is a real one. Where a decision carries a safe default that applies the proposal, letting the deadline pass applies it and the work continues, so a stalled decision never silently halts a workstream; the item says “Answer by” and what happens then. Where the change is one Erdo will not make without a person — the stricter setting on your autonomy dial — there is nothing to apply, so there is no deadline: the proposal stays in front of you until you answer it or the condition clears. Until October 2026 such items closed themselves after a day, unanswered and usually unread; they no longer do.Monitor findings close themselves when the problem goes away
A scheduled monitor re-checks every escalation it filed each time it runs. If the problem is still there, the monitor refreshes the same item with current figures, so you still see one item. If the problem has gone, the monitor closes the item and adds a Cleared line saying what it found. If a run simply does not find the problem again, the item closes once that run finishes, with a line naming the monitor. A closed finding comes straight back if a later run finds the problem again. Automatic recovery does not change items you have answered or dismissed. A new detection can bring an update back. Questions a workstream is waiting on stay open until you answer them or their deadline passes. A finding the monitor closed shows the status Cleared, never Dismissed: nobody dismissed it, and anything it proposed was neither carried out nor refused. If it cleared before you had read it, it stays listed under Reports as unread, with the monitor’s Cleared line, until you mark it read, so a problem that came and went overnight is still something you hear about. The CLI lists these witherdo attention list --status cleared; --status dismissed lists only what a person
closed.
Fresh evidence can also lower a monitor finding’s urgency. Only the monitor that
owns the finding can make that change, and it must provide a new evidence report.
A workstream monitor keeps the finding linked to its workstream while updating
its urgency; human questions and held actions keep their decision protections.
A failed read keeps the condition unknown; it does not establish recovery.
For advertising delivery checks, delayed metrics and empty reporting rows do not
prove that a campaign stopped. Google Ads checks allow for reporting delay and
describe unexplained gaps as needs verification. A confirmed blocking status
or ad disapproval can still raise an urgent finding immediately. An empty metrics
table alone does not mean your connection needs re-authorisation.
Routine checks of delivery, pacing or an eligibility reason appear as the next
check in the finding, without an approval button. Concrete proposals to repair
disapproved ads or replace an incorrect destination still ask for authorization.
Judge re-screens — something changed under live work
When a judge 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. The same item covers the mirror case: the standard held still and the page moved. A page built or rewritten outside a build — through the API, the CLI, an automation, or a rollback to an earlier version — never passes through the review a build runs on itself, so Erdo reviews it afterwards and files a re-screen item naming what the lenses found. Reviews are not cheap, so they are reserved for a page’s first content and for rewrites that replace the bulk of it; smaller edits are reviewed when the agent making them asks. See when the lenses read a page. Advisory lenses that never gate a build — fair-housing language above all — file the same way as a compliance review item when they surface candidate language on such a page: a quote, the lens that flagged it, and a proposed inclusive rewrite, marked for a person to judge rather than a machine to fix. See the judges page for what those lenses do and do not decide. Nothing is changed automatically in either case — the page keeps serving exactly what it served before, because a judge’s verdict is not a mandate to rewrite someone’s live page. The item proposes the response instead: for a live experiment, an iterate bet on it, so any fix goes through the same build-and-screen path as every other change; for a page written outside a build, ask the agent to fix it or edit it yourself. A finding closes on its own once a later review of the same page comes back clean. Judges still earning their calibration don’t raise these items at all; their verdicts land quietly in the calibration ledger.Runtime repairs that need a person
A page can keep reporting the same browser runtime failure after automatic code repair has spent its lifetime attempt budget. Erdo then stops scheduling daily retries and raises one Needs attention escalation for that page and failure signature. Repeated visitor reports refresh that same living item instead of creating duplicates. When the page is a variant in a workstream-bound experiment, the item is filed under that workstream so its reconciliation loop and its people see the same condition. Failed fetches and missing resources are recorded and shown to the technical judge, but they do not automatically enter code repair: a missing image, revoked data URL, or third-party outage is often a data/resource problem, and rewriting otherwise-correct page code is not a safe default.Pipelines that Erdo repairs first
An event pipeline is what receives a form submission, a webhook or a tracking event and records it. When a pipeline starts refusing everything it receives because of its own setup, Erdo sends a repair agent before anyone has to act. Setup problems include a pipeline left switched off while its sender still sends, and a sender and pipeline that no longer agree on how submissions are checked. Others are a dataset it writes to that is gone, or rules or a transform that reject what the sender sends. Erdo acts only when the failure is clear. It needs the pipeline’s last three submissions to have failed the same way, so one bad request among good ones never counts. For a lead form on a live page, the nightly test lead is enough on its own. The agent acts for the person who created the pipeline and uses the same tools and approval steps they would. It never switches a pipeline off and never deletes data, and Erdo switches back on any working pipeline the agent turned off. For a lead form, Erdo then submits another test lead to check the fix. Other pipelines, and any fix that cannot be checked straight away, are judged by the pipeline’s next real submission. If the agent needs an approval for its fix, nothing changes until the approval is given, and the feed gets one item for that pipeline saying an approval is waiting. When the repair did not fix a pipeline, that item gives the agent’s explanation of what it found and what a person needs to do. The Lead capture is failing on live pages item also says under each form what the repair did. Erdo tries a given problem on a pipeline at most three times, a week apart, and then leaves it to you. Failures inside Erdo itself are not sent to the repair agent. Erdo’s engineers fix those.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.
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 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.Open an item in full — the report
Every item’s title is a link. Clicking it opens that item’s report: one page showing the data the work read, the reasoning it drew from that data, and what it proposes. It is there so you can check whether Erdo looked at the right things before you answer. The report reads in a fixed order, and it leaves out any section it has nothing to say about:
An escalation that carries a real action links to the decision it became, and that decision’s own
report carries the other half of the story — see Decisions. If the decision belongs to a
project you do not have access to, the page tells you a decision exists and stops there, so you know
there is something to ask a colleague about.
Reports are shareable by URL. A link can also name an organization — add
?org=<organization-slug>
and Erdo switches to that organization before opening the item, which is how someone running several
organizations from a manager account sends a colleague straight to one
customer’s item. If you cannot enter the organization named, the page says so and stays where you
are.
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 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 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.What an item is about
Every attention item names what it concerns, as a list of subjects. A subject is{kind, id, label}: the kind comes from a small vocabulary, the id is the subject’s canonical identifier,
and the label is the human name as it read when the item was raised.
This is what makes the feed joinable to the rest of your account. An escalation about a campaign
whose conversion rate has fallen carries that campaign’s id in a field, so a dashboard listing your
campaigns can show, per campaign, how many things Erdo is currently proposing about it and link
straight to them. The title is written for a person to read; the subjects are what everything else
matches on.
Filter on subjects with
subject_kind and subject_id. subject_kind alone returns every item
about any subject of that kind; both together return the items about exactly that one. An item may
name up to twenty subjects, and an item about nothing identifiable — a budget question, a narrative
digest — names none.
Reading another organization’s feed
If your organization manages other organizations, you can read a client’s feed from your own workspace by naming it:organization_slug on the REST and MCP reads, --org on the
CLI. The rule is the same one manager access follows everywhere — you may read an organization you
belong to, or one that an organization you administer actively manages, one hop. Anything else comes
back as not found, so an organization you cannot reach does not reveal that it exists. Omit it and
you read your own organization, which is what every in-app read does.
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, your answer is recorded as a comparison attributed tohuman:<you> — the option you chose beats the ones you didn’t, and those comparisons
score the cheaper judges against you. Acknowledge marks an item read without deciding
it, and dismiss clears it from the feed.
Answering and dismissing both stop at a deadline. Once an escalation’s deadline has passed its safe
default is the answer of record — Erdo has already acted on it — so a late answer or dismissal is
refused rather than quietly overriding what happened, and the item shows which way it went. Only an
item whose safe default applies the proposal has a deadline at all. A feed or
report left open on screen does not notice the countdown reaching zero, so this is the case where the
button is still there and the answer is no; re-read the item to see where it stands. Acknowledging
still works at any time, because it decides nothing.
MCP tools
REST
Base URLhttps://api.erdo.ai. Authorization: Bearer <token> + X-Organization-ID.
GET /v1/attention takes optional statuses, engine_actions_only, item_id,
organization_slug, subject_kind, subject_id, limit, and offset query parameters. Each item
comes back with its subjects array and its workstream_slug. POST /v1/attention/:id/respond
takes action (answer, acknowledge, or dismiss) and, for answer, the answer body.
subject_id needs a subject_kind — an id with no kind names nothing, so it is rejected rather than
quietly ignored.
item_id is how you read one item: pass its slug or its id and the list comes back narrowed to
that single row. It is a filter rather than a separate by-id endpoint deliberately — one place
decides which items you may see, so an item that belongs to another organization is simply not in
the answer, exactly as it isn’t in the unfiltered list. Omit it and nothing is narrowed.
When item_id narrows the answer to one item, the response also carries a report — the same
content the item’s page shows: proposed_answer and safe_default (what happens if nobody
answers), workstream_slug, the decision_slug the escalation became with that decision’s
alternatives_considered and its declared effects beside whatever has settled against them, the
approval card somebody was asked to answer, and related_items. An unfiltered list omits the
report, so a page of fifty items stays one read. decision_slug can appear with no decision
beside it, which means the decision exists in a project you cannot view.
workstream_slug and workstream_title follow the same rule and are simply absent when you
hold no view grant on that workstream’s project. The item itself still reads — any member of
the organization can open it, which is what makes a report link worth sending — but the name
of the work behind it belongs to the project, not to the organization.
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, 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, Scheduled automations, or Monitoring automations 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.
Attention and workstream sources are available to every organization; the feed remains
organization-scoped and each linked resource keeps its own access controls.
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, 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 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.
GET /v1/activity/feed takes optional limit (default 20, max 100), offset, categories,
scope, and exact workstream_slug query parameters. offset plus limit may not exceed 5,000;
a larger window is refused with an invalid-argument error. Its MCP mirror is
erdo_list_activity_feed.