An Inbox for What Waits on You

At 14:10 you start a managed run on the Payments API and go back to your own work. At 14:25 the agent stops on a question: should retries also cover 4xx responses from receivers, or only 5xx and timeouts? You're in another tab. As we described when runs got a review loop, a question nobody answers within an hour lets the agent carry on with its own judgment, and a plan nobody reviews within an hour fails the run. At 15:25 the agent decides alone.

Nothing was broken. The run page said Waiting for you the whole time. You weren't on the run page.

Runs are one case of something that has become true across Archyl: things wait on people. An architecture change request sits open until someone with edit access reviews it. A comment on a diagram element gets a reply its author never sees. Until now there were two ways to find out. You went and looked, or you turned on email notifications, which mirror architecture changes across the organization and tell you a great deal that isn't yours to act on.

Archyl now has a third: a bell at the right end of the app header, on every page, with an unread count. Behind it is an inbox that holds only what waits on you or answers something you did.

What the panel looks like

Click the bell and a panel titled Notifications opens. Each notification is one line: a sentence saying who did what, an excerpt, the project name, and how long ago. Here is a plausible afternoon. The sentences are the ones the app shows. The names, projects and excerpts are examples.

Notifications                                        Mark all as read

● An agent is waiting for your answer
  Should retries also cover 4xx responses from receivers, or only
  5xx and timeouts?
  Payments API · 12 min. ago

● Marie Laurent requested changes on #14
  Billing shouldn't call the ledger database directly. Route it
  through the Ledger API container.
  Billing · 2 hr. ago

● Sam Okafor replied in a discussion
  That queue was replaced by the outbox table in March, the
  diagram is behind.
  Checkout · 3 hr. ago

  Your agent run finished
  Document how to set up and run the service locally.
  Billing · yesterday

Clicking a line marks it read and opens the page it is about: the run, the change request, or the discussion. Mark all as read sits in the panel header, and hovering an unread line shows a Mark as read button for the ones you want to clear without opening. When there's nothing, the panel says so: "Nothing is waiting on you".

What sends a notification

Three sources, and the full list is short enough to print.

Managed agent runs notify the person who launched the run.

What happened Sentence Excerpt
The agent asked a question An agent is waiting for your answer The agent's question
The agent proposed a plan and is waiting for approval An agent is waiting for your answer The task you gave it
The run finished Your agent run finished The task
The run failed Your agent run failed The error

A cancelled run sends nothing. Someone chose to stop it, and that someone doesn't need telling.

Architecture change requests notify in two directions. When one is opened, everyone who can edit the project is told, except its author. Reviewing takes edit rights, so those are the people it waits on. From then on, the author hears what happens to it:

What a reviewer did Sentence Excerpt
Approved it {name} approved your change request #14 The request's title
Requested changes {name} requested changes on #14 The review comment
Reviewed it with a comment {name} reviewed your change request #14 The review comment
Merged it {name} merged your change request #14 The request's title
Closed it {name} closed your change request #14 The request's title

Discussions notify on replies. A reply reaches the person who started the discussion and everyone who has already replied in it, with the reply as the excerpt. The link opens the discussion, not the single reply, so you land on the whole thread.

One rule holds across all three: you are never notified of your own actions. Approve your colleague's change request and they hear about it. You don't.

Why it isn't an activity feed

The obvious way to build this is to take the change history Archyl already records and show it under a bell. We didn't, on purpose.

An organization's history is mostly other people's work going fine. Someone renamed a container, someone added a relationship, discovery proposed twelve components and a teammate approved them. All of it is true and almost none of it needs you. Put that under an unread count and the count stops meaning anything. Most of us have a bell like that in some other tool, with a number on it we stopped reading long ago.

So the inbox has a narrow test for what gets in. Either the thing is blocked until you act (an agent's question, a plan, a change request you can review), or it's the answer to something you started (a review on your request, the end of your run, a reply in your discussion). A change that passes neither test doesn't get a line.

The broad view still exists and hasn't changed. Email notifications and the History page remain the place for activity across the organization. The inbox is the other half: the part addressed to you.

A few details

Each organization has its own inbox. If you belong to two, the bell counts and lists the one you're currently in.

Sentences follow your language, excerpts don't. The app ships in nine languages, and the sentence on each line is rendered in the language of your interface. A notification stores what happened, not a finished English string, so a reviewer working in French and an author working in Japanese each read "requested changes" in their own language. The excerpt is someone's words, and stays in the language they wrote it in.

What a notification copies is protected like its source. A line repeats a change request's title or a piece of a comment. Where those are encrypted at rest, which is the case on Archyl Cloud, the copy in the inbox is encrypted the same way.

The count is polled, not pushed. The unread count refreshes every 30 seconds, and again when you come back to the tab. A new notification can therefore take up to half a minute to show on the bell. For "a reviewer wants changes" that's soon enough, and it spares every open tab a long-lived connection. Marking something read updates the count right away in your own browser.

What it doesn't do yet

Change requests opened by an agent through the MCP server don't notify reviewers. A request opened in the app does. One an agent opens through MCP shows up in the project's list, and nobody's bell moves.

No per-type settings. You can't turn one kind of notification off. The list above is what you get.

No @mentions. Naming someone in a comment doesn't notify them. Today only people already in a discussion hear about replies. Mentions are next on the roadmap for the inbox, and we're not putting a date on them.

Where to find it

There's nothing to set up. The bell is at the right end of the header, and it will stay empty until something is addressed to you. The quickest way to see it work: start a managed run on a profile with Review the plan first turned on, switch to another page, and wait for the count.

If you launch runs from chat, this sits alongside the thread updates rather than replacing them. A run started from Slack or Teams still reports back in its thread, and its launcher also gets the line in the inbox.


Related reading: reviewing an agent while it works, for the plans and questions a run waits on, and architecture change requests, for the review workflow these notifications follow.