A fast step off the critical path is wasted effort
Tuning usually goes to whichever step is easiest to see, not the chain that's actually setting the total time. Reading the graph is what tells the two apart.
The workflow's real shape, not the order it happened to be written in.
A multi-step agent run usually gets built as one script, even when it's really a set of nodes and edges. Graph Engineering does for a workflow's shape what Loop Engineering does for whether it should exist at all: sees every one, prices what the shape costs, optimises what's already there, and recommends the graph you should be running instead.
Workflow graphs · last 7 days
Graphs mapped
46
Cost added by shape
18%
Restructures recommended
6
Spec-to-PR draft64%
Nightly test repair38%
Dependency upgrade22%
Share of each workflow's steps that don't actually have to wait
What changes in a workflow's shape.
Today
- A workflow's shape is invisible — you can see the script, not the graph
- A serial shape is paid for in wait time and duplicated work, and nothing prices the shape itself
- The fix for a slow workflow is always 'speed up a step', because nobody proposes a different shape
With Tetriz
- The graph mapped from how every workflow actually runs, node by node
- What the current shape costs, split out from what any single step costs
- A better graph recommended outright, not just the current one tuned
How a script becomes a graph, gets priced, and gets a better shape recommended.
The same four moves Loop Engineering applies to whether a run is worth having, applied here to how it's wired.
See the graph as it actually runs
A workflow's steps are usually documented as a sequence, but a sequence isn't a dependency — and nothing today tells you which edges are real and which are just the order it was written in.
What Tetriz does here
- Every node and every real edge
What state each step actually passed to the next, read from the run itself rather than the workflow's original design.
- Habit told apart from dependency
A step that never reads what came before it is free to move, whatever position it was written in.
Mapped workflow graphs
| Workflow | Steps | Real edges |
|---|---|---|
| Spec-to-PR draft | 9 | 5 |
| Nightly test repair | 6 | 4 |
| Dependency upgrade | 5 | 5 |
See what the shape costs
A workflow shaped as one long chain pays for it twice — once in the wait between steps, once in whatever gets redundantly repeated — and nothing today prices the shape separately from the steps themselves.
What Tetriz does here
- Cost split from the work
What the wiring is costing, apart from what any single step costs to run.
- Named per workflow
So a workflow that's expensive because of its shape is a different fix from one that's expensive because of its model tier.
Cost added by graph shape
| Workflow | Cost from shape | Share of total |
|---|---|---|
| Spec-to-PR draft | $1.42 | 31% |
| Nightly test repair | $0.18 | 14% |
| Dependency upgrade | $0.09 | 5% |
Run what doesn't have to wait
Every step held in a queue behind one it doesn't depend on is wall-clock time nobody chose to spend, and the chain that's actually setting the total is rarely the step anyone is looking at.
What Tetriz does here
- Independent steps freed to run together
Steps with no edge between them run at the same time instead of taking turns.
- The critical path named, not guessed
The one chain of edges that determines total run time — so effort goes to the chain that moves it, not the step that's easiest to see.
Parallelisation impact
Wall-clock
-46%
Run in parallel
41%
Cost
±0%
Recommend the graph you should be running
The bigger fix for a slow or expensive workflow is usually not a faster step, it's a different shape — fewer steps, a different split across nodes — and that redesign is the part nobody has time to sit down and propose.
What Tetriz does here
- New shapes proposed from what worked elsewhere
A restructure that fixed the same bottleneck in one workflow becomes a proposal for every workflow shaped like it.
- Approved before it changes anything
An admin accepts or edits each proposed shape, same as any other recommendation Tetriz makes.
Recommended restructures
| Workflow | Current shape | Recommended |
|---|---|---|
| Spec-to-PR draft | 9 steps, 1 chain | 3 branches + 1 gate |
| Nightly test repair | 6 steps, 1 chain | 2 branches |
Why a new shape beats a faster old one.
Three reasons the bigger win is in the graph, not in any one step of it.
Most of a workflow's order is accidental
A script written top to bottom looks sequential by default. The dependency is the exception, not the rule — most of what looks like an edge is just the order someone typed it in.
And tuning a chain has a ceiling a new shape doesn't
Speeding up the steps in a bad shape only ever gets you a faster version of the same bad shape. The larger gains sit in fewer steps or a different split across them — a redesign, not a tweak.
Questions leaders ask about Graph Engineering.
Loop Engineering is whether a run is worth having at all, and what it costs. Graph Engineering is the shape of one run once you've decided to have it — what that shape costs, which steps can happen at once, and what shape you should run instead.
Drawn from restructures that fixed the same bottleneck elsewhere in your org. A shape is only proposed if a workflow wired like it already improved somewhere you run it.
No. The graph and its cost are read from how a workflow already runs. A recommended restructure is a proposal, not a rebuild forced on you.
One step reading state that an earlier step actually produced. Everything else is sequencing left over from the order the workflow was written in — and that's usually the part free to move.
It names what could run in parallel, what that would save, and what shape would capture more of it. Whether to wire it up is your call.