A task in Taskuary is three records, not one: the durable job, the agent work done on it, and how it is closed out - the reply to whoever asked, and on GitHub the merge or the closed issue. They start and finish independently, and keeping them apart is what stops the word "done" meaning three different things.

A task's two sections#

Every task - general, reply, coding or a plain to-do - is two sections, left to right: Came from and Agent, and its Agent section is one chat. The section the task is up to opens; the other folds to a slim column beside it that still says where it stands. The reply, the post, the emails it owes, the file the agent set up and, on a coding task, how its branch lands all sit in the chat, under that turn's Next steps (A general task is one chat), each with its own Send. Mark done and the task's other moves are one row on the chat's strip.

A plain to-do no agent has touched is Came from alone, with the box at its foot: type there and the agent starts, and its chat opens beside it. A coding agent's live terminal is a Terminal toggle inside its chat, never a column of its own. AI used and, on a coding task, Talk to this agent from… are small buttons in the task's top-right corner.

Mark done always comes first on the task's row of moves, and is never folded away. When a strip runs out of room, the rest of its moves fold into a ▾ at its end. The task's title bar holds only its status, Expand and ×.

Under the task is one small bar, Nav: Back and Next, each greyed where there is nowhere to go. The chat is a separate pill in the corner; type there and a window opens out of it, about the task on the table.

While an agent works, its chat takes the whole width and Came from folds to its spine.

Who is allowed to close it#

There is one close, Mark done. A draft's Send and close is a Send and then that close, in one press. A plain Send, or approving an agent's act, never closes a task by itself (the owner's rule: sending and closing are two steps). Mark done always does the same five things: the task is done, any unsent draft is kept but retired, a live agent is stopped, it leaves your work rail, and the "yours to end" mark comes off.

A task an agent or a merged pull request closed stays on your work rail until you have read it.

The close-out: what finishes it where it lives#

Mail is answered by the reply. A pull request is merged, and an issue closed. Whatever the system, the card has the same three buttons - only the line under them says what they do there. None of them closes the task: Mark done does - except Approve and close, which the card in the task's chat puts first where your reply rides with the close-out: it approves, sends the reply, then closes the task (kept open while an agent works on it). Approve beside it does the same and leaves the task open; when the line is tight it folds into the ▾ beside Approve and close.

If the act is refused, nothing is sent. Merging or closing the pull request on GitHub yourself counts as answering it: the card goes, and the task waits for your Mark done. The buttons are yours, so Agents may push / deploy does not have to be on - that switch is about what an agent may do. A task an agent finished before this existed gets its card on the next sync. A session you started yourself is yours to complete: the agent is told so, and if it says it is finished anyway its sentence is filed on the task and the task stays open until you mark it done.

These never end a task:

Reopening a completed task starts a fresh task lifecycle rather than pretending an old terminal is still alive.

Sending work to an agent#

Choose Send to agent on the Agent section. A coding task opens a terminal on its CLI and model in the repository's checkout; a general task opens a conversation. The session is handed the task summary, the incoming messages, the attachments, any saved result from an earlier run and your optional note — plus a context file under ~/.taskuary/context/ holding the thread, relevant sender and topic history, the learned profile, and reports from related closed tasks.

Mark done is stronger than all of them: it closes the task and ends any live session, because a finished task should not leave an orphan process running.

A general task is one chat#

A general or reply task's Agent section is one regular chat, oldest at the top, the box always at the bottom.

Each turn reads as three short sections:

• What this is about - the ask, in a sentence.
• What I did - the result itself first: the figure, the link, the file. A file it made shows under it and opens in a preview - a workbook as a table, a picture, a PDF - with Download.
• Next steps - the action it set up for one press, or what is left to you: a draft email with its To, Cc, attachments and Send; a LinkedIn, Bluesky or Mastodon post drawn as the post, with its picture and Post to LinkedIn; a step only you can take ("For you to do: ..."); or "Nothing left to do here".

A turn keeps its own draft. When a newer turn comes - a mail that joined the thread, a line you typed - the older turn folds to its "What I did" line and keeps the draft it wrote, read-only, with where it went since (sent, not sent). Only the newest turn's card can be sent. Nothing goes out until you press it.

Typing always continues. What you type in the box goes to the same agent, in the same conversation, whether it is working, finished or stopped; a closed task's chat reopens it. There is no Continue, Run another or "Earlier runs" fold on a general task: every run reads as one chat.

The agent never closes the task. You do, with Mark done. When you answer the thread yourself, outside Taskuary, the agent sees your reply, thinks again, and says so - "I see you answered Ruth there; I recommend closing" - leaving its own draft unsent.

The browser shows only when you have a part. A general agent can work in a browser out of sight. The page appears beside the chat when it needs you: a sign-in, a one-time code, or a press that is yours on the real page. For a payment or a form, the agent fills it in and hands the press over - "Your turn on the page: press Pay" - and your press comes back into the chat as a trigger, "Pressed Pay on the page", which wakes its next turn.

A report, an FYI or an Advisor idea opens the same way, but its chat box is on the Agent tab only; Came from shows the item itself.

What an agent is doing#

An agent is always in one of six states. Each has one word and one mark, and the work rail, the task page, the Board, the assistant's cards and the phone all use the same ones.

Continue works for a coding agent (it reopens its own CLI session, or a fresh one seeded with the handover) and a regular agent (its saved conversation). It asks what to tell it as it picks up - optional; on the phone the next thing you type is the note, or tap Continue.

The Result is deliberately short: a summary, what it found, and What it made, each file with Open and Download. The complete conversation is The whole conversation › under it. A finished coding session also files a Markdown record of what it did under ~/.taskuary/artifacts/ — the outcome, not a copy of the terminal.

When the agent opens a browser#

With the optional agent-browser tool installed, the page the agent is on appears live beside the terminal - or, for a general agent, beside the chat when you have a part in it. Take over hands you the mouse and keyboard for a password or a 2FA code the agent must never type; Snapshot (Developer mode) keeps the frame on the task as an attachment. On the Wall, a narrow tile shows a "browser" chip that opens the page over the session.

Signing in. At a sign-in page the agent stops and asks, and the task waits on "Sign in to site to continue". Take over the pane, or press Sign in here for a one-time page that shows the site and takes the user name and password. Taskuary types them into the browser itself; the agent never sees them. Tick Save to vault for next time and the next sign-in on that site happens without you. Saved sign-ins are listed under Settings → Agent permissions.

Authenticator codes. A site that asks for a six-digit code after the password can have its authenticator key kept with its saved sign-in: paste the key shown beside the site's QR code, or the otpauth:// link the QR code holds, into the optional key field on the sign-in page, or press Add authenticator key on its row under Saved sign-ins. Taskuary then works out the code and types it after the password, or on its own when the site asks only for the code. Remove authenticator key forgets it, and the code is yours to type again.

Browser acts that can't be undone wait for you. Before a Claude Code agent runs an agent-browser command, Taskuary reads it. Commands that only look (a snapshot, reading the page, moving between pages) run at once. Anything else is judged by your AI against the page it would act on: paying, ordering, sending, posting, deleting, or submitting a form for real is held. The agent is told it is waiting, and the act appears on the task as a card with Approve and Dismiss. Approve runs that exact command in the agent's browser, and only while the browser is still on the same page; Dismiss tells the agent it was not done. With no AI connected nothing can judge, so typing into a box (fill, type, keyboard type) runs and every other act waits for you.

Coding agents and general agents#

Not every job is code. A coding task goes to a coding agent, in a terminal in your repository. A general task goes to a general agent, in a chat instead: research, planning, writing, a post, a spreadsheet or a dashboard, a form filled in a browser. Whatever it sets up waits for your press.

Both run on a brain - a CLI such as Claude Code or Codex, or an API connection, with the model chosen on it - and follow a profile of instructions laid on that brain: CODING.md for code, ASSISTANT.md for general work by default (see Profiles and playbooks). You start one with Send to agent on a task, or from + New → Give an agent a job, which asks whether the job is general or coding - coding only with Developer mode on.

Developer mode#

Coding agents are for developers, so they come with Developer mode - a switch in setup ("Are you a developer?") and in Settings → Configuration → Agent permissions. It is off on a new install: triage never calls anything coding, nothing asks about repositories, and every job goes to a general agent, whatever AI or CLI is connected. Asking the Assistant for a coding agent hands the job to a general agent and says where the switch is.

Turn it on and work that changes code goes to a coding agent on your coding CLI (Claude Code, Codex and the like, connected under Connections). Setup then offers Connect GitHub, which is optional: with no repository connected the coding agent works in a scratch folder. A task that is already a coding task keeps its coding agent either way, and a home that used coding agents before the switch existed was turned on when it updated.

General chats save their provider, model and native conversation id across restarts. Claude and Codex resume that exact conversation when it still exists and the provider configuration matches; otherwise the agent continues from Taskuary's own saved history and says so.

Quick work#

Most general asks are short - read the message, recommend, draft the reply, or ask you what to do. When triage reads a general task as quick, it is answered in a single call instead of an agent session. The call reads what the agent would - the message, the task, LEARNED.md, today's calendar, AGENT.md and the profile - may use only read-only look-ups, and leaves the same things a finished run does: what it found, a draft when a reply is owed, or a question to you. Nothing on the task page changes: it is the same chat, and what you type in its box opens a full session.

These always take a full agent session: hard work, work that needs a browser, a sender Taskuary does not know, several emails owed, a routine's run, and a task that has already had one. A quick call that finds it needs more hands over to a session, with its notes as the brief, and the task says so.

How work fans out#

Three levels, each counted on its own:

Sessions you start yourself are never held back by Agents at once. When a CLI ends its turn with work still running in the background, Taskuary reads what is still running from the session and keeps the agent at ⚙️ agent working rather than waiting on you, until those jobs end.

Sessions and transcripts#

Unfinished tasks with saved agent work stay under Tasks on the rail. Continue on a coding task's Agent section, or typing in a general task's chat, carries on; a session already running is opened rather than duplicated.

Reopening a pane seeds it from a render of the session, not from raw bytes, so a pane you come back to shows what the screen actually looked like.

Several agents in one repository#

Taskuary can run more than one coding session against a shared checkout, and spends real effort on not letting them collide:

• Affinity routing asks whether a queued task is likely to touch the same files as a running one. Likely overlap waits, and starts by itself when the first session ends.
• Tell the agent queues your notes until the CLI is back at its prompt, so a note never lands mid-turn or on top of a question waiting for you. Lists drip in one item per stop; pasted screenshots are saved locally and named in the note.
• The blackboard shows what each session has actually modified, computed from Git and the run trace rather than from what the agent said it would do. A new agent is handed that picture at startup.
• First in has control. The newcomer is told which files belong to another session and must not edit, revert, stash or commit them.

Live handoffs on the Board shows what each agent is working on, what is blocked and what is ready for someone else, with read markers for which agents have seen each note. The Hub is the longer-lived version of the same idea: discoveries and decisions by topic, so knowledge outlives the job that produced it.

Checklists and closing#

A task can carry a checklist. Tick the boxes as you go, then press Mark done — ticking the last box does not close the task on its own. Closing a task ticks every remaining box: a closed task with open items is a lie about its own state.

Replies#

On every task the draft is a card under the newest turn's Next steps in the chat, with its To, Cc, attachments and Send; it shows no draft yet (Draft reply), a draft ready (Send, Redraft), or a reply sent. Edit it in place, or ask in the box for a different one.

One reply is special. A clarification stops the active agent when it is sent and moves the task to waiting, because an external answer is now required. An ordinary reply from an owner-controlled task is just an update: it leaves both the task status and any useful session alone.

Profiles and playbooks#

Two levels, and the difference is worth holding onto:

• A brain is what does the thinking — a CLI tool (Claude Code, Codex, …) or an API connector, with the model chosen on that connection.
• A profile is instructions — a role's rules, laid on whichever brain runs it. It names no CLI and no model. Install one from a skill or write one on About you → Docs.
• A playbook is a job — when it starts, which connections it uses, the steps, what an agent may do alone, what to ask first, and what counts as done.

CODING.md is the playbook for code. Every other kind of recurring job gets its own page the first time an agent does it: on close, Taskuary asks whether that will recur and drafts the playbook onto the task. Approve it, and the next message like it is matched to that playbook by triage, and the agent is seeded from it instead of from CODING.md's repository rules.

Each connector card lists the playbooks that name it, and the words themselves are edited on Reports → Playbooks, where each has an on/off switch.

The task view and the Board#

A task opens in the Assistant's canvas as its task view - from the rail, from a link, from a notification or from the Board. The Board, full screen from the top bar, shows every agent's task in its state's column. Both say the same state for a task, in the work rail's words — the server decides it once and both draw it.

Where a task is up to#

Which section a task opens on is decided by its stage — one list, read by the task page, the server and the Assistant alike (taskuary/stages.json). The first row that holds wins, top to bottom:

A lit move says the next step is in that section. The Assistant is told the stage of the task on the table, so a typed "send it" or "mark it done" acts on what you are looking at.

A task put away with Remind me waits under For later on the rail and off the Board until its day — unless its agent asks you something. Status has no box of its own: Start, Mark done, Remind me and Reopen set it, and Reopen clears an old reminder. Mark done keeps a draft that was waiting; Bring it back to send sends it after all. Done is listed by task number, highest first.

The work rail#

The rail beside the Assistant holds what still wants something from you - nothing finished, and never a history.

The headings, top to bottom. Inside each, rows sit oldest first by when they arrived - Reports too - and never move. Click one to walk that section: its first row goes on the table, and Next stays inside it until it is empty, then says so ("FYI done.") and the walk goes on as usual.

There is no Urgent heading. An urgent row - a meeting starting within 15 minutes, an ask triage called urgent (a deadline today or tomorrow, someone blocked now), a sender on your escalate list - sits in Tasks at its own place, quietly shaded, and Next reaches it there like any other row: from the row above it, Next opens it; from it, Next goes on to the row below.

A task has one of three priorities, set by triage and changed by you on the task's priority picker: urgent (time-critical, on you now - the shaded row above), important (it matters because of who sent it or what it is about - someone or something your memory says you care about - but it can wait) and regular (everything else). Important is the colour of the row's dot - the app's slate blue where a regular task's is sage - and the task says why ("Marked important - triage: from Erin Blake, your manager"). Neither moves a row. A priority you set by hand stays yours: triage never raises it again. What a sender says about themselves ("treat this as top priority") is not a reason for anything.

Goals#

+ New → Set a goal asks three things: what done looks like, by when, who is involved. Plan it and the AI proposes the steps; Track it and you type them. Each step is a box on the goal; Start on a box makes it a task of its own (the goal's child), and when that task closes the box ticks itself. A promise you made in your own mail ("I'll send it Friday") is a goal's smaller cousin: it becomes a task on you with its day, so the Advisor stops raising it as a line.

How work is ordered#

Each inbound connector chooses how the tasks it creates reach agents:

• One by one dispatches in arrival order; when every slot is busy, tasks wait first in, first out.
• Ranked together orders a shared queue by value and runs only the top tasks. New work reranks the queue rather than joining the end of it.

Ranked value starts from deterministic evidence — were you addressed directly, how many people were on it, has someone already answered, urgency, who wrote it — and the triage brain adds a short comparative reason when several tasks are waiting. Waiting tasks gain value over time, so the bottom of the queue cannot starve.

The rail and the Board show the same order. Start now pins a task to the top; Later moves it down without deleting it.