Reports are how Taskuary reads the systems you work in. The Advisor is a report with a different job: instead of filing what it read, it decides whether any of it is worth your attention. They share one builder, which is why they share one page here.

A report is a pipeline#

One report is one saved configuration under Reports - the sidebar's button, browsed in the canvas - built in four steps.

Sources at the top, one prompt at the bottom. Every source runs on its own connection and query, the results are stacked under labelled headers, and the prompt sees all of them at once. One source failing is named in the bell; the others are filed and sent as usual.

Sources#

A source card carries a type, an optional label, whatever that type needs to run, and a row cap. The type picker is grouped by where the data lives: this computer, files and sheets, databases, AWS, Azure, Microsoft 365, monitoring, corporate systems, the AI itself, the web, and Taskuary's own data.

Four things are worth knowing:

• label is how the prompt refers to that data. Two queries against the same database are two sources, and without labels the prompt cannot tell them apart.
• my own system says the source reads a system you own. It starts on for databases and corporate systems like Intacct and QuickBooks, and off for news, the web, social timelines and REST addresses. A report whose every source is on is trusted, and so are the tasks it opens; one source off makes it a stranger's. See Security.
• max rows is blank by default, and blank means 200 — a cap nobody chose. When a run is capped the headline says so, so the AI can never describe a truncated slice as complete.
• Test — show me the data returns the exact text a scheduled run would hand the prompt. Use it before assembling the rest of the pipeline.

Drag cards to reorder them; duplicate one to ask the same connection a second question.

Letting the AI write the source cards#

A source card asks you to know things first: which of thirty-odd types your data sits behind, what that type's config keys are called, and the query language of whatever is on the other end. Nobody remembers that a GL entry's amount is AMOUNT but a bill's is TOTALENTERED. So you can describe what you want instead, in three places:

Four things keep this from being a wish machine:

1. It may only choose a type whose connection actually exists. The catalogue is built from this install's live connectors, so it cannot answer "connect to Salesforce" — only tell you that nothing here reaches Salesforce and what you would have to connect.
2. The config keys come from the executors' own docstrings, so a composed card cannot drift from the keys the code really reads.
3. It reads the real schema before writing a query — an object's field list, a table's columns, which LOCATIONID the site you named actually has. Up to three look-ups per ask, each a real call whose result goes back to the model.
4. It is allowed to say it does not know. Questions come back as questions, at most three, each answerable in a few words. A guessed WHERE clause on a finance report is silently wrong forever; a question costs five seconds.

Everything it writes is checked before you see it: a real type, a connected one, and the keys that type needs to run at all. Nothing is saved — a composed card lands in the boxes you would have filled in by hand, and Preview runs it for real so you look at actual rows before anything is scheduled.

The AI pass#

The prompt at the bottom of the pipeline turns rows into prose. Leave it empty and the raw rows file as they are.

• Write a concrete instruction — "Summarise spend by site; flag any vendor above 10k or new this month" — not "summarise the data".
• Brain: the AI that sorts your mail writes it by default; any connector with a saved key can be picked per report. A saved pick that has lost its key stays visible and disabled rather than silently vanishing.
• With a prompt set but no AI connector active, the raw data files and the builder says so.
• A summary that fails, or comes back empty, is a failed run - the report exists for the summary.
• When one column is a measure worth plotting, the model that just read every row says so and the run hands back a bar chart beside the text.

Where a run goes#

Every report has one route card: four lines, and each line is every run, ask the AI (a sentence the judge answers yes or no to), when a rule trips (a number or words - no AI), or never.

• Send it somewhere — email, Teams, Telegram, WhatsApp, iMessage or Discord. It waits on the task for approval by default. "Send it without asking" is the one place in Taskuary where that gate can be switched off, and it is deliberate.
• Who gets it, asked in the chat — "send this report to gail@northwind.example every run" brings up the report with that address in its to — who gets it box, ready for your Save; the Assistant never saves a send for you. A name works when exactly one person by it has written to you. When it is not sure who - nobody by that name, or two people who share it - it asks you one question and fills in nothing.
• Let triage judge it when it fires is a switch under a Reports line that asks the AI or waits for a rule, and it is off unless you turn it on: most reports are news to read, and a daily summary never reaches triage. On, a run that meets the condition goes to triage, which reads it against TRIAGE.md and the report's own Make it a task when… sentence and decides whether it needs a task - a bug found, a job that did not run - or is a row to read. Nothing is made for what an open task already covers. A triage condition set apart from the Reports line's is kept, and the card says so.
• A run about a task you already have never becomes a second task and is never put on that task: it stays a row under Reports, and the task gets one note that the report mentions it - one a day per report.
• A failed run is in the bell, top right, and nowhere else: no row, never a task, never an alert, never sent to anyone. It clears itself when a run works again. A send or an alert that did not go is in the bell the same way, until the next one goes.
• A mute covers the alert and the morning brief as well as the rail.
• Who judges is one setting for every report, under Settings › How mail is sorted › Where runs go; blank means the brain that writes the report. try it on the last 5 runs shows what the card would have done, without posting anything.

Under each report row, the last run shows what it read, what came out, and the error when it failed.

Schedules#

Pick one or more: every N minutes, daily at HH:MM, a five-field cron, or on app start. No clock at all means the report runs only when you press Run now, and its row wears a red border that says so. A slot missed while the app was closed fires once on reopen. Reports have their own clock: turning the mail poll or the startup catch-up off does not stop them.

Run now and the switch sit on the report's row on the shelf and again at the top of its builder, beside Remove report - the same buttons, doing the same thing. A dashboard's are on its row; a routine's own page carries its Run now and its switch.

Ask the Assistant to "run it" or "pause it" with a report's builder open and it presses that builder's own Run now or switch, and you watch it happen in the chat.

A scheduled run that fails is tried again at its next scheduled time, never in between. A report runs one at a time; a second Run now while it runs is told so.

The Advisor#

The Advisor is a report of type assistant. It runs on its own schedule and when the app opens, and it posts an idea on the rail only when it finds something worth saying: an unanswered reply, context for an upcoming meeting, a task gone quiet, a pattern across incoming work, or something in the systems it watches that does not look right. Each suggestion names its evidence and carries the same words everywhere it shows up - the Assistant chat, the work rail and your phone. What it reads, its two clocks and the outcome ledger it learns from are on The Advisor; this section is the report that runs it.

Marking the row done on the rail puts the idea down as handled. An idea never reopens a task that is already done - new work it notices becomes a new task, carrying what it saw.

Its pipeline is itself, so its Pipeline step looks different from every other report:

• Systems and data views to check — source cards owned by this check alone. Anything a report can read belongs here, and no saved report needs to stand behind it: the Advisor pulls each one silently and files no intermediate report.
• …and pull these saved data views too — existing reports it should also read. A report can stay switched off as a standalone schedule and still be pulled here.
• What should the Advisor surface? — one instruction over all of the above plus its own view of your work.

Every post records what it reviewed and leaves a note for its next check, so it does not research the same silence twice or repeat a suggestion you have seen or put down. Each Advisor report keeps its own ideas: one report's open idea never silences another's.

Four things shape it:

• COUNSEL.md in About you → Docs — how it speaks, and how readily it takes a position.
• The Advisor report — what it watches, its schedule, its model.
• Settings → Advisor — thresholds such as how long a reply or task must be quiet.
• The outcome ledger — what came of what Taskuary did: a reply that got more rounds, a close that reopened, a promise delivered late, your own next move after an agent stopped. Resolved once a day from the store's own facts; reflection reads it as evidence. See Three brains, one voice.

Delete the Advisor report to switch it off. Its Preview shows exactly what a run would hand the model, which is the fastest way to find out whether a watched source returns what you think it does.

The morning brief is a separate report of type digest: it writes DIGEST.md and opens on the morning card daily. Deleting that report turns the brief off.

Ideas it raises#

Beyond what it watches, the Advisor looks at the shape of your own work and occasionally raises an idea: a system your mail keeps naming that nothing here reads, for instance - at most one such system per run, and never one it has raised before. The app's own health (a report failing run after run, a connection erroring) is raised the same way, and counts toward the post's lines like everything else.

Routines#

A routine is a job that writes or keeps state - posting bills, bumping dependencies, driving a portal - rather than a check that reads. Every run of a routine is a task, whatever started it: its schedule, Run now, the assistant, or you from your phone. The run never becomes a row under Reports and never goes through triage; its agent works it like any other task.

• A routine that names a profile (ap, say) runs as that profile, with its rules; one that names none runs on the assistant, or on the coding profile when it has a folder to work in.
• A routine with a folder (cwd) runs in that folder. If the folder is gone, the task says so and nothing starts.
• A routine runs on the same brain as your general agents (Settings → How mail is sorted → General agent), on its main model. For a hard job, the editor's Model row picks a stronger model from that CLI's own list and an Effort level - only the levels that CLI and model take (Claude Code's --effort, Codex's model_reasoning_effort). A CLI with no effort setting shows no Effort box; an effort it cannot take is left out and the task says why. The task's header says what it Runs on.
• One run at a time: a scheduled run that comes round while the last one is still working is not started, and Run now takes you to the run that is. A run that is only waiting for your yes does not hold the next one back.
• The task shows where it came from: the routine's mark, Routine · its name and Started by - its schedule (with the clock, e.g. "Mondays 08:00"), you, the assistant, or your phone - in the header and under Came from, with a link back to the routine.
• A mail can start it. Describe, in words, the mail that should start it under Start when a mail like this arrives ("a vendor sends an invoice for something we ordered"). Triage is shown every such routine beside your playbooks; when a mail is one, that routine runs and its run is the mail's task, with the mail filed on it. Its steps read the mail as {{mail.from}}, {{mail.subject}} and {{mail.body}} - as data, never pasted into a query. Approvals work as on any run. A routine that hands to an agent is not started by a sender who may not start one by themselves; that mail becomes a task of its own that says which routine it matched.
• A new routine's first scheduled run is its next slot - saving one on a Wednesday does not run a Monday job straight away. Run now runs it now.
• A run of steps with nothing waiting on it is done when its last step runs; a draft it wrote waits on its own task, which the step names.

Playbooks#

The third shelf on the Reports page, beside Reports and Routines. A playbook is how this company does one kind of 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. Triage matches arriving mail to a playbook's when line, and the agent working that task is handed the playbook.

• New playbook builds one with AI from a past email or your own words - the draft appears in the conversation with its Approve - or opens the editor to write it by hand.
• When an agent finishes a kind of job that will recur and no playbook covers it, Taskuary proposes one on the task; approve it and the next mail like it is matched.
• Each playbook has an on/off switch: off keeps it, and triage stops matching it. Settings → How mail is sorted → Use playbooks turns them all off at once.

Stateful routines#

Monthly Zoho invoices is the first routine on the Reports page that is not a query returning one result. One scheduled run opens a batch, the batch holds one row per customer, and each row advances separately through amount, draft, Review and sent.

1. Connect Zoho Invoice, then use Monthly invoices on Reports.
2. Choose the customers and a monthly cron. Saving enables the routine.
3. On schedule (or Open this month), Taskuary reads each customer's latest prior sent invoice and prefills its total. No new invoice exists yet.
4. Confirm or change the amounts, then Prepare Zoho drafts — each prior invoice is duplicated as a draft and gets one durable Review card.
5. Edit and approve each email. Approval sends that invoice; leaving the page, restarting Taskuary or approving a different customer does not lose the others.

The duplicate boundary is (routine, customer, YYYY-MM), stored locally and written into Zoho's reference_number. A retry after a timeout reuses an existing draft; an existing non-draft invoice blocks the retry rather than creating another. A changed total is applied automatically only when the previous invoice had one line — a multi-line invoice with a changed total stops for attention, because Taskuary cannot safely guess how to allocate it.

Sage Intacct, specifically#

Intacct is the case that made the AI card composer necessary, so it gets explicit help.

• Objects are named, not picked: APBILL, APBILLITEM, APPYMT, ARINVOICE, VENDOR, CUSTOMER, GLENTRY / GLDETAIL, GLACCOUNT, LOCATION, DEPARTMENT, GLBUDGETITEM, PROJECT.
• Field ids are UPPERCASE and not guessable — WHENCREATED is entered, WHENPOSTED is posted, a bill's total is TOTALENTERED, a GL entry's is AMOUNT. Every company also has custom fields.
• What fields does APBILL have? on the source card asks Intacct itself and lists every field in your company with its label and datatype. There is also a report type for that question, so you can hear about it the day somebody adds a field.
• Filters are FIELD op value, one per line — WHENDUE <= 08/31/2026. Dates are MM/DD/YYYY, and in takes a comma-separated list.
• readByQuery does not group or count. "How many bills per person" is the rows with the person field included, plus a prompt that counts them.

Leaving the field list blank returns every field on the object — right for a list you want to eyeball, wrong for GL detail.

API#

The full interactive reference is at /api/docs while Taskuary is running.