The runtime that has to prove a run succeeded
Give it a goal. It plans, executes, recovers from failures, and has to prove the result against what its tools observed before it can claim success. What earlier runs learned is built into all of it.
The plan, before it runs
Run month-end collections
Milestone 1 · Establish position
added by a lesson
Milestone 2 · Collect
Decomposed, annotated and validated before a single tool fires. Everything marked came from runs that already happened.
One goal in, one proven answer out
Deciding the steps, recovering on its own when one breaks, proving the result before it can claim success: that is the run, not glue you write around a model. Watch one play out, including the part that breaks.
Run month-end collections
decide
Plan
scored before a single tool fires
execute & recover
It breaks, then fixes itself
a step fails mid-run
the gate · prove
Prove
every claim checked against what the tools saw
success it can prove
You wrote none of this: no retry loops, no result-checking. The runtime made every decision above.
It won't claim success it can't prove
The worst agent failure is invisible: the agent reports success in confident language, and the work did not happen.
At the point the run would report success
“All 12 overdue accounts have been chased and the reminders sent successfully.”
no observation supports this
The run’s output could not be verified against the tool observations, so it was not reported as successful.
At the point a run would report success, Hyperstruck Engine checks every claim in the answer against what the tools actually observed. A claim nothing observed ends the run. So does success wrapped around an admitted failure. No language model sits in this path, deliberately: a model asked to check another model tends to agree with it.
A refused run comes back with success false, a machine-readable reason, and the raw output preserved.
More on the failure that actually costs you: Stopping agents from reporting false success
What your framework does, and where it stops
Frameworks give you the wiring: a graph, state, streaming, retries. What they do not give you is a runtime that checks the work. Here is what goes wrong once an agent does the same job every week.
It reports done when it is not
On Hyperstruck Engine
A completion gate scores the answer against the run’s own observations and refuses to report success it cannot ground.
On a framework
The run returns what the model wrote. Nothing checks that claim against what the tools actually observed.
It redoes work you already accepted
On Hyperstruck Engine
Before a write, destructive or external tool fires, the executor checks whether that exact call already succeeded and returns the earlier result instead.
On a framework
A retry re-runs the step. If that step sent a message or moved money, it happens again.
It repeats the mistake you corrected
On Hyperstruck Engine
Lessons earned from real runs compile into the plan before it runs, and the plan is scored on whether it followed them.
On a framework
Standing rules live in a file the model may honor or may not.
The rules do not survive delegation
On Hyperstruck Engine
Child agents run in scoped contexts carrying the parent’s experience, each with its own memory namespace.
On a framework
Subagents do not reliably inherit the parent’s instructions.
You cannot put a bad run back
On Hyperstruck Engine
Rewind to an earlier milestone through an audited decision, with the side effects since that point disclosed before you commit.
On a framework
Recovering means running it again from the start.
A paused run replays on resume
On Hyperstruck Engine
A suspended run continues from the exact point it stopped, with full state restored, so work never repeats.
On a framework
Resume re-runs the node from its start, so the work before the pause repeats unless you guard every side effect by hand.
| What goes wrong | On Hyperstruck Engine | On a framework |
|---|---|---|
| It reports done when it is not | A completion gate scores the answer against the run’s own observations and refuses to report success it cannot ground. | The run returns what the model wrote. Nothing checks that claim against what the tools actually observed. |
| It redoes work you already accepted | Before a write, destructive or external tool fires, the executor checks whether that exact call already succeeded and returns the earlier result instead. | A retry re-runs the step. If that step sent a message or moved money, it happens again. |
| It repeats the mistake you corrected | Lessons earned from real runs compile into the plan before it runs, and the plan is scored on whether it followed them. | Standing rules live in a file the model may honor or may not. |
| The rules do not survive delegation | Child agents run in scoped contexts carrying the parent’s experience, each with its own memory namespace. | Subagents do not reliably inherit the parent’s instructions. |
| You cannot put a bad run back | Rewind to an earlier milestone through an audited decision, with the side effects since that point disclosed before you commit. | Recovering means running it again from the start. |
| A paused run replays on resume | A suspended run continues from the exact point it stopped, with full state restored, so work never repeats. | Resume re-runs the node from its start, so the work before the pause repeats unless you guard every side effect by hand. |
Already running one of these and it fits? See the FAQ for how Hyperstruck works alongside a framework you keep.
More on why the graph is the wrong shape: Why we didn't build Hyperstruck on a graph
You can un-run it
Durable execution systems let you resume a run. Fewer let you un-run one.
You un-run the run, not the world. A sent email, a committed write, a charge on a card cannot be taken back, and Hyperstruck Engine never pretends otherwise.
It rewinds the run’s state to an earlier milestone and puts every side-effecting step since that point in front of you before you commit, so you decide with the irreversible actions in view. None of them fire a second time on the way back, and the rewind reaches into delegated children too, so the whole tree lands on one consistent point.
It is a governed decision: recorded, and the run keeps its full history.
Suspended · rewind requested
→ Milestone 1 · Establish position
Side-effecting steps since that point
Recorded as a governed decision. The run keeps its full history either way.
Resume costs nothing twice
A resumed run continues from the suspension point rather than replaying the work before it.
The record and the state are different things
Approvals and traces are the record: long-lived and exportable. Checkpoints are state: resumable, and deletable when you are done with them. A checkpoint is never the system of record.
Durability is opt-in and takes a store. Step-level durability is on by default on hosted and a deliberate choice when you self-host.
A human, wherever it matters
Put a person at any of six points in a run, plan, milestone, step, tool, escalation, or a delegated child. Hyperstruck Engine suspends with a typed picture of what it is about to do, waits for approve, reject, or edit, then resumes from that exact point. Gates fire by rule, so you review what matters, not everything.
And it earns slack as it proves itself: approve the same kind of call enough times and that gate starts auto-approving, and the trust lapses if the agent goes idle.
Human in the loop
About to email Matthew Wilson, $2,400 overdue. Nothing sends until you say so.
Earns auto-approval
↓ decays after idle · then it asks again
Six places to put a human
Plan, milestone, step, tool, escalation, and a delegated child’s gates. All opt-in: configure none and it never pauses.
Gates that fire by rule
Key a gate off a tool’s category, a confidence floor, a step budget, or a predicate you write, so it pauses on what warrants a person.
Trust it earns, and can lose
Enough approvals and a gate starts auto-approving; idle time lets that trust decay. Autonomy levels set the starting posture.
The rules survive the handoff
Instruction files stop at the boundary: hand work to a subagent and the parent’s rules may never arrive. On Hyperstruck Engine, a child agent runs in a scoped context carrying the parent’s experience, its approvals bubble up to the parent, and a suspended delegation tree resumes as one consistent picture.
It is opt-in. If you never pass an agent factory, none of it is constructed and you pay nothing for it.
More on why a rules file isn't enforcement: You already wrote the rule down
And it gets better at your work
Everything above describes run one. Because Hyperstruck Engine owns the plan, experience is not read to the model as advice: it is compiled into the structure of the work before the work starts.
Compiled into the tools
Lessons that have proved themselves become annotations on the tools they apply to, and the planner reads them the way it reads a tool’s own documentation. Others become constraints the plan has to respect.
Scored before anything runs
The plan is checked against what the agent already knows, and a plan that ignores a well-evidenced lesson can be sent back to be rewritten. Nothing has executed yet.
Gates derived from what happened
When a run wastes its time on work that was never going to succeed, code, not a model, derives the condition from the trace. Next time, the steps that match it are skipped before they start. If the evidence is not there, the work simply runs as normal.
More on what makes a learning a learning: What are learnings?
Check the setup, then dispatch a goal
You do not choose models. Every reasoning component runs a model benchmarked for its job, pinned, and the runtime checks your whole setup up front instead of failing halfway through your first run.
pip install hyperstruck-core
hyperstruck doctoragent = create_agent(
AgentConfig(
name="Collections",
instructions="You work through collections tasks using the available tools.",
)
)
agent.register_tool(fetch_overdue)
agent.register_tool(send_reminder)
result = await agent.run(goal="Run month-end collections")
result.success # True only when the completion gate could ground it
result.is_quality_passed # final reflection's verdict on the work itself
result.incomplete_reason # machine-readable on refusal, e.g. UNGROUNDED_CLAIMAccess is gated while we onboard teams directly. Ask, and we will set you up.
Hosted, or in your own environment
Run it hosted, or self-host the whole stack in your own Kubernetes environment. Enterprise deployments come with licensing and dedicated support.
Questions engineers ask first
No, and we would rather you did not if it is working. The Hyperstruck layer plugs in underneath LangGraph, CrewAI, the OpenAI Agents SDK, Claude Code and Cursor, and your agents start earning and acting on experience without anything being ripped out. Hyperstruck Engine is for teams starting fresh, or who want one system rather than assembled parts.
Each reasoning component is pinned to a model chosen by benchmark for that job, with the output mode and reasoning effort pinned alongside it. There is no fallback: if a pinned model’s provider key is missing, that component tells you rather than quietly running on something else, because the prompts are tuned to the pin.
Experience is resolved once for the run and refreshed at milestone boundaries, not queried per decision. What is in force at each decision is already in hand.
Yes. Memory and knowledge services are passed in when you want them. A reasoning run needs neither, and the runtime ships mocks so you can build and test your own code against it with no containers, no keys and no spend.
It lets the run through. The gate is a floor, not a guarantee: it exists to stop the failures it can prove, and when it cannot check a claim it does not block your work on a guess. A refused run always carries a machine-readable reason alongside the preserved raw output.
Not unless you ask it to. Human-in-the-loop gates are entirely opt-in: configure none and the runtime never suspends. When you do turn them on, you choose which gates and which policies.
Rewind does not reverse them, and Hyperstruck Engine never claims to. It rewinds the run’s state to an earlier milestone and discloses every side-effecting step taken since then, so you decide with the irreversible actions in front of you. On the way back those committed steps replay from the record rather than firing again, so a recovery never double-sends or double-charges. You un-run the run, not the world.
Yes, including the full stack in your own environment. Hosted is the fastest way to start; self-hosted is available with enterprise licensing and support.
Build on a runtime that proves its work
Hyperstruck Engine is built for teams whose agents do the same kind of work over and over, and it gets better at yours with every run. Tell us what your agents do and we will set you up with a key.