whatcha finds the repetitive work inside a company, so you can work out which of it deserves an AI agent.
It pings people at random moments during the working day and asks one question: what are you doing right now. Ten seconds to answer out loud. Do that for a week and you get a log of what actually happens in a job, rather than what somebody remembers happening when a consultant asks them. A Dust agent then reads the log, groups the entries into the tasks that keep recurring, and ranks which of them are worth building an agent for and which are not.
It is a demonstration of a deployment method, not a product. The company in it is invented and nobody was really sampled.
The ranked shortlist the Dust agent produced, from one week of sampling four people. It is a Dust Frame, so it is live and interactive: every row opens to show the raw entries the recommendation was built from, there is a section for the candidates it rejected and why, and one for the places the sample was too thin to support a conclusion.
That Frame is the point of the whole repo. Everything below is how it got made.
A week of sampling, four people, 121 entries. This is the file that gets handed to the agent.
The agent's instructions are in dust/AGENT_PROMPT.md and the setup, written against the product rather than its documentation, is in dust/SETUP.md.
A company buys an AI agent platform and then has to work out which of its thousand workflows deserves an agent. The standard answer is a round of discovery interviews. Interviews are a bad instrument for this, and not because people lie.
People report what they think they do. They remember the unusual and forget the ordinary. Nobody tells an interviewer about the twenty minutes every morning spent putting the same numbers into a different template, because it does not feel like work worth mentioning. It feels like the background against which work happens. Interviews also select their own subjects: leadership decides who gets interviewed, and the roles nobody thinks to interview are often the ones holding the repetition.
Sampling beats asking. Ping people at random moments, ask what they are doing right now, and the repetition surfaces on its own without anyone having to notice it. This is experience sampling, a method from psychology, pointed at AI use-case discovery instead of at mood.
The app waits a random interval, 45 to 90 minutes by default, then pings you. You get ten seconds to answer out loud, transcribed in the browser. The entry goes into a log with a timestamp and nothing else: no categories, no tags, no editing. At the end of the week you export the log as one markdown file, upload it into a Dust folder and point an agent at it. The agent clusters the entries into recurring tasks, estimates what each costs, judges which are worth building against explicit criteria, and ranks them.
Try it: whatcha-eight.vercel.app. Press "Ping me now" rather than waiting three quarters of an hour.
The data in the demo is synthetic. One invented company, four invented people, one invented week, 121 entries. Nobody was sampled and Verrand does not exist. It demonstrates the instrument and the reasoning, not a finding about a real company. It is in data/synthetic-week.json.
There is an obvious objection to this and it is worth answering rather than leaving for the reader to find. I wrote the week knowing what the analysis should conclude, so the agent arriving there is not evidence that the method works. What it demonstrates is the instrument, the prompt and the reasoning, on data built to be hard in the specific way real sampling data is hard: the same task described differently every time, boring entries left in, and no one ever saying out loud that their work is repetitive. That last constraint is enforced by a test, in src/exportMarkdown.test.ts, which fails if any entry proposes its own conclusion.
The full ranking, with the supporting entries under each row, is in the Frame. The shape of it:
Top of the list is the regulatory affairs officer, moving safety data sheet content between country and language templates. Eight of her thirty sampled entries, on all five days, about a fifth of her sampled week judged recoverable. The source data is structured, the output is checkable, and it recurs daily. Nobody in leadership would know this, because it has always been done that way.
Second is the production planner, retyping a handwritten night handover into the planning system every morning. Notable for how it reads: he never once complains about it. The agent picked it out precisely because it is daily, manual, and described in a completely flat voice.
The largest single cluster in the whole dataset was rejected. A third of the planner's week goes on reconciling two systems that disagree with each other and with what is physically on the pallet. It looks like the obvious target and it is not, because most of it is walking to the shop floor to count something. The agent said so and ranked it sixth.
The scientist's week clusters just as heavily as the regulatory officer's, around finding prior internal work, but scored lower on feasibility because part of it lives in an archived share, a paper notebook and a drawer. Large cluster, small recoverable share.
The commercial manager's week produces the smallest recoverable time of the four. He is busy, and almost none of it repeats.
That is the argument for a horizontal platform over vertical tools. The opportunity sat in two roles a vertical tool would never have a product for, and that a discovery interview would never have reached.
I am not a developer. I came from materials and design, and I have watched good tools fail inside manufacturing companies for reasons that had nothing to do with the tools. A company buys something for the problem it says it has. The real problem is elsewhere, held by someone nobody thought to ask, and it does not look like a problem from outside because it has always been done that way.
Agents will not escape that. They have to be pointed at something specific, and the specific things are the ones nobody can name on request. So I doubt good deployment means picking one narrow workflow and building vertically into it. The value sits in the shape of somebody's actual week, and you cannot see that shape by asking.
This is an attempt at looking instead. Built with Claude Code, and parts of it are past my technical depth, which I would rather say than not.
Running this inside a real company is a permissions problem before it is a technical one, and it sits close to a line. An entry is a record of what someone was doing at 14:32 on a Tuesday. The moment people suspect a manager can read it, they stop saying "stuck behind a lorry" and start saying things that sound productive, and the instrument stops working.
The design answer is that names are not needed. The analysis clusters on what is being done, so the export can carry a role and drop the person, and you retrofit who it goes to once you know what you are building. The wrinkle is that in a company of 880 people "regulatory affairs officer at Nantes" is one person, so role labels re-identify. A real deployment would pool by role family and report only clusters that appear across several people, with the log staying on the device and retention measured in days.
None of that is built here. This is a demonstration, and saying so is more useful than a privacy feature nobody tested.
More of these than there are features. They are listed at length because the interesting question about an instrument is where it fails.
It cannot measure time. A ping tells you what someone was doing at 14:32, not for how long. What sampling gives you is frequency and pattern, which is what the method was designed for and what its authors claim for it: Csikszentmihalyi and Larson describe the Experience Sampling Method as an instrument for "frequency and patterning of daily activity" (1987). So the honest unit here is share of sampled entries, not share of the week. The agent prompt enforces that distinction, and the analysis says "share of sampled entries" wherever it would be tempting to say "a third of her time".
People do not answer when they are busy. This is the real problem, and it cuts against the method's own claim. A ping arriving mid-negotiation gets ignored; a ping arriving while you wait for an oven gets answered. So the log over-samples exactly the slack, low-demand work that the method claims to discover. The classic evidence for how badly self-reported compliance can drift is Stone and colleagues in the BMJ (2002): patients kept paper diaries with a light sensor hidden in the binding, 90% reported complying, and 11% actually had. Nothing in whatcha addresses this. A real deployment would need to record non-responses as data rather than as gaps.
Measuring changes the thing measured. Being asked six times a day what you are doing makes you notice what you are doing. That is reactivity, a known cost of diary and sampling methods generally (Bolger, Davis and Rafaeli, 2003). It may even be useful here, since noticing is the point, but it means week one is not a clean baseline.
The sample is thinner than the method's own convention. The standard protocol is seven to ten signals a day for seven consecutive days (Larson and Csikszentmihalyi, 1983). This is six a day for five days, across four people, one per role. One person is not a role.
The ping is in the wrong place. It fires as a browser notification, and only while the tab is open, which is close to useless. Nobody leaves a tab open for a week. The right channel is the one people are already interrupted by: a Slack DM, a Teams message, WhatsApp, an SMS, answered in the thread without leaving what they were doing. That is where a real version of this belongs, and it is also where the answer rate would come from. It is not built because it needs a bot token, a webhook and a server, and this repo has no secrets in it. Failing that, a menu bar app. What is deployed is a browser tab.
This matters more than it sounds. The production planner, who holds the second largest recoverable block in the analysis, spends his week away from a desk, and is precisely the person a browser tab would never sample.
Speech recognition is the browser's own. It works in Chrome on a desktop. On iOS Safari it takes the microphone, returns silence and reports no error, which is why an empty answer now falls through to the text field with the reason on screen rather than being discarded. On a desktop the better path is to ignore the built-in recognition entirely and dictate into the text field with whatever tool you already use. That does not work on iOS either: a keyboard extension bounces between apps without ever starting. On a phone, this is a typing app.
The data is invented. See above.
Vite, React, TypeScript, one hand-written stylesheet, no backend, no database, no API keys. Web Speech API for capture, Notifications API for the ping, localStorage for the log. One bundled typeface, Geist Sans, and no other external asset. Built with Claude Code, with the surface designed by Claude Design.
npm install
npm run devnpm run build produces a static dist/, deployable to Vercel with no configuration. npm run data:render regenerates the markdown dataset from the JSON using the same function the export button uses.
Decisions made while building are in DECISIONS.md.
MIT licensed.