The work your team redoes every week

Every team has a few jobs that eat a morning a week and never get automated, because writing them down properly costs an afternoon nobody has. Describe one in a sentence and an agent builds it, shows you the steps, and runs it from then on. Everything below is what that is made of.

One of these, end to end

Every Monday morning someone on the support team exports last week's tickets, reads down the list for the ones that never got an answer, and sends them to the team channel. It takes forty minutes and it gets skipped whenever the week is busy.

Here you write that sentence once. An agent turns it into a workflow: pull last week's tickets, drop the ones already closed, find the ones with no reply, write the list. A clock starts it at eight on Monday. The list lands in Slack before anyone is at their desk, and it says which tickets are new since last week, because it remembers last week's.

Nothing about it is hidden. You can open the workflow and see the four steps, change the wording of the message, and look at every run it has done, what each one cost and how long it took. When a step fails, the run stops on that step and tells you what it was holding, so you start it again from there rather than from the beginning.

Workflows

Every Monday, pull last week's open tickets, flag the ones nobody has answered and post the list to Support. Describe it once in those words and an agent builds it. From then on it happens whether or not you remember it.

The work you keep meaning to automate never gets automated, because writing it down properly costs an afternoon you do not have. Here you say it in a sentence and an agent assembles the steps, connects them and tells you what is still missing. What you get is a thing you can open: every step visible, editable by hand, and the same every run. When one fails at three in the morning, the run history shows the step it stopped on and what it was holding, so you fix that step and start again from it rather than from the beginning.

See the overnight digest recipe →

Where work arrives

It starts itself when the work turns up: a Slack, Telegram or Discord message, an email to an address of its own, a file dropped in a watched folder, an RSS item, a push to your repository, or a call from your own code.

Most automation dies at the first step, because somebody still has to notice that something has happened and go and start it. Here the thing that arrives is the thing that starts it, in whichever place your work already lands - the shared inbox, the team channel, the folder the scans go into. Nobody has to remember to check.

See how the inbox gets sorted →

Memory

Stop explaining your own business every time. It gets better the longer you use it: what was settled in March is still there in September, and nobody had to be the one to write it down.

The expensive knowledge in a company is never in the files. It is the decision made in March, the supplier who always invoices late, the reason you do it this way. That gets kept as it comes up, and it is there the next time anybody asks. You can read back everything it believes about your business, correct a line that is wrong and delete one it should never have kept - per workspace, so what it learned for one client stays there. Searching the documents you upload is the easy half, and it does that too.

See the bot that answers from your handbook →

Agents

Set one up for a job - support, bookkeeping, first-pass code review - and give it exactly the access that job needs and nothing else. One can hand work to another and wait for the answer.

One assistant that can do everything is one assistant you cannot trust with anything. Giving each job its own, with only the documents and machines that job needs, means the one answering customers cannot open the payroll folder, the bookkeeping one cannot email clients, and the code reviewer cannot touch either. You pick what each may reach, action by action.

See the contract check recipe →

A machine of its own

Some answers need something actually done, not described: four hundred scans renamed and converted, the spreadsheet job that crashes your laptop, a script run against last month's data. It has its own Linux machine to do it on, separate from yours and from everybody else's.

The useful half of most requests needs something run, not something written. Its machine keeps what you install on it between runs, reaches the network when it needs to, and can be thrown away and remade in seconds. So it can install what it likes, get it wrong and start again, and the worst afternoon costs you a fresh start rather than a machine somebody depends on. When the work has to happen somewhere specific - a build server, a box with a GPU, a licence that cannot move - paste one line onto that machine and it joins your workspace too. It dials out, so nothing of yours is opened to the internet.

See the pull request review recipe →

Scheduled work

The Monday report nobody gets round to writing, written. Hourly, daily, weekly or monthly, at the minute and in the timezone you choose, with a record of every run.

The jobs that slip are the recurring ones, because nothing breaks when they are missed - they just quietly stop happening. Putting one on a clock makes it somebody's job without making it anybody's job, and the history tells you it really has been running.

See the morning briefing recipe →

Chats

Ask in ordinary words and watch the work happen - what it looked up, what it ran, and which line of which document each claim came from.

An answer you cannot check is an answer you have to verify yourself, which is most of the work back again. Every step is shown as it happens and every claim carries the passage it came from, so checking is a glance rather than an afternoon.

See the Telegram bot recipe →

Your documents

Send it the ninety-page contract and ask what the termination clause says. The answer comes back with the page it came from, and it can hand you a finished file rather than telling you how to make one.

The document you need an answer from is always the ninety-page one. Every page of it is pulled out in full - PDFs, Word files, spreadsheets and decks - and indexed with the page and heading each passage came from, rather than the first few pages or a summary of the rest. So an answer can come from the clause on page forty and tell you it was page forty, which is what makes it checkable in a glance.

See the meeting notes recipe →

Not sure who to ask

Then do not choose. Type the question and it goes to whoever fits, matched against what each of your agents is set up to do. If it cannot tell, it leaves the question where you asked it rather than guessing.

Being asked to pick the right specialist before you have explained the problem is a strange thing to ask of anybody. Type the question and it lands with whoever is set up for it, which matters most for anyone who just has a question and should not have to know how you arranged things.

See the standup recipe →

Tools you already use

Connect Notion, a Git repository, a folder of files, a live browser or web search - or anything else that speaks MCP - and decide action by action which of them an agent may use.

The work lives in the tools you already pay for, and an assistant that cannot reach them is a toy. A catalogue of ready ones installs in a click and asks only for the key or the folder it needs; anything else connects by its own address or command. Then you switch on the individual actions an agent may take, one at a time, so read-only really does stay read-only and nobody widens it quietly later.

See the page watching recipe →

Keeping things apart

Clients, teams or projects each get their own agents, memory and files. Same login, nothing bleeding between them.

If you do work for more than one client, one shared pile is a problem waiting to become an apology. The separation is real rather than a filter on the screen: agents, memory, documents and what they have learned belong to one workspace and nothing reaches across, and that holds for what a workflow or a scheduled run can touch too. A question asked in one cannot be answered out of another's documents, and you still sign in once.

Finding things again

Find the conversation from three weeks ago by something that was said in it, not by guessing what you called it.

Nobody remembers what they named a conversation. They remember a phrase from it, or roughly when it was, which is what you can search by - so the answer you already got once does not have to be got again.

Recipes that use this →

When something looks wrong

See exactly what was asked and what came back, what it cost and how long it took. No summary standing in the way.

The moment you stop trusting an answer, everything else stops too. Every call is kept exactly as it went, so you can see whether the model was told the wrong thing or answered the right thing badly. Each one carries what it cost and how long it took, which is how you find the step quietly doing most of the work. Your monthly price does not move either way.

See the bug reproduction recipe →

What happens on a Tuesday morning

A live map of your agents, workflows, triggers and what feeds what, read from the workspace itself rather than from notes nobody updated. You will not remember what is running. You will not have to.

Six months in, nobody remembers what is set up or what feeds what, and the person who does is on holiday. So the answer to what happens on a Tuesday morning is a picture instead of an archaeology project.

See the numbers board recipe →

Start your workspace

One price a month for a workspace of your own, on your own address. The model connection is included, so there is no provider account to set up and no usage meter to watch.