Why we didn't build Hyperstruck on a graph
A graph is a great way to describe a process you already understand, and the wrong way to build an agent. The whole reason to reach for an agent is that you cannot specify the steps up front.
A graph might be the natural first instinct for building an agent. Graphs are cool right? They are fancy and give an organised feeling towards something that might get complicated.
What if the agent needs to do something the diagram didn't account for though? Which tends to happen almost at once. It's obvious that real tasks will branch in ways one didn't predict, and they'll turn on details that the model only figures out partway through. Each of those is one more thing the graph has to represent, and the diagram slowly stops describing the work and becomes a second thing you maintain next to it.
LangGraph (LangChain's framework for building agents as graphs) is where we think most people meet this. It is a capable tool, and graphs are the right model for a great many problems. The kind of problem an agent is handed is rarely one of them.
Graphs are a good idea
This is not a complaint about graphs themselves. A graph is definitely one of the best ways we have to describe a process you already understand. Known states and transitions, clear start and finish. Says exactly what will happen, in what order, and reliably.
Trouble certainly starts when you aim the same abstraction at an agent!
An agent's path is not knowable in advance
The whole reason to reach for an agent is that you cannot specify the steps up front. This is not subjective whatsoever. Which step comes next, whether to retry, when to change tack, when the job is actually finished - all of these things should get decided while the work happens and not before!
A graph asks for the opposite. The topology is declared before anything runs and the agent can only ever travel routes you laid down in advance.
The quiet cost
Every branch you draw is a guess about the future. The judgement that should belong to the agent now lives in control flow you wrote by hand. You're basically left with a flowchart not an agent.
It's funny that you end up doing by hand the actual reasoning the agent was meant to do.
"But modern graphs can route at runtime!"
It's a fair rebuttal, and graph frameworks have answered part of it. A node no longer has to follow a fixed edge, and it can look at the state and decide which node runs next. So the path is not fixed before the run.
But, it is still bounded beforehand. Every node the runtime router can choose has to be one you already declared. It picks from the options you wired and cannot reach for a step you never gave it. A route you left out stays a route the agent cannot take, however dynamic the choosing looks from the outside.
There is a way around that, and it quietly concedes the point. Collapse the work into a single node, let an agent run freely inside it, and the edges disappear along with the constraint. It works. But now the graph is routing nothing: you have wrapped an agent in one node and drawn a box around it, and the dynamism you needed lives in the one place the graph doesn't reach.
Hyperstruck instead
Hyperstruck doesn't ask you to draw a map. You hand it the goal and it works out how to get there as it goes. It stops when the job is genuinely done rather than when it lands on a node labelled "end". The shape of the run is reliably discovered during the run and there is no diagram to keep in sync, because there was never a diagram.
There is less to write and far less to guess at, because you describe what finished looks like rather than the forty ways the work might reach it. Hyperstruck is intelligent.
"But I want control"
The fair objection, and probably the real reason teams reach for graphs is visibility. You can see a graph, step through it, point at exactly where a decision is made. In a regulated setting or anywhere a wrong move is expensive, that sounds important.
If you give up the graph it feels like you give up control. But you don't!
Control does not have to come from pre-wiring every transition in a graph. The better way to do control is letting you decide where a human signs off (human-in-the-loop, which is a first-class citizen in Hyperstruck). The agent handles everything in between, and when something goes wrong it corrects course on its own. What it learns on one run carries into the next. You keep the audit trail and the intervention points without hand-drawing the route to reach them.
The shift
Oversight stops being something you wire into every step and becomes something you place where it counts.
When a graph is still the right call
If your problem really is a fixed pipeline, reach for a graph, which is exactly what they are good at. The claim was never that graphs are bad. It is narrower, and we think harder to argue with: the work an intelligent agent does is not a pipeline, so it certainly should not be modelled as one.