Why you see the plan before anything runs
An agent that acts on a paragraph has to read it first. The blueprint shows you what it read, so the mistake happens on the screen and not in your CRM.
Every agent product starts with the same promise: tell it what you want in plain words and it does it. Every agent product then meets the same problem. Plain words are ambiguous, and the first time you find out the agent read them differently from you is after it has done something.
“Email me the diff” could mean a message or a file. “Flag anything that does not match” could mean a column, a colour, a comment, or a Slack post. “Every Friday at 4pm” is clear until you ask which timezone. A person you were briefing would read your paragraph back to you before starting. Most agents do not.
Read it back as a drawing
Describe reads your description into a structure before it does anything: a trigger, if there is one, and a sequence of steps, each attributed to the app it touches, or to the model if it only thinks. Then it draws that structure under the words as you type.
The trigger node is amber and shows the schedule it understood, down to the cron string. Each step node shows its app’s mark and quotes the exact words it was read from. If a step is attributed to the wrong app, or a phrase you meant as one step became two, you see it immediately, in the drawing, before the first run.
This is the whole idea. The reading is the dangerous part of an agent, and the reading is the part you never normally see.
The same drawing everywhere
The blueprint appears three times, and it is the same drawing each time.
It appears under the composer as you write. It appears in the thread when the agent proposes the plan and asks you to confirm it. And it appears on the automation’s own page once it is running, next to every run it has done, so that six months from now you can see what it believes it is supposed to do without re-reading the paragraph.
For developers it appears a fourth time: as JSON from the API. The trigger, the steps, the connections and the model, in the same shape the app draws. A plan you check in a browser and a plan you check in a test are the same object.
What this costs
Reading first is slower than acting first, by a few seconds. We think that is the right trade in a product that touches your inbox, your CRM and your books. The run itself is where the time goes; the read is where the mistakes would have gone.
It also changes what the composer can do. Because the reader knows whether a description has a time or an event in it, the buttons change to match: a plain request gets Send, a description with a schedule gets Run once and Turn on. The interface follows what you wrote instead of asking you to classify it.
When the reading is uncertain
Sometimes the words really are ambiguous, and the honest answer is a question. The reader returns a one-line note when it is unsure, and the app shows it next to the drawing. “Did you mean the Revenue sheet in the shared drive, or the one in your drive?” is a much better thing to hear before 4pm on Friday than after.