Gray
Show-it-once automations for small businesses
Overview
The Problem
A demonstration leaves room for interpretation.
Small businesses run on repetitive computer work, like matching invoices and updating spreadsheets, but rarely have anyone to automate it. Automation tools ask them to describe the process as rules. Most people can't do that, but they can show it.
Showing has its own gap. When someone processes two invoices, the recording captures clicks and keystrokes, not the rules behind them. Next time, which invoices count? Which details change between runs? What happens when a customer isn't in the spreadsheet?
A person watching would ask. An automation that guesses silently will eventually be confidently wrong.
Approach
Teach it, check it, then let it run.
Gray never acts on a guess it hasn't shown you. Every workflow moves through three stages, and the person makes the call at each one.
Teach. Do the task once in the tools you already use, narrating if you want. Gray only records when you start it.
Review. Gray shows the steps and rules it inferred. You confirm or correct them.
Run. Gray works where you can see it, pauses when something doesn't match, and hands control back.
Interpretation
Make the interpretation easy to check.
From actions to intent
A two-minute demonstration can hold hundreds of low-level actions. Showing all of them would be accurate and useless, because nobody can check a log. So the review shows steps a person would name themselves: "Find new invoices," not "Click row 14."
[Your grouping rules, in two or three sentences. For example: a new step starts when the goal changes, not when the app changes. Steps are named in the person's own words, taken from their narration when there is any. The recorded actions behind each step stay one click away.]
The steps sit on a rail of connected nodes, and size shows focus. The step Gray is interpreting is the largest, and the others shrink with distance in both directions.
Each connection also shows a step's state. Ink means confirmed. The accent color means Gray is still working it out. No connector and a faded node mean the step hasn't been reached. The three states never blend, so "almost confirmed" can't be mistaken for confirmed.
Making assumptions visible
The riskiest inferences are the ones that look obvious. If you process last week's invoices on a Monday, did you mean "last week," or the specific dates you happened to pick? Gray turns each of these into a question attached to the step it affects, not a list on a separate settings page.
[The design comparison, in 2–3 sentences: what you tried first, why it fell short, what you chose, and what that choice costs.]
Control
A clear way to step in.
Checking a plan isn't the same as trusting a run. While Gray works, the person needs to know what it's doing, in which window, and how to stop it, without Gray covering the work itself.
Gray's status lives in a pill tethered to the window it's acting in. The tether makes the relationship literal: with two windows open, you can see which one Gray is in. [One sentence on the overlay: where the pill sits, and what it never covers.]
On invoice seven, the customer isn't in the spreadsheet. Gray doesn't guess. It pauses on that invoice, shows the rule that failed, and asks what to do: [add the customer, skip this invoice, or stop]. Once the person answers, Gray picks up from the same step. [Say whether it offers to save the answer as a rule for next time.]
The system
Turning interactions into rules we could build.
Gray's interface is a few ideas repeated precisely, so engineering can build it without guessing.
One law runs through both the brand and the product: gray is the resting state, and color means something is happening. The accent color appears in exactly two places, a step that's still forming and the status pill's dot, so it always means something when it shows up.
Every connector follows one construction rule, built from boolean shapes rather than drawn by hand. That way a tether between windows and a link between steps read as one family. Buttons are named by what they do to the agent (Run agent, Correct, Discard, Skip step), so the spec and the screen use the same words.
Behavior needed the same precision.
[Pick two or three: corrections made during recording, relative dates, unmatched items, dependencies between steps. One sentence each, the situation and the rule.]
[One real engineering constraint and its tradeoff. For example, what changed when you scoped out a browser extension, extra installs, and a screen-reading fallback, but kept voice narration.]
Progress
Gray's interface is a few ideas repeated precisely, so engineering can build it without guessing.
One law runs through both the brand and the product: gray is the resting state, and color means something is happening. The accent color appears in exactly two places, a step that's still forming and the status pill's dot, so it always means something when it shows up.
Every connector follows one construction rule, built from boolean shapes rather than drawn by hand. That way a tether between windows and a link between steps read as one family. Buttons are named by what they do to the agent (Run agent, Correct, Discard, Skip step), so the spec and the screen use the same words.