The graph is the behavior

Status. Nothing in this post is live today. Every capability described here is Planned: designed, not built yet.

A workflow in Linestop is a graph of steps. Our rule is that the graph is the behavior. Nothing sits above it deciding what happens.

If the author places an agent step, the agent acts. If the author places a human step, a person acts. There is no default behavior underneath.

What we took out (Planned)

An earlier design kept a built-in approval step and made human approval the default. We removed that from the design. As organizations evolve and LLMs continue to get better, we believe that the “always get human approval” mindset will invariably decline and don’t want to force users into that workflow.

There’s a second reason. Behavior that a reviewer can’t see in the graph is behavior nobody can reason about. If you want a person to check something, you place a step. If you trust an agent, you delete the step.

Take a pull request review workflow. An agent reviews the pull request and stores its findings. A separate step publishes them as a comment. If you want a person to read the findings first, you add a human step between the two. Nothing else adds that step for you.

Where governance lives (Planned)

Moving the rules into the graph doesn’t mean there are no controls. It means each control is a setting that someone chose, that is visible, and that a reviewer can check without reading code. We’re building these:

• Who may publish a workflow. Publishing is a permission, and not everyone holds it.
• Which actions each connection may perform. An administrator enables an action such as “merge pull requests” on a GitHub connection, or doesn’t. Publishing a workflow that uses an action that isn’t enabled is refused. If an action is disabled later, it fails and can be retried. Each change to a connection’s enabled actions is recorded.
• Which tools an agent may use. The agent’s own definition lists them.
• Budgets. Each workflow can set a budget per run, and the model connection has an approximate monthly cap.
• A record of what happened. A run timeline, an audit trail and an effects report attribute each step and effect to a person, an agent or a connection.

What this costs you

Anyone who can publish can change the graph. That includes removing a review step. That is the point of the design, and it is also why publish rights matter.

The publish boundary is not finished. We’re working on a more precise split: ordinary changes made by developers inside a delegated scope, and a higher level of permission for giving an agent more authority or changing a sensitive step. We haven’t designed the keys and publish identity for that yet.

We also know this choice has a limit. If a design partner’s security review insists on a review that the platform enforces and that workflow authors can’t remove, we’ll revisit this decision.

This is not a security claim. We hold no security certifications and haven’t had a penetration test completed. The security page lists what we plan and what we haven’t done.

What is live, prototype and planned