Skip to content

How it works

Why you can trust what the board shows you

On the first morning it will read a few hundred things and show you nine. This is exactly how it got to nine, and what it refuses to do on the way.

The first time you connect a mailbox, the board reads what is there and hands you a short list. On mine that was nine cards against a few hundred signals.

That is a lot to ask on day one. You have no track record with it. It has none with you. And the first thing it does is tell you that most of your morning does not need you.

Nobody should take that on faith. So here is the whole mechanism, rather than a reassuring summary of it.

What it reads, and what it does not

Five inputs. Your mail, through Gmail or Outlook. Your calendar. Your tasks, from ClickUp, Asana, Monday, Notion, Todoist or Trello, or written straight onto the board itself. And chat, through Slack or Discord, in the channels you point it at.

Connect more than one account per provider if you have them: two Gmails and a work Outlook land on one board. Private Slack channels work the same as public ones, with one difference in who joins: the bot adds itself to a public channel, and a private one needs a human to invite it first, which is Slack's rule rather than ours. It runs on a schedule through the working day, not the moment something arrives, so the board is a state you return to rather than something that interrupts you.

If you use none of those task tools, the board keeps its own tasks so you still have both halves. Mail and tasks are not alternatives. They are two halves of the same board, and losing one of them was never an acceptable answer.

The rule that decides

Everything is sorted by the action it requires, not by how important it looks.

That distinction is the whole design. Priority is a label somebody already argued about. The action required is a fact about the message. There are four possible answers, and every card lands in one of them.

Reply owed

A person is waiting on you.

Bookings

This needs a time on a calendar.

Follow-up due

You are waiting on somebody else.

Do it

Yours to make. No counterparty, no clock.

The fourth lane is the one that took longest to get right. Until I added it, anything with no counterparty fell back into Reply owed, so twenty drafts and receipts sat in a lane called Reply owed with nobody waiting on any of them. A lane that collects everything is not a lane.

Which tasks make the board is not a judgment at all. It is arithmetic, and it costs nothing to run. A task surfaces if it is overdue, or due inside fourteen days, or in an active status, or marked high or urgent. Nothing else. No model is asked whether your task is due, because that is not a question worth asking a model.

The hard part is what it leaves out

Anyone can build you a list. The difficult thing is earning the right to leave something out, and then being able to say exactly why.

Nothing is silently dropped. Everything set aside is counted, grouped, and carries the rule that set it aside.

Open any of those groups and you get two things. The rule, written as a plain sentence about what would have to change for those items to reach the board. And real examples underneath it, so a count is never something you have to take my word for. Pull any one of them back in a tap.

A number you cannot audit is a number nobody believes. That is why the receipts are there.

The restraint is engineered, not accidental

A worked example, because this is the part I would be most suspicious of if somebody else were telling me.

The board needed a rule to stop the same piece of work showing up twice from two different sources. The obvious version compares titles and folds the ones that look alike. Before turning it on I ran it as a report instead, across 467 open tasks.

It found 96 pairs that looked like duplicates. Two of them were duplicates.

Thirty-five of the rest were one essay being fanned out across three channels, which is three pieces of work with similar names. Most of the others were a single client appearing in an account record, a deal, a contract and a log, which is what a CRM is supposed to look like. Shipped on instinct, that rule would have swallowed thirty-five live tasks and I would have trusted the board the entire time it was happening.

So it never compares one task to another, and when it is unsure it shows you the card. A duplicate costs you a moment. A dropped signal costs you the work.

What it will not do to your data

One rule sits underneath all of this, and it is enforced in code rather than asked for in a prompt: never write something back that the board cannot read in full.

In practice that means you can tell it to rename a task out loud, because the board is holding the whole title and can put the whole title back. You cannot tell it to rewrite a description, because the board only ever holds the first slice of one, and writing that slice back would quietly delete everything past it with no way to restore it.

The same instinct shows up in three more places. An item the model refers to has to have actually been on screen that run, so an invented reference cannot reach your task list. Reassigning work is unreachable by voice at all, because being misheard should never move somebody else's job onto them. And when a source fails to report, the board says the source failed rather than rendering a calm empty state. An empty board and a broken connection look identical, right up until the moment they matter.

Where it stops today

Some of what runs on my own board does not run on yours yet, and you should hear that from me.

It runs on a schedule, not in real time. The bookings lane reads your calendar and proposes real times, and we have not yet watched it put a hold in on a live account, so treat taking one of them as yours to do. And drafting on your board reads the whole thread, where mine also reads the meeting transcripts, the prior email and the notes on the account, which is a real difference in what comes out.

It does learn how you triage, and I want to be exact about what that means, because it is the easiest thing on this page to oversell. The board reads what you have cleared, parked, rescheduled and cancelled, and uses it for one job: working out where you put a kind of thing, and how urgently you actually treat it. If you clear a sender the same day every time, that sender starts arriving higher. If you park a kind of update every time, it stops competing with the things you act on.

Here is what it will not do with that, and these are rules in the code rather than promises on a page. It will not decide something is already handled because you handled something like it. An invoice you cleared last month says nothing about this month's invoice. It will not silence something just because it resembles something you silenced before, because every silence on this board still has to carry a reason you can argue with, and "you ignored one like it" is a pattern, not a reason.

Separately, and more simply: mark something handled and the board writes that down so the next sweep does not hand you the same card again. Thirty days, only what you actually finished, and only for the sources it cannot write back to. That is a card not coming back. It is the plumbing, not the judgment.

One rule, everywhere

The counted groups with their receipts. The ledger that shows its own arithmetic. The description it will not overwrite. The failed source it names out loud. Those are all the same rule wearing different clothes.

Never claim what you cannot read back.

That is the reason to trust the board, and it is the only one I am willing to offer on day one. Everything else has to be earned in the weeks after.

See it on your own inbox.

Fourteen days, no card. Connect a mailbox and the board builds itself. If you would rather have the mechanism walked through against your actual inputs, that is a working session.

More on what the board is: the app. The method underneath it: The System Before the Work.