From 7e5aa1a6ced7037bfc31b15cbf95224e3b584d3b Mon Sep 17 00:00:00 2001 From: Felix Yang Date: Tue, 13 Oct 2026 00:00:17 +0800 Subject: [PATCH 1/2] Docs: describe only the session controls the task page has The task page has one way out of an agent session, Save and end session; Give new prompt, Pause & save and Stop session are no longer in website/src/TaskPage.jsx, but docs/site still documented them. - tasks-and-agents.md: drop the three dead rows from the controls table, and the summary row for Agent work no longer lists "new prompt"/"pause"/"stop". - troubleshooting.md: the paragraph about ending a session now describes Save and end session. site/docs rebuilt with `cd website && npm run build:docs` and committed with it. --- docs/site/tasks-and-agents.md | 5 +---- docs/site/troubleshooting.md | 4 ++-- site/docs/search.json | 2 +- site/docs/tasks-and-agents.html | 16 ++-------------- site/docs/troubleshooting.html | 4 ++-- 5 files changed, 8 insertions(+), 23 deletions(-) diff --git a/docs/site/tasks-and-agents.md b/docs/site/tasks-and-agents.md index 61ea0a55f..cc38049d2 100644 --- a/docs/site/tasks-and-agents.md +++ b/docs/site/tasks-and-agents.md @@ -10,7 +10,7 @@ each stage owns exactly one state badge. | Part | What it records | Main controls | What it never does by itself | |---|---|---|---| | **Task** | The durable job and who owns it | owner, kind, priority, Reopen, Mark done | Starting or ending an agent session does not complete it | -| **Agent work** | One or more attempts by a coding or non-coding agent, plus the saved result | harness, model, new prompt, start, prompt, pause, finish, stop | Stopping does not mark the task done or send a reply | +| **Agent work** | One or more attempts by a coding or non-coding agent, plus the saved result | harness, model, start, save and end session | Ending a session does not mark the task done or send a reply | | **Close out** | The reply to the person who asked, and the last act where the task lives (merge its pull request, close its issue) | write, generate, edit; **Close out**, **Decline**, **Not yet** | Sending it marks the task done — unless an agent is still working, a new message came in, or its merge still waits | While a terminal or an assistant chat is live, the task collapses to a one-line context strip and @@ -86,10 +86,7 @@ and topic history, the learned profile, and reports from related closed tasks. |---|---| | **Start coding session** | Starts the selected harness and model | | **Start new coding session** | Picks a different harness after an earlier run stopped or hit a limit; the checkout and history are kept | -| **Give new prompt** | Queues another instruction for the live session | -| **Pause & save** | Ends the session after writing a handoff note for the next one | | **Save and end session** | Ends the session and writes its result; the task stays open until you mark it done | -| **Stop session** | Ends only the process. Deliberately changes neither task nor reply state | **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. diff --git a/docs/site/troubleshooting.md b/docs/site/troubleshooting.md index ccf5fde35..8cabd670b 100644 --- a/docs/site/troubleshooting.md +++ b/docs/site/troubleshooting.md @@ -98,8 +98,8 @@ fall back to an unrelated default working folder. **It is gone.** If the process died, the row reads ⏹ **agent stopped** and is forced unread, so it comes back to you rather than disappearing. Only **Later** holds it. -**Stop session** ends the process and deliberately changes nothing else — not the task state, not -the reply. If you want the task closed, **Mark done** does both. +**Save and end session** ends the session and writes up what it did; it deliberately does not +touch the task state or the reply. If you want the task closed, **Mark done** does both. ## A report returned nothing diff --git a/site/docs/search.json b/site/docs/search.json index 485e6365b..0c2ed146a 100644 --- a/site/docs/search.json +++ b/site/docs/search.json @@ -1 +1 @@ -[{"t":"Start here","c":"Start here","u":"./","x":"What Taskuary is, how to install it, and what the first hour looks like."},{"t":"What Taskuary is","c":"Start here → What Taskuary is","u":"./#what-taskuary-is","x":""},{"t":"Install on Windows","c":"Start here → Install on Windows","u":"./#install-on-windows","x":""},{"t":"Install with Python","c":"Start here → Install with Python","u":"./#install-with-python","x":""},{"t":"Command-line options","c":"Start here → Command-line options","u":"./#command-line-options","x":""},{"t":"Docker","c":"Start here → Docker","u":"./#docker","x":""},{"t":"Your first run","c":"Start here → Your first run","u":"./#your-first-run","x":""},{"t":"Choosing the AI setup","c":"Start here → Choosing the AI setup","u":"./#choosing-the-ai-setup","x":""},{"t":"Where your data lives","c":"Start here → Where your data lives","u":"./#where-your-data-lives","x":""},{"t":"What leaves your machine","c":"Start here → What leaves your machine","u":"./#what-leaves-your-machine","x":""},{"t":"Updating","c":"Start here → Updating","u":"./#updating","x":""},{"t":"Next","c":"Start here → Next","u":"./#next","x":""},{"t":"How it works","c":"How it works","u":"./how-it-works","x":"One message from arrival to approval: the Timeline, the five roads, and what triage actually decides."},{"t":"The Timeline","c":"How it works → The Timeline","u":"./how-it-works#the-timeline","x":""},{"t":"The five roads a message can take","c":"How it works → The five roads a message can take","u":"./how-it-works#the-five-roads-a-message-can-take","x":""},{"t":"What triage actually decides","c":"How it works → What triage actually decides","u":"./how-it-works#what-triage-actually-decides","x":""},{"t":"Nothing sends itself","c":"How it works → Nothing sends itself","u":"./how-it-works#nothing-sends-itself","x":""},{"t":"Correcting it teaches it","c":"How it works → Correcting it teaches it","u":"./how-it-works#correcting-it-teaches-it","x":""},{"t":"The documents that govern it","c":"How it works → The documents that govern it","u":"./how-it-works#the-documents-that-govern-it","x":""},{"t":"Where the rest of the workspace fits","c":"How it works → Where the rest of the workspace fits","u":"./how-it-works#where-the-rest-of-the-workspace-fits","x":""},{"t":"Connections","c":"Connections","u":"./connections","x":"The accounts Taskuary may read, and the role that says what it may do with each."},{"t":"What a connection is","c":"Connections → What a connection is","u":"./connections#what-a-connection-is","x":""},{"t":"The five roles","c":"Connections → The five roles","u":"./connections#the-five-roles","x":""},{"t":"Mail","c":"Connections → Mail","u":"./connections#mail","x":""},{"t":"Chat","c":"Connections → Chat","u":"./connections#chat","x":""},{"t":"Repositories and trackers","c":"Connections → Repositories and trackers","u":"./connections#repositories-and-trackers","x":""},{"t":"Data and report sources","c":"Connections → Data and report sources","u":"./connections#data-and-report-sources","x":""},{"t":"Coding CLIs and AI providers","c":"Connections → Coding CLIs and AI providers","u":"./connections#coding-clis-and-ai-providers","x":""},{"t":"Adding another of the same kind","c":"Connections → Adding another of the same kind","u":"./connections#adding-another-of-the-same-kind","x":""},{"t":"Pushing something in yourself","c":"Connections → Pushing something in yourself","u":"./connections#pushing-something-in-yourself","x":""},{"t":"Tasks and agents","c":"Tasks and agents","u":"./tasks-and-agents","x":"A task, the agent work on it and the reply to the sender are three separate lives."},{"t":"A task's three lives","c":"Tasks and agents → A task's three lives","u":"./tasks-and-agents#a-tasks-three-lives","x":""},{"t":"Sending work to a coding agent","c":"Tasks and agents → Sending work to a coding agent","u":"./tasks-and-agents#sending-work-to-a-coding-agent","x":""},{"t":"The general agent","c":"Tasks and agents → The general agent","u":"./tasks-and-agents#the-general-agent","x":""},{"t":"Sessions and transcripts","c":"Tasks and agents → Sessions and transcripts","u":"./tasks-and-agents#sessions-and-transcripts","x":""},{"t":"Several agents in one repository","c":"Tasks and agents → Several agents in one repository","u":"./tasks-and-agents#several-agents-in-one-repository","x":""},{"t":"Checklists and closing","c":"Tasks and agents → Checklists and closing","u":"./tasks-and-agents#checklists-and-closing","x":""},{"t":"Replies","c":"Tasks and agents → Replies","u":"./tasks-and-agents#replies","x":""},{"t":"Profiles and playbooks","c":"Tasks and agents → Profiles and playbooks","u":"./tasks-and-agents#profiles-and-playbooks","x":""},{"t":"The task view and the Board","c":"Tasks and agents → The task view and the Board","u":"./tasks-and-agents#the-task-view-and-the-board","x":""},{"t":"The work rail","c":"Tasks and agents → The work rail","u":"./tasks-and-agents#the-work-rail","x":""},{"t":"How work is ordered","c":"Tasks and agents → How work is ordered","u":"./tasks-and-agents#how-work-is-ordered","x":""},{"t":"Assistant buttons","c":"Assistant buttons","u":"./assistant","x":"Every button under an Assistant card, the one question two of them ask, Remind me, and the words that work typed."},{"t":"One screen: the sidebar and the canvas","c":"Assistant buttons → One screen: the sidebar and the canvas","u":"./assistant#one-screen-the-sidebar-and-the-canvas","x":""},{"t":"The buttons on each card","c":"Assistant buttons → The buttons on each card","u":"./assistant#the-buttons-on-each-card","x":""},{"t":"The two buttons that ask one question","c":"Assistant buttons → The two buttons that ask one question","u":"./assistant#the-two-buttons-that-ask-one-question","x":""},{"t":"Pictures, and your voice","c":"Assistant buttons → Pictures, and your voice","u":"./assistant#pictures-and-your-voice","x":""},{"t":"Remind me","c":"Assistant buttons → Remind me","u":"./assistant#remind-me","x":""},{"t":"Everything the task page can do","c":"Assistant buttons → Everything the task page can do","u":"./assistant#everything-the-task-page-can-do","x":""},{"t":"Words that work typed","c":"Assistant buttons → Words that work typed","u":"./assistant#words-that-work-typed","x":""},{"t":"What the Assistant sees","c":"What the Assistant sees","u":"./assistant-tools","x":"Every tool the Assistant has: the summary it gets on every turn, and each tool in detail. Written from the code."},{"t":"The summary, sent every turn","c":"What the Assistant sees → The summary, sent every turn","u":"./assistant-tools#the-summary-sent-every-turn","x":""},{"t":"Table","c":"What the Assistant sees → Table","u":"./assistant-tools#table","x":""},{"t":"Task","c":"What the Assistant sees → Task","u":"./assistant-tools#task","x":""},{"t":"Agents","c":"What the Assistant sees → Agents","u":"./assistant-tools#agents","x":""},{"t":"New","c":"What the Assistant sees → New","u":"./assistant-tools#new","x":""},{"t":"Pipe","c":"What the Assistant sees → Pipe","u":"./assistant-tools#pipe","x":""},{"t":"Reports","c":"What the Assistant sees → Reports","u":"./assistant-tools#reports","x":""},{"t":"App","c":"What the Assistant sees → App","u":"./assistant-tools#app","x":""},{"t":"Look","c":"What the Assistant sees → Look","u":"./assistant-tools#look","x":""},{"t":"Reports and the Advisor","c":"Reports and the Advisor","u":"./reports","x":"Reading the systems you work in on a schedule, and the report whose job is to judge."},{"t":"A report is a pipeline","c":"Reports and the Advisor → A report is a pipeline","u":"./reports#a-report-is-a-pipeline","x":""},{"t":"Sources","c":"Reports and the Advisor → Sources","u":"./reports#sources","x":""},{"t":"Letting the AI write the source cards","c":"Reports and the Advisor → Letting the AI write the source cards","u":"./reports#letting-the-ai-write-the-source-cards","x":""},{"t":"The AI pass","c":"Reports and the Advisor → The AI pass","u":"./reports#the-ai-pass","x":""},{"t":"Where a run goes","c":"Reports and the Advisor → Where a run goes","u":"./reports#where-a-run-goes","x":""},{"t":"Schedules","c":"Reports and the Advisor → Schedules","u":"./reports#schedules","x":""},{"t":"The Advisor","c":"Reports and the Advisor → The Advisor","u":"./reports#the-advisor","x":""},{"t":"Stateful workflows","c":"Reports and the Advisor → Stateful workflows","u":"./reports#stateful-workflows","x":""},{"t":"Sage Intacct, specifically","c":"Reports and the Advisor → Sage Intacct, specifically","u":"./reports#sage-intacct-specifically","x":""},{"t":"API","c":"Reports and the Advisor → API","u":"./reports#api","x":""},{"t":"On your phone","c":"On your phone","u":"./phone","x":"The same assistant over WhatsApp or Telegram, and what it may do there."},{"t":"The doorways","c":"On your phone → The doorways","u":"./phone#the-doorways","x":""},{"t":"What it can do","c":"On your phone → What it can do","u":"./phone#what-it-can-do","x":""},{"t":"The morning line","c":"On your phone → The morning line","u":"./phone#the-morning-line","x":""},{"t":"Handing over","c":"On your phone → Handing over","u":"./phone#handing-over","x":""},{"t":"What it will not do","c":"On your phone → What it will not do","u":"./phone#what-it-will-not-do","x":""},{"t":"Sections, For later and browsing, on the phone","c":"On your phone → Sections, For later and browsing, on the phone","u":"./phone#sections-for-later-and-browsing-on-the-phone","x":""},{"t":"Settings reference","c":"Settings reference","u":"./settings","x":"Every setting, generated from the same file the app and the assistant read."},{"t":"How to read this","c":"Settings reference → How to read this","u":"./settings#how-to-read-this","x":""},{"t":"Triage & agents","c":"Settings reference → Triage & agents","u":"./settings#triage-agents","x":""},{"t":"Triage & routing","c":"Settings reference → Triage & routing","u":"./settings#triage-routing","x":""},{"t":"Replies","c":"Settings reference → Replies","u":"./settings#replies","x":""},{"t":"Assistant","c":"Settings reference → Assistant","u":"./settings#assistant","x":""},{"t":"Assistant on your phone","c":"Settings reference → Assistant on your phone","u":"./settings#assistant-on-your-phone","x":""},{"t":"Advisor","c":"Settings reference → Advisor","u":"./settings#advisor","x":""},{"t":"Coder agent","c":"Settings reference → Coder agent","u":"./settings#coder-agent","x":""},{"t":"Agent permissions","c":"Settings reference → Agent permissions","u":"./settings#agent-permissions","x":""},{"t":"Notifications","c":"Settings reference → Notifications","u":"./settings#notifications","x":""},{"t":"Attachments & images","c":"Settings reference → Attachments & images","u":"./settings#attachments-images","x":""},{"t":"Sync & startup","c":"Settings reference → Sync & startup","u":"./settings#sync-startup","x":""},{"t":"Display","c":"Settings reference → Display","u":"./settings#display","x":""},{"t":"Routing policies","c":"Settings reference → Routing policies","u":"./settings#routing-policies","x":""},{"t":"Verdicts & notes","c":"Settings reference → Verdicts & notes","u":"./settings#verdicts-notes","x":""},{"t":"Audit integrity","c":"Settings reference → Audit integrity","u":"./settings#audit-integrity","x":""},{"t":"When something is wrong","c":"When something is wrong","u":"./troubleshooting","x":"What to check, in the order worth checking it."},{"t":"It will not start","c":"When something is wrong → It will not start","u":"./troubleshooting#it-will-not-start","x":""},{"t":"A connection stopped","c":"When something is wrong → A connection stopped","u":"./troubleshooting#a-connection-stopped","x":""},{"t":"Triage got it wrong","c":"When something is wrong → Triage got it wrong","u":"./troubleshooting#triage-got-it-wrong","x":""},{"t":"A reply has no confirmed delivery","c":"When something is wrong → A reply has no confirmed delivery","u":"./troubleshooting#a-reply-has-no-confirmed-delivery","x":""},{"t":"An agent is stuck","c":"When something is wrong → An agent is stuck","u":"./troubleshooting#an-agent-is-stuck","x":""},{"t":"A report returned nothing","c":"When something is wrong → A report returned nothing","u":"./troubleshooting#a-report-returned-nothing","x":""},{"t":"Reading the audit log","c":"When something is wrong → Reading the audit log","u":"./troubleshooting#reading-the-audit-log","x":""},{"t":"Where the logs are","c":"When something is wrong → Where the logs are","u":"./troubleshooting#where-the-logs-are","x":""},{"t":"Still wrong","c":"When something is wrong → Still wrong","u":"./troubleshooting#still-wrong","x":""},{"t":"","c":"Start here","u":"./","x":"Taskuary is a work assistant that runs on your own machine. It reads the places work arrives — mail, chats, issue trackers, monitoring, your finance system — decides what each thing actually is, and brings you the few that need you. Coding jobs go to a coding agent in your repository. Answers come back as drafts you approve. Nothing is sent without you. It keeps its data in a SQLite file in your home directory and serves its interface at http://127.0.0.1:7787 . There is no account to create and no server to rent. What Taskuary is Three sentences, because the rest of this site is detail: 1. Everything arrives in one Timeline. A vendor's email, a GitHub pull request, a Teams message, a failed nightly export and this morning's spend report are one list, in the order they happened. 2. Each item gets one verdict. A small AI reads it and decides: nothing to do, a sentence settles it, an agent should work it, let's talk it through, or it's yours. That verdict is visible, and arguing with it teaches the next one. 3. Work that can be done is done, and comes back for approval. A coding agent works in your checkout; replies wait on the task. Approving is always a human action. :::rule The one thing to understand Taskuary never sends anything by itself. Replies, comments, invoices and posts all wait for you on the task. The only deliberate exception is an alert you configured, which fires the moment its rule trips — an alert that waits for approval is not an alert. ::: Install on Windows Download [Taskuary.exe](https://github.com/ldbumble/taskuary/releases/latest/download/Taskuary.exe) and open it. It is one file: the app and the desktop shell together, with no Python and no installer. The first run creates %USERPROFILE%\\.taskuary\\ and opens the interface. Install with Python Python 3.10 or newer: The browser opens by itself. For the same interface in a native desktop window: :::note Which platform gets the most use CI runs the full test matrix on Windows, Linux and macOS. Development happens mostly on Windows, so the terminal, the desktop shell and the agent presets are best exercised there; macOS and Linux may still have rough edges. ::: Command line options The everyday options for the Python install are: Option What it does port PORT Overrides the configured server port for this run host HOST Overrides the configured server host; use 0.0.0.0 to listen on all interfaces no browser Starts the server without opening a browser tab debug Enables verbose console logging for requests, report runs and errors Run taskuary help for the complete command reference. Docker Runs Taskuary without putting Python on the host: Open http://127.0.0.1:7787 . Data lives in the taskuary data volume. The container gives you the Timeline, Review, Reports and Connections; coding CLIs and the optional WhatsApp bridge stay host programs, because both need a machine of their own. The compose file binds to localhost. Set TASKUARY_TOKEN before publishing the port anywhere else. Your first run Open Set up Taskuary on the Assistant. The first four steps get you to one useful result: 1. Say who you are. Add the name that signs your drafts, and your email so Taskuary can recognise your own messages. Detailed preferences can wait. 2. Connect one AI. Use an API provider, Ollama, or a signed in coding CLI you already pay for. Test its connection. Keep the current model defaults to start; reviewing every model assignment is optional. 3. Connect one work source. Choose one mailbox, chat, or issue tracker in [Connections](connections). Enable it as an input and test it. You do not need a mailbox if your first source is a tracker such as GitHub. 4. Press Read first items. This starts a real source read and shows its progress. Once items arrive, open one of the first five recent results to check its verdict and any draft. Replies still wait for your approval. If nothing arrives, the step explains how to check the source scope or try a new incoming message. The five items are a review sample, not an import limit: each source keeps its normal read scope and history settings. Starting with one source makes that first review easier. Setup does not overwrite an existing user's model or connection configuration. After that first result, add another source, connect a coding CLI if you want code written, or add a report for numbers you check by hand. The optional models and agents step opens the existing settings whenever you want to adjust cost or use different models for different jobs. Reports and the Hub can wait until you have a workflow that needs them. Two reports exist from the start: the End of day checkup and the Advisor , which looks for useful follow ups and patterns in your work. You can review or remove either in Reports. The Morning digest is available as an optional report. Choosing the AI setup Triage reads many messages cheaply; coding changes a repository rarely and wants a strong model. Taskuary lets those be different brains, and the choice is mostly about what you already pay for. Setup Triage, drafts, summaries Coding sessions Fits you if Two brains (recommended) a small cloud model on an API key your coding CLI's full model you have a low cost API key One brain, two gears the CLI's light model the same CLI's main model you have one CLI subscription and no key One brain, one gear the CLI's full model the same model simplest, and expensive for routine mail Local brain Ollama or any OpenAI compatible local server a coding CLI, optionally the same local model no key, and no mail leaving the machine With no cloud key, set the triage brain to your configured CLI in [Settings](settings triage agents), and give that CLI a light model on its connector card so routine triage does not burn the coding model. Where your data lives The Python and desktop installs keep everything in ~/.taskuary/ : File What it is taskuary.db the SQLite database — messages, tasks, settings, the audit log config.toml local configuration taskuary.log the application log playbooks/ .md one page per kind of job an agent has learned to do context/ the context file each coding session is handed at startup TASKUARY_HOME moves all of it. Docker uses /data inside the container. TASKUARY_HOST , TASKUARY_PORT and TASKUARY_TOKEN override server settings at runtime without being written back to the config file. :::warn Before you expose it beyond localhost Set [server].token in the config or provide TASKUARY_TOKEN , and send that token in the X Taskuary Token header. An unauthenticated Taskuary reachable from the network gives whoever finds it your mail, your repositories and an agent that can run commands. ::: What leaves your machine Taskuary calls the services you configure and nothing else. Hosted AI providers and coding CLIs receive the prompts their work needs. With a model running on your machine, those prompts stay on it too; connected services such as mail still use their own connections either way. Before a prompt reaches a hosted model, a headless CLI run or the first turn of an agent pane, Taskuary replaces recognisable credentials with labelled placeholders. The original message is never altered. A reply that still contains one of those placeholders is refused rather than sent. These are deterministic shape rules — they catch API keys and passwords that look like API keys and passwords, and they cannot catch every secret. Updating Settings → Updates shows the running build and the latest release, and installs it in place: the exe is swapped or pip install runs, and the app reopens. Connections and settings are untouched. For the Python install you can also do it yourself: Next [How it works](how it works) — one message from arrival to approval. [Connections](connections) — what Taskuary may read, and what it may do with it. [Reports and the Advisor](reports) — before you build your first report. The live API reference is at /api/docs while Taskuary is running.","body":true},{"t":"","c":"How it works","u":"./how-it-works","x":"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 Advisor 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, under Urgent, Your task, Passed, Reports, FYI and Agents working. A finished or closed item gets no row: the rail is what still wants something from you, never a history. See [The work rail](tasks and agents the work rail) for what puts a row there and what takes it off. The five roads a message can take Every message gets exactly one verdict, and there are only five places it can go. Road What it means What happens fyi nothing to do filed; it stays readable and nothing is created reply a sentence settles it a draft goes to the task for you to approve coding an agent at a keyboard a CLI session starts in the checkout it picks general worth thinking about a conversation opens on the task; no system is touched task yours to do it lands on your list and nothing works it 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. :::note What \"general\" means It means the assistant's conversation: there is nothing to type at a system, but thinking, reading or research would help — weigh an option, make sense of a thread, work out what to ask. Work a person genuinely has to do in the world (sit a course, sign a form, attend, decide) is the task road instead. ::: 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\". Step Gate or AI What it does 1 Dedupe gate A message whose id is already stored is dropped. Nothing below runs. 2 Feed connections gate A connection marked feed lands on the Timeline and stops — no verdict, no AI call, no task. 3 Policy rules gate Your rules, plus whether the sender is known. skip and ignore end it here. 4 Deferral gate Deferred triage lands the message as triaging so the Timeline shows it at once; the rest runs later. 5 Chat opener gate \"hi\", \"you there?\" — filed to wait for the ask it opens, so a greeting never becomes a task. 6 Threading gate (scored) Similarity against open tasks picks attach or create ; then a thread that is not yours is refused. 7 Still the same ask? AI Chats only, and only when step 6 attached: does this line continue that task or start a new one? 8 Your standing ruling gate If you already ruled on this conversation it is filed, quoting your own words. Your rulings outrank the classifier. 9 An agent is waiting gate If a run is live on the attached task, no verdict is asked for — the message goes to the agent as its answer. 10 The verdict gate, then AI Tracker items, obvious noise and calendar invites settle with no call. Everything else is one call reading TRIAGE.md , SOUL.md , JOB.md , LEARNED.md and your past verdicts. 11 Acting on it gate fyi files. A reply files instead of drafting when replies are off for that channel. Anything else becomes a task with its kind. 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. :::rule One way to finish A task ends with Mark done — on the task page, on the Assistant's card, or by saying \"done\" in the chat. Sending the reply marks it done too, unless an agent is still working on it or a new message arrived meanwhile. An agent that says it is finished closes its own task, and that result stays on your work rail until you have read it. See [Tasks and agents](tasks and agents who is allowed to close it). ::: 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: 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 under Settings → Docs . These are not configuration files around the edges — they are what the models are actually told. ![The eight operator documents and who reads them: TRIAGE, STYLE and JOB can be generated from three months of your mail; SOUL, CODER and COUNSEL you write; LEARNED and DIGEST write themselves](img/operator docs.svg \"Three are read out of your mailbox, three you write, two write themselves.\") Document Purpose Read by SOUL.md The constitution: rules, voice, escalation lines, repository map triage, replies, the assistant JOB.md What your job is: mission, responsibilities, who you serve, the cadences, what to protect. It weighs importance, never intent triage, the assistant, the morning brief TRIAGE.md What makes something a task, a reply or an FYI triage STYLE.md Greeting, tone, length, phrasing reply drafts COUNSEL.md How the assistant speaks, and how readily it takes a position the assistant, the morning brief, replies CODER.md How coding agents work and close out coding agents LEARNED.md The profile learned from your verdicts; always below SOUL.md triage, replies, coding agents DIGEST.md The current morning brief you Playbooks One page per kind of job: when it starts, which connections it uses, the steps, what an agent may do alone, what counts as done triage's when line, and the agent working it 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 onto the task. Generate from history on TRIAGE.md , STYLE.md and JOB.md bootstraps all of this from your last three months of mail: it compares what arrived with what you actually answered, reads how you write from your sent folder, and reads what your job is from both directions at once — who writes to you, who you write to, what recurs and on what rhythm. Each writes its 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 Advisor](reports). Hub — what agents have learned, by topic, so knowledge survives past one job. Docs — the documents above. Settings — everything else; see the [Settings reference](settings).","body":true},{"t":"","c":"Connections","u":"./connections","x":"A connection is one account Taskuary may read — a mailbox, a chat, a repository, a tracker, a database, a bank feed. Each card on the Connections page is one named connection, and its roles decide what Taskuary is allowed to do with what it finds there. Nothing is polled without an enabled role. A card with no role is a saved credential and nothing more. A card's settings its roles, what each repository or source does, processing, the agent's prompts wait for its Save bar, which lists every change before it is kept; Discard puts them back. Leaving the card with changes unsaved asks first. Test, sign in and a new credential still act at once. What a connection is One card is one account, not one kind of system. Rename it for the account or environment it represents — Ops mailbox rather than IMAP — and use Add another on the card to connect the same kind again. Two mailboxes, two GitHub organisations, or separate production and staging databases are all normal, and each keeps its own roles, its own schedule and its own name in every prompt. Secrets are write only in the interface: you can replace a password, never read one back. A database connection string may contain {password} so the saved password stays separate from the readable part of the configuration. The five roles A role is a permission, not a ranking. Role What Taskuary may do trigger Send inbound items through triage — they can become tasks, drafts or FYIs feed Show inbound items on the Timeline, unread by any AI report Make the source available to scheduled reports tool Let agents query it while working a task :::rule Feed is not a quieter trigger feed means no model ever reads those items — cheaper, quieter, and no verdict to argue with. ignore is a judgement about a message and happens further down, in your routing policies. If a source is noisy but you still want to see it, make it a feed. ::: A card can hold more than one role. A mailbox is usually trigger and tool ; a database is usually report and tool . Mail System Notes Outlook Mail and calendar, through Microsoft sign in or a tenant app registration Gmail and IMAP Any IMAP mailbox. Approved replies go back through the provider's SMTP, in thread Taskuary reads your Sent folder as well as your inbox. That is what makes \"has this been answered?\" a real question rather than a guess, and it is what STYLE.md 's Generate from history learns your writing voice from. :::note A shared mailbox needs saying so If the mailbox is shared, mail addressed to the team reads as mail addressed to you unless Taskuary knows otherwise. Name your own addresses in SOUL.md so triage can tell \"someone asked me\" from \"someone asked the team\". ::: Chat System Notes Teams , Slack Messages enter the Timeline through triage Telegram Bot based inbound, approved in chat replies, the Assistant walk on your phone; each chat is opt in WhatsApp A local bridge for inbound messages, approved replies and the Assistant walk on your phone. Unofficial protocol — use a number you can afford to lose Discord Watches selected bot channels and posts approved replies back into the originating channel Apple Messages macOS only. Reads the Mac's local Messages history and replies through Messages.app; needs Full Disk Access and Automation permissions Mattermost , Rocket.Chat A server you host. Each watched channel is its own source, and approved replies post back into it. Rocket.Chat needs two values — the token and the user id issued beside it Matrix Any homeserver, matrix.org or your own. Replies go back as your account rather than a bot, so the account has to have joined the room Google Chat Spaces on the Timeline and replies back into them. Reuses the Gmail card's OAuth client, so there is one registration in Google Cloud rather than two Chat is different from mail in one way that matters: a chat message often has no clock on it. \"Can you look at this when you get a chance\" is a real ask with no deadline, and Taskuary keeps those as their own kind of item rather than inventing urgency for them. A greeting on its own is held until the ask it opens arrives. Repositories and trackers System Notes GitHub Repository discovery, issues and pull requests as triggers, task specific standing prompts GitLab Assigned issues and merge requests, GitLab.com or self hosted Azure DevOps Work items assigned to the connected user, through WIQL @Me Jira, Asana, Monday.com, ClickUp, Todoist Assigned work items enter the Timeline through triage Linear, Trello Assigned issues and cards Notion Pages shared with the integration appear as a feed when they change Sentry, PagerDuty New unresolved errors and open incidents join the same funnel A tracker is the clearest case for trigger : an issue assigned to you is, by definition, work addressed to you, and triage settles most of them without an AI call at all. GitHub: what Close out does The GitHub connection has a Close out step: what finishing a task does on GitHub when you press Close out . These are your choices what each repository requires (branch protection, required checks and reviews) is read from GitHub for every pull request, and the card only offers what it allows. Setting Choices (default first) The token needs Close out on a pull request Merges it · Only closes the task Contents: write Merge method Squash · Merge commit · Rebase used when the repository allows it (same) Red checks the repository does not require Merge anyway, with a note · Stop and ask me Offer Update branch on when the pull request is behind and its author allows maintainer edits Pull requests: write Offer Re run checks on re runs the failed Actions jobs Actions: write Close out on an issue closes it on Issues: write Post your reply as the close out's comment on even with Reply to issue/PR authors off Issues / Pull requests: write Close out anyway, past the repository's own rules off admin tokens only, and only on your press Administration A repository you follow can override the pull request choice, the merge method and Close out anyway. Check the token asks GitHub, per repository, whether the token may do what these settings turn on. Data and report sources The full list is long and grows; these are the ones worth knowing about by shape. Databases and files — SQL Server, SQLite, SharePoint Lists, Google Sheets, a Windows/SMB share, SFTP, REST and RSS, and any MCP server tool. PostgreSQL , MySQL , ClickHouse , Snowflake and BigQuery each have their own card: the same executor with the dialect filled in, the default port known and the missing driver named in the error you actually get. The older Any database (connection string) card is still there for anything else with a SQLAlchemy URL, including raw ODBC through pyodbc. All of them are reads — these cards ship no write verb at all, and the engine's own user is the ceiling, so point them at a read only account. Cloud and monitoring — AWS (S3 buckets, CloudWatch log groups, arbitrary service calls), Azure (blob containers, Log Analytics, arbitrary ARM paths, and it can reuse the Outlook app registration), Microsoft Entra ID, Prometheus, Datadog, WinRM for PowerShell on a remote Windows machine. Finance — Sage Intacct, QuickBooks Online, Zoho Invoice, and bank and card feeds through SimpleFIN or Teller. These are the cards where the read/write distinction bites: each ships at read , so an agent proposes a bill or an invoice and you approve it on the task. Raising a card to write is what lets a routing policy pass small, known items through without you. Markets — Yahoo Finance, CoinGecko, Alchemy, ECB reference rates, SEC EDGAR filings, and a strategy screen that filters another card's rows. With a key: Twelve Data (quotes and computed indicators across stocks, FX and crypto), Alpha Vantage (slow limits, no card, no expiry), Finnhub (quotes plus company news, earnings dates and insider transactions), Polygon.io (bars and full market snapshots), Tiingo (properly adjusted end of day history), Financial Modeling Prep (fundamentals and ratios rather than prices) and Alpaca (a broker's own feed — read only; this card has no order executor at all). FRED needs no key or account whatsoever and is the one a fresh install can use immediately. Which to pick is a question of what you are watching, not of which is best: Finnhub if you follow companies, Tiingo or Polygon if you follow prices, FMP if you follow balance sheets, FRED if you follow the economy. The web — search it or read one page of it, each a single REST call with a key. Exa and Tavily read the web for an agent (Tavily can hand back a written answer with its sources beside it); Brave Search answers from its own index; SerpApi and Serper give back a search engine's page as it was ranked, which matters when the ORDER is the finding. To read one page: Jina Reader (no account at all), Firecrawl (clean markdown), ScrapingBee (for a page that fights back) and Apify (when the crawl is one somebody already wrote). They overlap on purpose — the bill and the terms differ far more than the results do. What is deliberately NOT here is anything that DRIVES a browser — logging in, clicking, filling a form. That runs over CDP through a real browser session and cannot be reached from an API, so a card promising it would be a card that never works. Social — LinkedIn , Bluesky and Mastodon . Nothing from these reaches the Timeline as work: a public timeline is not an inbox, so they are report sources and tools rather than triggers. Like every connection they start at full authority, so an agent can post. A public post cannot be recalled: set the card to read and a post an agent drafts becomes a proposal you approve on the task. Agent tools — treg puts thousands of endpoints across many providers behind one key, billed per call. Searching its catalogue is free and commits nothing, so an agent may do it unattended; calling an endpoint spends real money and can reach services that publish or order. The card starts at full authority like every connection; set it to read and every call becomes a proposal. Your own documents — the Knowledge base card indexes SharePoint library folders and folders on this machine (docx, pptx, xlsx, html, text, and pdf with pypdf ) into Taskuary's own SQLite. Once anything is indexed, a kb_search report answers questions from it on a schedule, agents call the same search as a tool, and the reply drafter, the assistant and coding sessions are handed the passages that bear on a thread. Passages are treated as facts to cite, never as instructions. :::warn Planned is not available The Connections page lists cards that are on the roadmap as well as ones that work — NetSuite, SAP, Workday, ADP, Epic, Cerner, PointClickCare among them. A planned card tells you so on its face. If the assistant suggests connecting one, saying yes is a vote for building it, not a connection. (This callout used to name \"a long tail of market data providers\" here. Eight of them were built and the sentence was not updated, so the docs called working cards planned — the market cards above all work.) ::: Coding CLIs and AI providers AI providers — Anthropic, OpenAI, Azure OpenAI, OpenRouter, Ollama (and any OpenAI compatible local server: LM Studio, llama.cpp, vLLM), and the Meta Model API. Coding CLIs — Claude Code, Codex, Qwen Code, OpenCode, Kimi Code, Gemini, Cursor, Copilot, Muse Code and Devin, plus any CLI that accepts a prompt on stdin. The connector defines its command, arguments, model argument and working directory behaviour. Two practical notes. A headless agent needs its noninteractive or auto approval flag, or it will hang waiting for a click that cannot happen — the presets set this for you. And the card's Test action runs a small prompt through the CLI before it ever receives real work, which is the fastest way to find out that a sign in expired. Every CLI card has a light model as well as a main one. Naming the same CLI as both your coder and your triage brain is normal and cheap, and it is the light ","body":true},{"t":"","c":"Tasks and agents","u":"./tasks-and-agents","x":"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 three lives The task page shows them as one numbered workflow — 1 Task → 2 Agent work → 3 Close out — and each stage owns exactly one state badge. Part What it records Main controls What it never does by itself Task The durable job and who owns it owner, kind, priority, Reopen, Mark done Starting or ending an agent session does not complete it Agent work One or more attempts by a coding or non coding agent, plus the saved result harness, model, new prompt, start, prompt, pause, finish, stop Stopping does not mark the task done or send a reply Close out The reply to the person who asked, and the last act where the task lives (merge its pull request, close its issue) write, generate, edit; Close out , Decline , Not yet Sending it marks the task done — unless an agent is still working, a new message came in, or its merge still waits While a terminal or an assistant chat is live, the task collapses to a one line context strip and the workspace takes most of the page. Full controls, saved results and restart choices come back when the agent stops. Who is allowed to close it ![Every way a task ends: you press Mark done, send the reply, tick the last box, hand it to a person or say Not ours; or an agent says it is done or its pull request merges](img/how a task ends.svg \"Every road ends in Mark done, or says why the task stays open.\") There is one close, Mark done , and every road below leads to it. 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. You or an agent does What happens Stays open when Mark done — the task page, the Assistant's button or card, \"done\" or \"close\" in the chat, the phone Mark done never Close out with a reply Sends it, then Mark done an agent is still working on it, or a new message came in while you were answering — it says why Tick the last checklist box Mark done an agent is still working on it Hand it to a person Forwards it, then Mark done never Not ours / Not a task Deleted if nothing was done on it, otherwise Mark done never Mark done on a channel that cannot send (the draft stays unsent) Mark done never An agent says it is finished ( taskuary done ) The session is written up; the task waits for you with its close out (below) and the draft if a reply is owed, otherwise it is done its close out or a reply waits on you, or you opened the session yourself Close out on GitHub, or Decline Merges or closes the pull request, or closes the issue, posts your reply, then Mark done never The pull request or issue it came from is merged or closed Same as an agent saying it is finished, with nothing owed never 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 finished by the reply. A pull request is finished by merging it, and an issue by closing it. Whatever the system, the card has the same three buttons only the line under them says what they do there: Button What it does Close out Finishes the task the normal way for its system, sends your reply with it, then Mark done Decline Closes it without doing it, where the system has that difference a pull request closed unmerged Not yet Nothing happens; the task stays open and on you (in the Assistant's walk this is Next ) The task's work is The rail says What Close out does there A pull request the agent opened, or the one the task came from ✉️ ready to close out Merges it the way you set on the GitHub connection (a draft is marked ready first), then posts your reply as its comment. The card reads the pull request from GitHub first: when the repository's rules say it cannot merge yet it says why and offers what fits Update branch , Re run checks , or Close out anyway where you allowed it An issue the task came from ✉️ ready to close out Posts your reply as the closing comment and closes the issue Mail, chat, anything else ✉️ ready to close out Sends your reply If the act is refused, nothing is sent. Merging or closing the pull request on GitHub yourself counts as answering it: the task closes by itself. 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: You do What happens instead Save and end session The agent stops and its report is written; the task stays open Reject a draft The draft is rejected; the task is untouched Next Read and moved on; open work comes back after a few hours Remind me Put away until the day you pick, then back on your rail that morning A stopped or quiet session Nothing — only you, or the agent saying so, ends a task Reopening a completed task starts a fresh task lifecycle rather than pretending an old terminal is still alive. Sending work to a coding agent Open Agent work , choose the CLI and model, and start. The session is handed the task summary, the incoming messages, the attachments, any saved result from an earlier run and your optional new prompt — plus a context file under ~/.taskuary/context/ holding the thread, relevant sender and topic history, the learned profile, and reports from related closed tasks. Control What it does Start coding session Starts the selected harness and model Start new coding session Picks a different harness after an earlier run stopped or hit a limit; the checkout and history are kept Give new prompt Queues another instruction for the live session Pause & save Ends the session after writing a handoff note for the next one Save and end session Ends the session and writes its result; the task stays open until you mark it done Stop session Ends only the process. Deliberately changes neither task nor reply state 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. 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 Timeline, the task page, the Board, the assistant's cards and the phone all use the same ones. Mark State What it means Your move ⏳ waiting to start Handed to an agent, not running yet Start now ⚙️ agent working Running, and needs nothing from you Leave a note for when it stops 👋 agent waiting on you Running, and it asked you something, needs your approval, or is stuck Answer it 💾 session saved You ended it with Save and end session ; its report is written Continue session , or Mark done ⏹ agent stopped It ended without finishing: a crash, a closed pane, Taskuary closing Continue session , or hand it on ✅ agent finished The agent closed the task, or the item it came from was merged or closed Read the result ![How an agent starts: handed off, auto start allowed or not, a free slot or next in line](img/agent start.svg \"Waiting to start always says why.\") ![While it runs: working, or waiting on you a question, an approval, stuck on a limit, quiet at its prompt](img/agent run.svg \"Your answer puts it back to work.\") ![How it ends: agent finished, session saved, the task closed, or agent stopped and Continue session](img/agent end.svg \"Only a session that ended by itself reads as stopped.\") It ended because What you see What brings it back The agent said it was done its Close out card if its work lives on GitHub, then ✅ agent finished ready to close out if a reply is owed a new message on it You pressed Save and end session 💾 session saved the report is written, the task stays open Continue session You pressed Mark done the task is closed and the agent stopped they write again The session crashed or was closed, or Taskuary closed ⏹ agent stopped a reply it had held is back for your yes Continue session , or Run another agent Continue session 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 as is . The saved result is deliberately short. Every finished coding session also writes a full Markdown artifact with that result and the complete transcript — Work details → Full artifact on the task page. When the agent opens a browser With the optional agent browser tool installed, the page the agent is on appears live beside the terminal. Take over hands you the mouse and keyboard for a password or a 2FA code the agent must never type; Snapshot 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. The general agent Not every job is code. A general task opens a conversation instead of a terminal: research, planning, writing, weighing an option, working out what to ask. No system is touched. You reach it from Talk it through on a Timeline row, from ＋ New → Give an agent a job → Just talk it through , or from Prepare me for it on a calendar invite. 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 assistant continues from Taskuary's own saved history and says so. Sessions and transcripts Continue previous work on the Assistant page lists unfinished tasks that have saved agent work, each with an excerpt of the latest reply or handover. Resume opens the task and carries on; Review draft opens a pending result. Loading the page starts nothing, and 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 The Reply section exists whenever the task has an incoming sender. It shows one of three things: no draft yet, a draft ready, or a reply sent. Open on the task is the ","body":true},{"t":"","c":"Assistant buttons","u":"./assistant","x":"The Assistant walks you through what is waiting: one item at a time, with a few buttons under it. There are eight buttons in all. Anything without a button still works when you ask for it in your own words, in the app or on your phone. One screen: the sidebar and the canvas Taskuary is one screen. The sidebar on the left is your work rail; the canvas on the right is the conversation, and whatever part of the app is in use opens inside it. Where What is there Top of the sidebar New (a task, a report or a workflow), then Reports , Connections , Hub and Settings Under the buttons Work \\ Timeline which rows the rail shows and the filter, then the day's count and Sync now The rail On you , Agents working , For later , Reports , Advisor ideas , FYI click a heading to walk that section The canvas The item on the table: a task opens as its full task view Task, Agent work, Close out with Next under it The top bar Board every agent and its session, full screen and back to the Assistant Reports, Connections, Hub and Settings are browsed in the canvas , by clicks: a button shows that part's sections, a section shows its cards, and a card opens with its own controls Back returns to the list. Ask the Assistant about the card that is open (\"why is this failing?\", \"turn this on\") and it knows which one you mean. An agent's session opens inside the task view, nearly the full height of the canvas; Expand gives it all of it. On a phone the task view is the screen, and Expand takes the session full screen with a back arrow to the chat. The buttons on each card ![Which buttons each kind of card shows](img/assistant buttons.svg \"Next is on every card. Nothing else is offered unless that card can actually do it.\") Button Shown on What it does Runs Next every card Marks it read and moves on. Open work you pass comes back after a few hours (Settings → Passed work comes back after) at once Mark done a draft reply, a finished agent, a task The one close: the task is done, an unsent draft is retired, a live agent is stopped, and it leaves your rail at once Close out a draft reply, a task's close out (a pull request to merge, an issue to close) Finishes the task the normal way for where it lives, then Mark done: sends the draft; on GitHub merges the pull request or closes the issue and posts the reply as its comment. The line under the card says which you confirm Run it an agent's proposal Runs the action the agent proposed you confirm Reply a person's ask, a finished agent with no draft Writes a draft reply. Nothing is sent at once Make a task an ask, an fyi, an idea A task on your own list. No agent starts you confirm Send to agent an ask, an fyi, an idea, a meeting, a report A task and an agent on it. The card asks which agent you confirm Not ours a draft reply, a proposal (not a close out), an ask, an fyi Files it. The card asks how far you confirm Send back to the agent a draft reply on a task (under More actions); a close out GitHub refuses for merge conflicts (the main button) Picks the task's own agent back up with your note or, on a conflict, GitHub's reason as the first thing it hears. The card comes back when it stops at once Save and end session an agent waiting on you Writes up what the session did and stops the agent. The task stays open at once Remind me any card with an open task behind it Asks for a day, then puts the task away until that morning: under For later on your rail, with its day. On the phone the days come as choices you pick the day A handful of fyi comes as one card with its own All read, next button. A close out card for a pull request also shows Decline (close it without merging) on the card only, never as a chat word or a phone choice and no separate Reject: the reply on it is edited or redrafted in place. The two buttons that ask one question ![Not ours asks how far; Send to agent asks which agent](img/assistant questions.svg \"The card asks; nothing runs until you confirm.\") Button Answer What happens Not ours Just this once This message is filed. Its task is deleted if nothing was done on it, otherwise marked done From now on Triage learns to file everything from this sender. Their mail still arrives and stays readable A rule in Settings An exclusion rule: their mail never reaches triage, and what already arrived leaves the Timeline. Reversible Send to agent A coding agent A task and a coding agent in a repository. The card asks which repository when it is not clear A non coding agent A task and an agent for reading, checking, drafting or research Send to agent starts on the agent triage would pick; the other is one click away on the card. Pictures, and your voice Paste a screenshot, drop an image, or use the paperclip in the chat line, in New , and in Continue session . It goes with your words: the Assistant looks at the picture itself, and a coding agent is handed the file to open. PNG, JPEG, GIF and WebP, up to eight at a time. The microphone beside each box dictates into it. Continue session opens as a card under the item, not a popup: type or say what to tell the agent as it picks up, add a picture, or continue as is. Moving on with Next puts the card away with the item. Remind me Every open task has Remind me on its page: tomorrow, next week, in 2 weeks, in a month, or any day from the calendar. Until that day the task waits under For later on your rail, saying when it comes back. That morning a note goes on the task and it is back under On you , however long ago it arrived. Ask the Assistant the same thing — \"bring TQ 0123 back in two weeks\" — and it does it at once, with an undo. Everything the task page can do Anything you can do on a task's page, you can ask the Assistant to do — about the task in front of you, or any task you name (TQ 0123). It shows you a card first, like every other action. It never guesses which task you mean. ![What you can ask about a task, and what each does](img/assistant task tools.svg \"One tool per action on the task page.\") Say, about a task What happens \"make this urgent\", \"rename it\", \"I'll take it\" Priority, title or owner changed \"this is a general job, not coding\" What kind of work it is changes, and a live session is closed if it no longer fits \"this belongs in the ledger repo\" The task moves to that repository \"tick off the first item\" That checklist box is ticked — the last box is Mark done \"add a note that Erin wants it by Friday\" A note on the task \"forward it to Erin\" A hand off is written for your yes — nothing is sent until you approve it \"ask the sender which date range they need\" The question is written for your yes \"start the coding agent on TQ 0123\" An agent starts on that task; it asks which repository when it is not clear \"continue the agent where it left off\" The agent's own last session picks up again \"stop the agent on TQ 0123\" Save and end session on that task's agent \"split this in two\" / \"it's the same job as TQ 0120\" Two tasks, or this one folded into the other \"this isn't a task\" Deleted, and triage learns it was not work \"it's done\" / \"reopen TQ 0123\" Mark done, or open again \"bring it back in two weeks\" Remind me — away until that morning \"send it\" / \"reject that draft\" / \"make it shorter\" The draft is sent, rejected, or written again Words that work typed These have no button. Say them, in the app or on your phone. Say What happens Runs \"reply and tell them…\" A draft with that gist, for your yes at once \"redraft it shorter\" The draft written again with the change at once \"yes, go ahead\" to a waiting agent Your answer goes to the agent you confirm \"run it again\" on a report The report runs again at once \"remember that…\" A fact kept in Settings → Memory, used by triage and the Assistant you confirm \"clear all the fyi\" Clears that set from the walk, with the count on the card you confirm \"set up a report that…\" A walk through for a report, connection or workflow you confirm \"stop hiding auto replies\" The setting is changed, with an undo at once \"what's waiting on me?\" Looked up and answered — tasks, reports, mail, calendar, settings at once \"what's in For later?\" The rail read by its own sections On you, Agents working, For later (with when each comes back), Reports, FYI at once Later and Tomorrow are gone: Next is the \"not now\", and Remind me puts a task away until a day.","body":true},{"t":"","c":"What the Assistant sees","u":"./assistant-tools","x":"A task's three livesSending work to a coding agentA report returned nothing#

Open the report row: the last run shows what it read, what came out, and the error if it failed.