Don’t design workflows, discover them

Why autonomy works better when the environment does the teaching.

Most systems begin with a workflow. Someone sketches the steps, arranges them in an ideal order, and then hands the resulting sequence to an implementation team. The workflow becomes the backbone of the system, a fixed path everyone is expected to follow

.

That approach works when the world is stable and well understood. It fails when it is not.

In dynamic environments, workflows are rarely wrong in detail. They are wrong in assumption. They assume we can know, in advance, what must happen and in what order. They assume progress is linear or sequential. They assume the system will behave tomorrow the way it behaved today.

In recent work on a project called GRAIL, I have been starting from a different premise. Workflows are not inputs. They are outputs.

Start with the goal, not the steps

In GRAIL, a smart agent is given a goal and an environment. The environment is not a script. It is a collection of in-situ affordances, things that may or may not be possible, depending on conditions.

The agent does not design a workflow. It does not decompose the goal. It does not ask what usually comes first. It simply attempts the goal execution immediately.

This sounds reckless until you notice what happens next.

Goals as tests, not destinations

In GRAIL, a goal is an affordance. Like every affordance, it can succeed or fail. A failed attempt is not an error. It is a response.

When a goal attempt fails, the response explains why. It does not just say no. It returns the remaining requisites that must be satisfied for the goal to succeed. Those requisites appear as other affordances in the environment that the agent can attempt.

In effect, the environment teaches the agent how to navigate the space in order to accomplish the stated goal.

The workflow emerges from this conversation between agent and environment.

Discovery beats anticipation

Designed workflows anticipate the future. Discovered workflows reflect the present.

By attempting the ultimate goal first, GRAIL actively avoids the high-cost computational work of modeling the entire environment and calculating all possible paths toward the goal. The agent does not perform steps just in case they might be needed. It performs only the steps the environment proves are necessary.

There is no speculative progress, only verified movement.

Workflow as evidence

At the end of a successful run, humans can look back and trace a sequence of actions. That sequence looks very much like a workflow, but it was never designed. It was discovered. It may not even be a valid resolution path tomorrow if the environment changes.

In uncertain systems, GRAIL’s real-time traversals age better than design-time workflow documents.

The larger shift

GRAIL treats the world as the source of procedural knowledge. The agent’s job is not to predict what should happen, but to ask the right question first and keep asking it as conditions change.

“Don’t design workflows, discover them” reflects a shift toward systems that operate in environments too complex to script reliably, while still giving agents a practical, bounded form of autonomy and safety.

For more on the GRAIL model for autonomous agents, see my GRAIL Github repo and check out previous articles: The Binary Mind and this Linkedin post.