Tool
Three questions, none of them technical. At the end the tool says what you just described, what it does, what it doesn't, and what would have to change for it to be something else.
Question 1 of 3
Who starts the work?
The tool classifies by decision rights, not by brand or by model. Nothing you answer is stored.
The seven shapes
Seven concrete shapes, grouped into the four patterns. What separates them isn't the brand or the model: it's who starts the work and who decides the next step.
Answers, drafts, summarises and explains. It's the most common shape and the fastest to adopt.
It doesn't it doesn't reach company systems and leaves no trace inside the process. If nobody opens the tab tomorrow, the work happens exactly as before.
Saves the context and instructions, so nobody repeats them and answers look more alike across people.
It doesn't it doesn't start on its own: it still waits for someone to open it and ask, and it doesn't touch the systems.
Produces something you edit right there: a document, a spreadsheet, a calculator.
It doesn't it isn't maintained or connected to the operation unless someone publishes it. A month later the data inside is stale.
Runs on its own and leaves the result ready: the Monday report, the weekly summary.
It doesn't it doesn't choose what to do with what it found. If the result calls for an action, a person still takes it.
Drafts, calculates or suggests inside the tool the team already uses, and waits for approval.
It doesn't it doesn't shrink the team: somebody reviews one by one, and as volume grows that review is the bottleneck.
Runs without anybody opening it and writes into the systems at the planned steps. The model solves one specific step: classify, summarise, tag.
It doesn't it doesn't handle the case that wasn't in the drawing: there it stalls, flags, or carries on down the default branch.
Decides the next step and executes it: asks for what's missing, checks the system where the data lives, writes the result and hands off when it should.
It doesn't it isn't bought without three things in writing: the scope of what it can do alone, the cases where it must hand off, and where what it decided gets logged.
The full reasoning, with the four patterns and the three questions that work in a demo, is in the article this tool came from.
Because confusing them is expensive in both directions. Buying an agent for a three-fixed-step process is overpaying for something an automation handles better. Buying an automation for a process with twenty real variants guarantees the human team keeps handling the ones that didn't fit the diagram. And in a proposal, the difference defines who answers for the outcome.
It depends on what it does when the conversation leaves the script. If it follows a decision tree and repeats or hands off when something unexpected appears, it's an automation with natural language on top. If it decides the next step and takes actions in company systems, it's an agent.
It's useful for organising the conversation, not for replacing it. Answering for what you were shown in the demo, the tool tells you which category it is. What to ask for next is always in writing: the scope of what the system can do alone, the cases where it has to hand off, and where what it decided gets logged.