Decisions in one place: the Console and the Work board
Agents raise questions, CI fails at night, and results pile up for review. The Console asks each decision as a choice, and the Work board turns a drag into the action it means.
A pipeline on your default branch fails at 17:42. The owner hears about it from a GitHub email an hour later. Meanwhile three agents finished their runs and left questions, triage parked forty new work items, and twelve pull requests wait for someone to accept them. Each of those lives in a different tab. Answering them means opening every one, reading it again, and pressing the same button many times.
That is what running more than one agent looks like on an ordinary day. The agents do not get stuck on hard problems. They get stuck waiting on a person who has the context but not the time to find each question. Oxagen 5.5 puts those decisions in two places: the Console for what waits on you, and the Work board for moving many items at once.
#Why scattered decisions slow teams down
Every tab you open to answer one question costs more than the click. Mark, Gudith, and Klocke studied interrupted office work. People made up the lost time by working faster, and paid for it with more stress, frustration, and effort.1 Leroy found a second cost. After a switch, part of a person's attention stays on the task they left, and they do worse on the next one.2 A reviewer who jumps from a failed CI run to a triage question to a pull request pays that cost three times.
So the Console holds every decision for one workspace in one stack of cards, one card at a time. The sidebar shows one count of what waits on you. No other page adds a second counter.3
#Work that needs you
A Needs you card is an item that waits on you: an approval a tool call parked, a question an agent asked, the work a run left undone, a result to review, or a work item ready to send. The items that block the most agents come first.
When a run ends with work it could not finish, the Console asks each open point as a question with choices. Choice A is the answer stella recommends, and it carries a Recommended label. On a run's card, no choice starts picked. You press an answer before a question has one, and a question you skip stays on the card.
We made that change on purpose. A preselected answer tends to become the answer. Johnson and Goldstein showed how strongly a default steers a choice, even for organ donation, where people care a great deal.4 Parasuraman and Manzey describe the same pull with automated advice: people lean on a system's suggestion and check less.5 A recommendation saves you the work of drafting choices. Making you press it keeps the decision yours, and the record shows a person chose.
Triage questions use the same card. When triage cannot start a work item, it asks what it needs as multiple choice, and one Send records every answer for the agent's next start. Those cards still start with the recommended answer picked.
#Work done while you were out
Some work stella does alone, under a rule or a switch you turned on. Each of those actions becomes a While you were out card. The card says what stella did and carries a button that reverses it. Keep hides the card. Reversing an action is one press, so letting stella act alone costs you little when it is wrong. Nielsen lists this as a basic rule of usable systems: people need a clear way out of a state they did not want.6
These cards ask nothing, so they add nothing to your count. Items that block an agent stay at the top. Everything else mixes in, newest first.
#Notices you read once
Some news needs your eyes and nothing else. A CI/CD run that ended on a tracked repository's default branch, a pull request merged into it, a run that ended without a clean finish, or a model account the provider refused each arrive as a card. A failed CI card names the repository, the branch, the commit, the job that failed first, and the forge's own error text. If a later run of the same workflow and branch passes while the card is still unread, the card turns from red to green in place.
Each notice reads once. Moving past it in any way marks it read, and it stays read on every device. A Run failed card goes to the person who started the run and to the workspace's Admins. A refused model account waits on the person who owns it, or on the Owners and Admins for a workspace account. The CI, merge, and Run failed notices send no email or Slack message, so the Console does not add to the pile in your inbox.
#How the Work board shows work by state
The Work page now has a board layout, with work items in columns by state. A card on a board invites you to drag it, and a drag usually means something: send this, stop that, take it back. On a careless board the drag just changes a label and nobody does the work.
On the Work board, a drop opens the action the move means. The card moves only after the write lands and the page reads again.
| Drag from | Drop on | Action it opens |
|---|---|---|
| New | Done | Close |
| Pending review | Ready | Approve the Done Checklist |
| Pending review | Done | Close |
| Ready | Sent | Send to an agent |
| Ready | Done | Close |
| Sent | Ready | Withdraw the send |
| In progress | Ready | Stop the run |
| Pending acceptance | Ready or Sent | Return with a reason |
| Done | New | Reopen |
A column with no row in that table takes no drop. A result waiting for acceptance never drops on Done, because finishing it is an acceptance a person makes on the item's page. The server checks each move again with the same rule the item page uses, and your roles decide which actions the board offers you.7
#How to review work in bulk
Work also reviews in bulk. Tick the items in Pending review and approve their Done Checklists in one press, or run triage on all of them again. Tick results in Pending acceptance and accept up to 100 at once. Each acceptance still names the exact commit you read. If a new commit lands on one pull request, that one is refused and the rest go through. Any item the server refuses stays ticked and appears under the table with its reason.
#How agents update work in bulk
Agents and scripts get the same lists. Through MCP and the API, four capabilities take up to 100 items per call: add_work_items, update_work_items, delete_work_items, and retry_work_triage.8 The oxagen CLI reaches them through oxagen mcp call. Each call answers every item in order. One item that cannot be saved comes back with its reason while the rest are saved. Before this, a script that triaged forty items made forty calls.
In the app, stella can make the same list edits. You confirm the whole list once, on one card, and stella acts as you, with your rights and nothing more. A deleted item keeps its row and its history, and no later action can reach it.
#What this release does not cover
- An enrolled machine writes without a card. On a machine you enrolled, a connected agent can create, edit, delete, and re-triage work items as you, with no approval card. It can do no more than your role allows, and the server checks that role on every call.
- Decisions stay with a person. Closing, sending, accepting, returning, and approving are not on that list. A key without delegated authority is refused for each of them, so an agent cannot decide its own work.
- The board approves only saved checklists. It does not approve triage's draft checklist. You read and edit that draft on the item's page first.
- Keep is local. Keep hides a card in one browser for two days. Read-once notices are marked read for good, on every device.
- GitLab is partial. An item from GitLab gets no answer scoped to its repository.
- Coverage follows the routing. The Console and the board cover actions routed through Oxagen. An agent's work outside Oxagen does not reach the stack.
The release post for Oxagen 5.5.0 lists the other changes in this version.
#References
-
Mark, G., Gudith, D., & Klocke, U. (2008). The Cost of Interrupted Work: More Speed and Stress. CHI 2008. https://ics.uci.edu/~gmark/chi08-mark.pdf ↩
-
Leroy, S. (2009). Why is it so hard to do my work? The challenge of attention residue when switching between work tasks. Organizational Behavior and Human Decision Processes. https://doi.org/10.1016/j.obhdp.2009.04.002 ↩
-
Oxagen (2026). The Stella page. Oxagen documentation. https://docs.oxagen.sh/docs/stella-page ↩
-
Johnson, E. J., & Goldstein, D. (2003). Do Defaults Save Lives? Science. https://www.dangoldstein.com/papers/DefaultsScience.pdf ↩
-
Parasuraman, R., & Manzey, D. H. (2010). Complacency and Bias in Human Use of Automation: An Attentional Integration. Human Factors. https://doi.org/10.14279/depositonce-8052 ↩
-
Nielsen, J. (1994). 10 Usability Heuristics for User Interface Design. Nielsen Norman Group. https://www.nngroup.com/articles/ten-usability-heuristics/ ↩
-
Oxagen (2026). Work. Oxagen documentation. https://docs.oxagen.sh/docs/work ↩
-
Oxagen (2026). MCP tools. Oxagen documentation. https://docs.oxagen.sh/docs/mcp/tools ↩

