Taskuary's whole behaviour is one loop: something arrives, it gets a verdict, the verdict decides who does the work, and whatever comes out waits for you. This page follows one message the whole way, then explains the machinery underneath it.

The Timeline#

The Timeline is the front door: every connection with a trigger or feed role lands here, in the order things happened. An email from a vendor, a pull request, a Teams message, this morning's spend report and a failed nightly export are one list.

Each row shows where it came from above its original time, so mail, chat, GitHub, a SQL report and an Assistant post are told apart at a glance. Calendar entries show the meeting time. Open a row for the full message, its attachments, what triage decided and why, any drafted reply, and the actions available on it.

Beside the Timeline, the work rail holds what is actually waiting on you, in lanes — unread, needs an answer, an agent is waving, stopped, later. A finished or closed item gets no row: the rail is what still wants something from you, never a history.

The five roads a message can take#

Every message gets exactly one verdict, and there are only five places it can go.

Three of those — coding, general, task — are kinds stored on the task, and the kind is what routes the work. reply is a kind too. fyi creates nothing at all.

Only coding is ever dispatched automatically. A conversation you did not ask for is noise, and a task is yours by definition, so both land on the Board and wait for your click.

What triage actually decides#

The verdict is the last thing that happens, not the first. Eleven checks run in a fixed order, and only two of them ask a model anything. A gate is deterministic: same input, same answer, no AI call, no cost. Knowing which is which is how you tell "triage got this wrong" from "a rule caught it before triage ever saw it".

Two rules hold wherever AI is involved. With no AI connector, a message is filed with "awaiting AI triage" rather than guessed at. A call that fails, or answers something unreadable, is filed too — never assumed to be work. Triage breaking is quiet and safe, not destructive.

So a message that never reached the classifier was stopped by steps 1–6 or 8–9, and the fix is a rule, a feed or a ruling. A message the classifier did judge and got wrong is corrected on the Triage tab.

Nothing sends itself#

Review is the outbound decision queue, and it is the only road out. A drafted reply sits there with the original request beside it; you edit the wording or the recipients, then Approve & send returns it through the channel the conversation started on. You can also ask for a redraft, reject it, or decide no reply is needed.

The same gate covers more than mail: a GitHub comment, an invoice, a bill posted to your finance system and a file written to a share are all proposals until you approve them. A connector card ships at a read-only authority, and raising it is a deliberate act.

Correcting it teaches it#

The roads on the Triage tab are not decoration. Correcting a verdict writes the reason into TRIAGE.md, the document the classifier reads on the next message — so the correction applies to the next message like this one, rather than becoming a rule about this one sender.

Every verdict is evidence. Editing a draft teaches voice; rejecting one teaches what should not be drafted; Not our task teaches where your responsibility ends. The exact decision is kept with its date, sender and subject, so future triage can judge whether a new message is genuinely similar.

Repeated patterns become lessons in LEARNED.md. Each machine-written line carries its evidence:

- John drops greetings and signs off in one word. [s:4 | ev: rv12,rv15,rv31 | seen: 2026-08-19]

• s is strength. A hypothesis starts at 2 and is promoted at 4 or more, supported by at least three episodes across two people or threads. Contradictions weaken it; stale hypotheses decay.
• ev names the verdicts that taught it, so you can go and read them.
• seen is the last date on which it held.

Delete a learned line and it is gone. Lines you write yourself carry no machine tag and are never rewritten. An inferred rule that would hide work waits in Proposed rules until you adopt it. SOUL.md always outranks LEARNED.md, and one setting switches the whole loop off.

The documents that govern it#

Taskuary's behaviour is plain Markdown on the Docs tab. These are not configuration files around the edges — they are what the models are actually told.

Playbooks are the ones that grow. CODER.md is the playbook for code; every other kind of job — a card charge to post as a bill, a new hire to set up — gets its own page the first time an agent does it. On close, Taskuary asks whether that was a kind of job that will recur, and drafts the playbook into Review.

Generate from history on TRIAGE.md and STYLE.md bootstraps all of this from your last three months of mail: it compares what arrived with what you actually answered, and writes the result into a marked block, leaving anything you wrote outside that block alone.

Where the rest of the workspace fits#

• Board — queued, working, waiting and completed agent tasks, with a live terminal and the files changed so far on the working cards.
• Studio — agent capacity as a floor: one desk per slot, occupied when a task is running, a raised hand when a session needs you.
• Wall — every live terminal side by side, each with its own prompt box.
• Tasks — the durable task, its agent sessions and the reply, as three separate records.
• Review — the outbound queue.
• Reports — connected data on a schedule; see Reports and the Assistant.
• Hub — what agents have learned, by topic, so knowledge survives past one job.
• Docs — the documents above.
• Settings — everything else; see the Settings reference.