Workflows or agents? When to use each — and why you shouldn't have to choose

Pick a lane, the advice goes. Either you adopt a visual workflow builder and wire your steps by hand, or you hand the whole problem to an agent framework and let a model figure it out. The tooling reinforces the split — workflow products and agent products rarely live under one roof, so the market makes it feel like a categorical decision.

It isn't. Workflows and agents are two ends of one spectrum, not rival camps. The useful question is never "which is better." It's: how much of this job has a known path, and how much gets discovered at runtime? Answer that and the choice usually makes itself — and the most robust solutions answer it more than once, because they use both.

The real distinction: known path vs. discovered path

A workflow fits when you already know the path. The steps are fixed, the order is fixed, and you wire them once. Same input takes the same route and produces the same result. You're buying three things: determinism (it's predictable), traceability (the graph is the spec — you can read it and know exactly what will happen), and speed (no model has to deliberate about what to do next). Document processing, retrieval-augmented generation, scheduled data extraction, format conversion — anything where the procedure is stable — belongs here.

An agent fits when the path is discovered at runtime. The model decides the next step from what it learned in the last one. It branches, loops, retries, and calls tools in an order you didn't pre-wire, because the right order depends on intermediate findings you couldn't know in advance. You trade some determinism for reasoning. Open-ended research, adaptive decisions, multi-step problem-solving where step five depends on what step three turned up — that's agent territory.

The trade-off underneath is determinism vs. adaptability. A workflow is easier to test, cheaper to run, and trivial to audit. An agent is more capable on ambiguous work but harder to predict and more expensive per run — every step may be a model call. Neither property is "better." They're the right answer to different shapes of problem.

A heuristic you can actually use

Lay the same job against both and the fit is usually obvious:

If you want a faster gut-check, ask four questions about the task:

• Can I draw the steps in advance? If yes, lean workflow.
• Does the next step depend on reasoning over the last one's output? If yes, lean agent.
• Do I need the same input to produce the same output every time? If yes, workflow — determinism is a feature you lose the moment a model picks the route.
• Is the hard part the exceptions, not the happy path? That's the tell that you want both.

The real answer: use both

Here's what the "pick a lane" framing misses. The boundary between structured and autonomous isn't drawn once per project — it's a design decision you make per sub-problem. Production solutions tend to be mostly deterministic with reasoning where it earns its keep.

Two patterns show up again and again.

A workflow that escalates to an agent. You build a deterministic document pipeline — ingest, extract, classify, route. It handles the overwhelming majority of inputs fast, cheaply, and identically every time. But a fraction of documents don't fit the rules: an ambiguous contract clause, a malformed table, a field the classifier can't place with confidence. Instead of failing or guessing, the workflow hands that one case to a reasoning agent, which investigates and returns a decision. The common path stays cheap and auditable; the model is spent only where ambiguity actually lives. (Start from the Document Q&A or Vector Store RAG templates to see the structured half wired up.)

An agent that calls a workflow as a sub-task. Invert it. A research agent is working an open-ended question and, mid-investigation, needs clean structured data pulled from a batch of PDFs. It doesn't reason its way through the extraction token by token — it calls a deterministic extraction workflow as a tool, gets back well-formed structured output, and resumes reasoning with reliable inputs. The agent owns the discovered path; the workflow owns the known one. The Sequential Agent template is a good starting point for the autonomous half.

In both patterns the win is the same: you spend determinism where the path is known and reasoning where it isn't, instead of forcing one tool to do a job it's the wrong shape for.

Where this is today — honestly

MachineCraft is built as two engines under one platform, which is what makes the patterns above a configuration choice rather than an integration project.

• The Workflow Engine ships today — a visual builder with code extensibility, 100+ components, and 18 model providers behind a single credential layer. This is the structured half: drag the path, run it, read it back.
• The Agent Engine BETA brings production-grade agent orchestration — the branching, loops, and tool-calling that autonomous work needs. It's in beta; we label it as beta rather than imply it's done.
• HITL approval gates BETA sit on top of both. Mark any node an approval gate and execution pauses for a human to inspect state and approve, reject, or modify before it proceeds — the natural place to put a person on the agent's escalated edge case. Also beta.

Because design and runtime are separated, the same hybrid solution moves from cloud to private cloud to air-gapped with env-var-only differences — see build once, deploy anywhere. And when the work runs in a regulated environment, the audit trail plus those approval gates are what let a compliance owner sign off — more on that in shipping AI agents in regulated environments.

The takeaway

Stop treating "workflow or agent" as a stance. It's a per-task fit decision, and the strongest systems answer it many times over — a deterministic spine with reasoning grafted in exactly where the path stops being knowable. Pick the engine that matches the shape of each sub-problem. When the shapes are mixed, use both.