How it all fits together
Documents become claims, work becomes learnings, agents use both. Insights notice what to do, Workflows do the work, Evals judge and improve. Each run feeds the next.
In short
Hyperstruck is one compounding system, not three new products bolted on. You send what the company already knows. Agents keep it as claims and learnings. Insights watch for what to do next. Workflows do a unit of work to a judged outcome. Evals make those judgments sharper on real cases. The next run is better than the last because of it.
If you already read Memory, you know the split: claims for what is true, learnings for what to do. Insights, Workflows and Evals are how that shows up in the work.
Knowledge: documents become claims
You send documents: briefs, tickets, meeting notes, contracts, records from your own systems. Hyperstruck reads them and files each specific detail as a claim: this company, this salary band, this account manager, this outage, dated and sourced.
That is the knowledge the company already invested in, in a form an agent can trust instead of re-reading a pile of files. When a recruiter's workflow needs Juniper Labs' hiring brief, it looks up claims, not last week's paste into a prompt. When a support workflow needs prior incidents, those outages are claims with sources.
Claims stay current. A newer brief ends the old salary band. A conflict waits for a person. When sources disagree is the page for that.
Learnings: what worked, not what is true
A learning is a short, conditional rule earned from real work: when a refund was already issued, do not issue it again. It is not a fact about one customer. Those belong with claims.
Learnings accrue through the learning loop: resolve before the work, observe when it finishes. A workflow has its own agent, so runs of this workflow earn learnings that come back the next time someone hits the same kind of case. list_workflows with a goal can recall those for the caller, so even an agent that has never seen your playbook starts from what the last runs taught.
Agents
An agent is who those records belong to: a support desk, a client desk, a workflow named support-ticket-triage. People and other agents talk to them through the dashboard, MCP, or REST.
You do not replace the agent someone already runs in Claude Code. You give that agent access to these ones: the catalog of workflows, the claims on the client desk, the learnings from last week's triage. With your agents is that contract.
Insights: proactive
Once agents have knowledge, they can do more than wait for a request. An Insight watches, gathers what it needs from the agents that hold it, and produces a ranked list of what to do now, with the reasoning a person can read.
Examples you can picture:
- GTM intelligence. A recruiting agency wants to know when a company is coming into the market, early enough to offer a partnership, not after the news is everywhere.
- Proactive outage outreach. The same account has had two failures this month. Contact them before they open the third ticket.
Insights are the proactive tier. They run on a schedule or on demand, and they talk across agents to satisfy an intent: the network desk knows the node, the support desk knows the household, the Insight ranks who to call and why.
The feed is that ranked list. Here, Candidate rediscovery has already asked the client desk and the conversations agent, and put Amelia Chen at the top for Juniper Labs' Founding CTO, with cited claims from those agents. The same finding is what a match workflow can read as an insight step.
A workflow can use an Insight as a step, so a reactive case (this ticket, this CV) still gets the proactive context (prior outages, latest conversation). The workflow fills in the Insight's objective from this request and reads the findings downstream. It is the same Insight you already run, not a copy.
Workflows: do the work
A workflow is the reactive counterpart: someone (or their agent) has a case, and you want a consistent, judged outcome that uses the knowledge above.
That is first-line support, triage, candidate matching. Not a rigid step list. An outcome, plus the intelligence the company already paid for. Workflows is the overview; examples is a CV dropped into Claude Code.
Evals: judge and improve
An eval is a judgment attached to a workflow: urgency, routing, must-have skills, overall match. It is how the system produces a decision a person can stand behind, not only a paragraph of prose.
Evals get better on your data:
- Real runs land in the run log, with the evaluator's verdict on each case.
- When a person disagrees, they correct the verdict. That correction is the label.
- The review queue holds the cases worth a human look. This is
must_havesoncandidate-company-match: Amelia Chen's skills, location, seniority and Juniper Labs on the input. The evaluator's met sits next to keys to label met, partial or missing. A correction here is the label the next training job sees.
- You train a finer judgment on that mix of run data and human labels, tuned to nuances the starter eval never saw: your meaning of "urgent", your founding-level seniority band.
- Before it goes live on the workflow, you compare it with the old judge on the same runs. Deltas are visible. You roll it out when it is safer, not because a single demo looked good.
That loop is why workflows and evals belong together. A workflow without evals still answers. A workflow with evals can be told when it was wrong, and can get less wrong without anyone rewriting a tree of branches.
How each run feeds the next
Take the recruiter's CV match as one pass around the diagram.
| This run | What it writes forward |
|---|---|
| The CV and the brief already sat in documents and claims | The agent does not re-type the salary band |
run_workflow judges must-haves, seniority, overall match | Verdicts and the answer land in the run log |
| An Insight step cites the latest conversation | That conversation was itself a document that became claims |
| A person corrects seniority | The next training set has a better label |
| The workflow agent completes the loop | Learnings about this kind of match are offered next time |
Nothing here is a one-shot automation. The first run is useful because of data you already had. The tenth is useful because of the nine in between. That is the same compounding Learning describes for a single agent, widened to a desk that triages, matches, and follows up.
Where to go next
Workflows
Why they exist, how to start, and the questions people ask first.
Documents
Send the briefs and tickets that become claims.
Insights
Proactive: ranked findings of what to do now, before anyone has to ask.
Evals
Judge real workflow runs, then improve the judgment on your data.
Learning loop
Resolve before the work, observe after it.