Workflows
Turn the knowledge your company already holds into repeatable work such as first-line support, triage, and candidate matching, without replacing the agents your people already use.
In short
A workflow is a saved way of doing a unit of work: take an input, apply what your agents already know, judge the answer, and return an outcome. Your people still work in Claude Code and other tools they already trust. Hyperstruck finds the right workflow for the task and brings organization-wide expertise to it.
Most companies have already invested in the hard part: the briefs, the tickets, the policies, the past conversations. That knowledge sits in documents, in claims, and in learnings earned from real work. A workflow is how you put it to use on the next similar case, instead of starting from a blank prompt every time.
It is built for work you already recognize:
- First-line support. An inbound ticket becomes a queue, an urgency, and a one-line reason a human can act on.
- Triage. A legal matter, a refund request, or an intake form is read once and routed with the context that already exists for that customer.
- Candidate matching. A CV is checked against the hiring brief the firm already filed, and the verdicts come back as Hyperstruck reported them, reasons and gaps included.
The point is the outcome, not a rigid list of steps. Traditional workflow managers ask you to spell out every branch in advance, then break when the next ticket does not match the diagram. A Hyperstruck workflow says what good looks like, which knowledge to use, and how the answer should be judged. The agents do the reasoning in between, with the learnings and claims the company already paid to build.
That is also why it is easy to reason about. You can read a workflow as: this comes in, these agents know the context, this judgment is applied, this is what comes back. You can open any run and see the input, the verdicts, and the answer. You do not have to simulate a dozen branches to know what it will do.
And it does not ask anyone to leave the tools they already use. The people doing the work stay in Claude Code, or any other MCP host. Hyperstruck sits underneath: it finds which workflow the task falls under, applies what the organization has already learned, and returns the outcome. Their agent, their editor, their tools, plus the expertise the rest of the company invested in.
With your agents
Connect Claude Code or any MCP host so the agent you already run can find and call the right workflow.
Examples
A recruiter drops a CV into Claude Code; Hyperstruck finds the match workflow, pulls the brief, and returns the verdicts.
How it all fits together
Documents, claims, learnings, agents, Insights, Workflows and Evals, and how each run makes the next one better.
Getting started
You can start from the dashboard or from the agent you already run. Nothing here replaces that agent.
From the dashboard. Open Workflows. Choose Describe a workflow and write the outcome in a sentence, for example "Decide how urgently a support ticket needs a human, and which team owns it." Hyperstruck drafts the graph and suggests starter evals such as Urgency. Review the draft, open it in the builder, and create it. Or start from a Blank canvas and add the pieces yourself.
Here is a desk that already uses them. In the last two weeks: 534 runs, none failed, three of the four judged by an eval. The catalog is candidate matching, outage escalation, and support triage. Describe a workflow and Blank canvas sit in the header.
Click Describe a workflow and you type what the workflow should decide, in one or two sentences. Example starters sit under the box. Nothing is saved until you draft it and create it in the builder.
From your agent. With the MCP server connected, ask it to draft one: "Draft a workflow that matches a candidate CV to a hiring brief." It calls draft_workflow, shows you the draft, and saves it when you agree. To run an existing one, describe the task in your own words. list_workflows with that goal finds the workflow that fits and can recall what its agents learned on earlier runs.
A workflow is only as useful as the knowledge behind it. If you have not sent documents yet, start with Documents so they become claims. If agents have already been doing the work, the learning loop is already filling in learnings. You do not have to finish either before you create a workflow; each run makes the next one sharper. How it all fits together is the map.
When to use a workflow
Use a workflow when the work repeats, the outcome is something a person can act on, and the quality of the answer depends on knowledge the company already holds.
| A good fit | A poor fit |
|---|---|
| The same kind of request arrives every day: tickets, intake, matching, routing | A one-off investigation with no expected shape |
| You already have briefs, policies, or past cases that should change the answer | There is nothing on file and no agent has done this before |
| You want a judged outcome (urgent or not, match or miss) plus a short reason | You only need a free-form chat with no decision to stand behind |
| The people doing it already work in an agent host, and you want them to apply the same bar | You want to replace those agents with a new interface of your own |
You can attach an Insight step when the outcome should include what is true right now for this customer or candidate, not only what arrived in the request. You can attach eval steps when a person will later ask "why did it say that?" and when you want those judgments to improve. Neither is required. The smallest workflow is an input and an answer.