Is Hankweave right for you?

You have probably already done useful work with a coding agent such as Claude Code: a conversation that explored a problem, found a method, and produced a result. The question this page answers is what happens next. Some of that work deserves to be frozen into a hank – a program that can be run, resumed, and repaired – and some of it should stay interactive. The sections below give you a way to tell the difference: first the boundary between exploration and repeatable work, then a fit test, then the trade-offs you accept when you freeze a workflow, and finally the evidence that the pattern holds up in production.

Not yet? Stay with a coding agent#

If you want a one-shot agent chat, use a coding agent such as Claude Code directly. There is no need to turn an exploratory conversation into a program.

Hankweave comes after exploration, not during it. Once we have a workflow that works, we can freeze it into a hank. A hank preserves a working way of doing something; we still need to decide what that way should be. Everything else on this page is about recognizing when that preservation is worth the effort.

When a task outgrows one session#

The first signal is scale. A task horizon is the length of time or number of operations a task needs to complete productively. The bands below give a rough placement by either measure; they are not a timing formula:

Coding agents cover the ultra-short through medium horizons because a person can steer, intervene, and course-correct in real time. Hankweave targets the long horizon, where human attention cannot scale and the work must survive beyond one session.

The single-session test is blunt: if the task fits comfortably in one Claude Code session, you probably do not need Hankweave. And a long horizon is not enough by itself – repeat use, repairability, or unattended operation must matter too.

When Hankweave earns a place#

Scale alone does not justify a hank. The fit usually appears after an interactive attempt has produced something worth preserving:

1. You built something that works with a coding agent and want it to keep working. Freeze what worked so the workflow has a structured way to run and be repaired.
2. You want to share an AI capability across a team. Make the method explicit so a colleague can pick it up instead of leaving it in a few people's heads.
3. You have a complex workflow where reliability matters. A proof of concept that works most of the time needs a path toward working nearly always in production.
4. You build AI workflows for other people. The deliverable is something a client can run, maintain, and improve without you–not a conversation transcript.

One word in that list needs care. Reliability does not mean identical model output on every attempt. Model output is stochastic: it varies. Hankweave supplies control flow, checkpoints, and evidence around that output, so reliable here means repairable and receipted–backed by evidence–not repeatable bit-for-bit.

Before you freeze a workflow, run it through this gate:

Each row is a condition the work must meet for a hank to pay off. If any answer is no, keep the work interactive or use ordinary automation.

When interactive work is still better#

The gate above also explains the cases where freezing is the wrong move. We do not need to freeze every useful interaction into a hank:

• First-time exploration: You do not yet know the output shape or the intermediate steps. Use a coding agent directly.
• True one-offs: You will run the work once, get the answer, and never think about it again. Talk to the model instead.
• Constant steering: The work needs decisions every few minutes based on what the agent produces. Hankweave is designed for minimal intervention; it is infrastructure, not a conversation partner.
• High judgment-call density: A judgment call is a decision contested even among humans. If every step is one, keep a human in the loop throughout.
• Reproducibility is optional: If “it worked that one time” is good enough, the machinery is not worth it.
• Heavy browser automation, computer use, or user-interface orchestration: Hankweave runs headless–a mode without a user interface–and is not built for clicking through interfaces. Purpose-built tools are better, at least for now.

Judgment-heavy work is not automatically disqualified. Hankweave can surface judgment calls rather than silently resolve them: judgment-call (JC) blocks can present options, a tentative choice, and confidence, and exception queues can hold cases that need a person. See human-judgment patterns for ways to keep those decisions with us.

Hankweave's stated non-goals follow the same boundary: conversational UI, browser or UI orchestration, an arbitrary graph workflow engine, and parallel primary workers – unless runtime behavior changes.

We chose the quote-template-unification example workflow for low judgment-call density precisely because judgment-dense work is where Hankweave does not fit. As we build it in the tutorial, we keep that limit visible rather than pretending every workflow should become a hank.

What you trade for repeatability#

Suppose the work passes the gate. The next question is cost. Hanks take more work up front than generating an output: we work with a coding agent first, learn what actually works, and then freeze that learning into structure. That effort is the price of turning exploration into something we can use again.

The return is a known place to look when something breaks and a known place to put a new lesson. A hank is easier to debug, maintain, and improve than an unstructured conversation because the working method has a structure you can inspect.

Think of Hankweave as a track bike, not a pickup truck: a poor choice for groceries, a good one for a known course. Coding agents are the pickup trucks in this comparison. Keep them for exploration; choose a hank for a course you intend to ride again.

The maturity curve behind that note does not make model output deterministic: it remains stochastic, meaning it varies. Control flow, checkpoints, and evidence can be deterministic–fixed by the workflow and its records–so the value is repairability and named evidence, not character-for-character repetition.

What else could carry the work#

Hankweave is not the only way to run frozen AI work. Compare alternatives by capability, not by marketing category. The nearby choices are using agent tooling directly, an LLM (large language model) call framework, or a runner you build yourself.

To weigh vendor independence, copying the patterns, context control, and deployment, continue with Why Hankweave?. The order matters: first decide whether the work fits at all, then whether adding this runtime is worth it.

What you give up elsewhere#

Adopting Hankweave also changes how you inspect runs. If your team has invested in per-call tracing dashboards, you give up the dashboard's real-time click-to-trace view. In exchange you gain unified local JSONL–one JSON object per line–across agent tools and models, which you can debug with jq, a JSON-filtering tool, without locking that inspection to one vendor.

This is not a claim that tracing is unavailable. hankweave-trace shipped in 0.7.0 and uploads to Braintrust or Langfuse. The tradeoff is between a platform's per-call view and local, unified evidence, with that upload path alongside it.

The operating shape is a second trade-off. Hankweave is a batch process with a filesystem, not a daemon – a long-running background service – or a hosted service. Consider whether that shape matches how you need to operate the work; see deployment model for the details.

What runs on it in production#

The fit criteria above are not hypothetical. Southbridge's team runs Hankweave for:

• data-codebook generation: a pipeline of more than 20 codons (individual workflow steps) that runs for hours;
• plan generation for development;
• documentation writing;
• Notion-to-website migration; and
• real-time connector generation.

A public account corroborates the broader shape. Deployed hanks cover data onboarding, hygiene and cleanup, business test generation, and even comic books and slides. The planning hank is also available as a public example.

If your work sounds like one of the fit cases above, start with the quickstart. If it still needs discovery, steering, or dense human judgment, stay with the interactive tool until the shape is stable enough to freeze.