Browseflow is a visual builder for browser automation. You compose steps on a canvas — open a URL, act, extract, observe, call an API — and it runs them in a real browser.
The first version had the obvious node set: open, click, type, extract. Then a customer asked for something reasonable and it exposed the gap.
"Extract the price, but only if it is under 200"
That is a conditional, and the builder had no way to express one. The only options were to hardcode the threshold somewhere in the workflow, or to split into two workflows with logic outside the tool.
Both are bad in the same way: the logic stops living in the workflow. The person who built the flow no longer owns the decision, and the person who owns the decision cannot see the flow.
Adding a node that does nothing on purpose
The fix was a condition node and an observer node.
An observe node does not change the page. It runs an agent that looks at the current screen and returns structured observations — prices, labels, whether an error banner is present. It is a read, and it produces data that later nodes can branch on.
A condition node takes that observation and decides. Price under 200 continues, price over 200 stops.
The important part is that the observer is a first-class node rather than a property of the extract node. Once observation is a thing the flow can contain, conditional logic becomes a small addition instead of a redesign — and the branching shows up visually in the canvas, which is where a builder should show it.
Why the agent part is harder than it looks
An observe node that clicks the wrong thing is a bug that costs money. The agent has to be allowed to look without being allowed to act, which is a capability split, not a prompt tweak.
In Browseflow that split is enforced by the browser session itself: the observer runs against a read-only view of the page, and acting requires a separate session with different permissions. The observer cannot click, because it has nothing to click with.
That makes the node safe to run speculatively. The flow can observe first and act second, and the expensive, side-effecting step only happens on the branch that needs it.
The result
The node set went from four to nine. The interesting change is not the count, it is that the tool can now express the decision a user actually wants to make, in the place where the user is already looking.
An agent that only acts is a script with extra steps. An agent that can also look is what makes a workflow able to branch, and branching is most of what "automation" turns out to mean.