Agents do the work. People approve the merge.
Give HyperFlow a repository and a short note describing the change you want. It works out the tasks, does the job in a throwaway checkout, puts a second agent on reviewing it, and then stops. Nothing reaches your branches until somebody reads the proposal and approves it. There is one going through right now.
Built by Zehntech, and used inside Zehntech.
Real work, with a person at the gate
You write it in markdown
A heading, a line or two about what you want, and the repositories it applies to. In short, that is the entire input. No pipeline file, no YAML, nothing to learn.
It plans first, and shows you
A model works out the tasks and what each one needs. HyperFlow checks that plan against a schema and throws out anything that does not fit. Then you read it before a single task runs.
The agent cannot reach your remote
Work happens in a disposable checkout cloned from a local mirror. There is no network route out to GitHub from inside it. An agent told to push simply cannot.
A second agent reviews it
Different agent, fresh context, no stake in the first one being right. It flags what it finds, the original agent fixes it, then it is reviewed again. You see the change after that loop, not before.
Then it stops and waits
What comes out of HyperFlow is a merge proposal: the commit, the files touched, the diff. No branch is pushed and no pull request exists until someone approves it and says why.
Ten repositories, one approval
The same change across a set of repositories, decided once. You cannot approve three and leave the rest, because a change applied to half your estate is worse than not doing it.
Four steps from a sentence to a pull request
Write down what you want
Markdown. A heading and a requirement. Then point it at one repository or name several.
Read the plan, then approve it
It lists the tasks, the order they run in, and what each agent is allowed to touch. If it has misread you, reject it. Nothing has run yet.
Leave it to work
Write, review, fix, review again. Every step is logged with the tokens it burned and what that cost.
Decide on the merge
Read the proposal, give a reason, approve or reject. Approving is the thing that pushes the branch and opens the pull request. Nothing else does.
Why we built HyperFlow
Our engineers use coding agents every day and the output is good. Accounting for it afterwards was the hard part. What was this agent allowed to do? Also, what else did it try? And what did it cost, and who said yes? The usual workaround is to keep agents in a sandbox and copy their work out by hand, which throws away most of the reason for using them. So we built the piece that was missing. In HyperFlow the limits sit in the platform rather than in the prompt, which means they hold whether or not the model feels like cooperating.
What HyperFlow is not
Not a chat window
There is nothing to converse with. You write a specification and you read a pull request.
Not an autonomous developer
Every run halts at a human decision before anything leaves the platform. That is the design, not a limitation we plan to remove.
Not a hosted service
It runs on your infrastructure, against your own model credentials. Also, there is no sign-up page.
Not a substitute for review
It produces a pull request. However, somebody on your team still has to read it.
Common questions
Can an agent merge to main?
No. A merge step produces a proposal and waits for somebody with the right role to decide. Branches like main, master and release are protected out of the box, and the agent has no push credential to begin with.
Which models does HyperFlow use?
Claude, either through the Claude Code CLI signed in with your own account, or over HTTP against the Anthropic API. OpenRouter works too if you would rather route it that way. Models are set per task, so review can run on something stronger than drafting.
What does a change cost?
You pay your own model bill and nothing to us per seat. A small change on a small repository comes to a dollar or two. In other words, cost follows how much context each stage has to read, so it grows with the size of the repository rather than the size of the change.
Where does HyperFlow run?
On your infrastructure, against your own credentials. There is no hosted version today.
What stops it doing something we did not ask for?
A new project cannot run a single command or reach a single host until you add them. Budgets for cost, tokens and runtime pause a run rather than letting it drift. Policy is frozen when a run starts, so editing settings mid-flight changes nothing retrospectively. And if it still gets it wrong, you reject the merge and nothing was pushed.
Does it work with private repositories?
Yes. Credentials are encrypted at rest and write-only: once saved they are never sent back to a browser, including yours. Also, one credential can serve every project, or a project can override it.