Working an offered task
What a person sees when a matter reaches them: presence, the six work views, how an offer arrives and what it carries, and what accepting a task does to the screen.
Work reaches a named holder — an AI agent, or a person where policy reserves the decision — by being offered to them individually, with the reason they were chosen. This page is what a person sees when a matter reaches them. This page covers the loop that produces those offers, what an offer carries, and what happens when one is accepted, declined or left to lapse.
The home screen
Start Here greets the person by name and shows a single focus task, what else is with them, and — collapsed, because it needs nothing — the work that is parked waiting on somebody else, each item naming what it waits for.
Pulling the next task is a single action, bound to the n key. When it is unavailable, the interface names which of five conditions applies rather than disabling the control silently:
The button explains itself rather than greying out
- 1"You don’t have an assigned queue yet"a setup problem for a supervisor, not a capacity problem
- 2"Set yourself available when you’re ready for new work"their own presence
- 3"Respond to your current offer before taking another task"one decision at a time
- 4"Finish or release a task to free up capacity"
- 5"3 of 5 general task slots in use"the ceiling, and where they are against it
Push delivery
A live server-sent event stream notifies the app that this person’s work has changed. The stream carries no payload — its only message is that something changed, which causes the app to re-read through the ordinary authenticated endpoints. Nothing confidential travels on it, and it is never a second source of truth. While it is connected, background polling relaxes from five seconds to thirty; if it drops, polling resumes at the shorter interval.
Offers
There is no separate offered state: the reservation is the offer. It stands for approximately two minutes, shown as a countdown, and carries four things:
Selection is ordered, not scored: eligibility, then case-owner continuity, then fewest active tasks, then longest since the last offer, then worker id as a tiebreak. Because every step is a checkable fact, the resulting choice can be rendered as a sentence.
Declining requires a reason from a fixed list — busy, not my speciality, stepping away, needs someone else, other. The reasons describe their availability rather than the task, so declining carries no assessment of the work.
Accepting a task
Accepting navigates to the record the work concerns — the case, document or interaction — rather than to a task detail page. The task persists across that navigation as a ribbon carrying its deadline, its summary and its available outcomes, with a banner providing the route back. Task types that are worked entirely within their own panel are registered as such, and accepting one of those does not navigate.
- The offer arrivespushed, with the reason it chose this holderautomatic
- Accept, or decline with a reasona person
- The platform opens the case, not the taskyou land where the evidence isautomatic
- The task rides alongclock and finish line follow you across screensautomatic
- Record the outcome where you did the worka person
Work views and presence
What each view answers
- Ready for me — what can I take right now
- My work — what I have accepted
- Waiting — mine, but parked on somebody else
- Team backlog — what my queues are carrying
- AI work — what the AI workforce is running
- All work — everything I am allowed to see
Why the server derives them
- Membership depends on eligibility, capacity, presence and permissions
- A client-assembled list can contain work the server would refuse to reserve
- The discrepancy would surface at reserve time rather than at render time
Presence has five states — available, busy, wrap-up, away, offline — set by the person across the channels they cover. AI workers appear in the same lists as people, with the same capacity accounting.