Show It Once or Build the Workflow: Which Wins When

Demonstration learning has reached mainstream automation: instead of building a workflow node by node, you show an agent the job once and it persists what it watched as a repeatable routine. xAI’s Grok Bot calls this Teach a task, and its documentation is unusually concrete about the boundary — a capture records up to ten minutes of visible computer interaction, and the learned skill is explicitly a draft. The question for CRM and operations teams is no longer whether this works. It is when demonstration beats an explicitly built workflow — and when it doesn’t.

The stakes are governance, not novelty. Explicit workflow builders — n8n, Zapier, Make — publish documented version or change-log histories, run logs, restore or export paths and, in Zapier’s case, an account-wide audit log. For demonstration-captured routines, nothing equivalent is documented on the vendor pages we fetched: no diff between two versions of a routine, no named versions, no account-wide change log. When an automation touches a revenue system, that gap decides more than the capture speed does.

This is a paradigm-fit guide, not a cost comparison — we already published the cost and build-time math in Claude Code Routines vs n8n and Zapier: Real Costs. Here we cover how demonstration capture actually works and where its documented limits sit, what the explicit builders publish that it doesn’t, what the record-and-replay era of RPA teaches about the failure mode, and a decision framework for choosing — or combining — the two paradigms.

Every business automation starts as knowledge in someone’s head. The two paradigms differ in how that knowledge gets out. An explicit builder makes a person translate it into structure — triggers, steps, branches, failure paths — before anything runs. Demonstration capture skips the translation: the person performs the job once while an agent watches, and the system infers the routine from the performance.

A useful analogy is prompt length. The explicit builder is the long prompt: high setup cost, high precision, and it only works if you already know the process well enough to specify it. Demonstration capture is the short prompt: low setup cost, but it delegates judgment to the system about what mattered in what it watched. Neither dominates. The choice depends on whether the process is already known and stable enough to specify — and on who will need to inspect it later.

Demonstration capture is not one vendor’s idea. We reviewed two earlier implementations — Claude Cowork’s Record a Skill and OpenAI Codex’s Record & Replay — in our feature-level comparison of the two, and this article won’t retell that story. Here the working example is the newest entrant, Grok Bot’s Teach a task, because its published limits are the most concrete we found while researching this piece — which makes it a useful lens on the paradigm itself.

Grok Bot launched in beta on August 11, 2026 — we covered the launch itself in our companion piece on Grok Bot’s AI teammates — and its skills-and-routines documentation describes the demonstration mechanic plainly: Bots learn workflows from live demonstration. You ask a Bot to follow along once through a multi-step or multi-system path; it persists that path as a routine and can re-run it on a schedule or on demand.

The limits are what make this vendor’s docs valuable for the paradigm question. Teaching records visible computer interaction for up to ten minutes, and it explicitly does not record microphone audio. That ten-minute cap is the most concrete, checkable limit we found anywhere in the demonstration-capture category while researching this piece — most record-and-replay features we have looked at publish no time boundary at all.

Just as telling: the vendor does not pretend the capture is a finished automation. In the docs’ own framing, “the learned skill is a draft” — one that needs human refinement of decision rules, failure handling and approval boundaries that are “not evident from a single example.” That sentence is the honest core of the whole paradigm. A demonstration captures the happy path a human happened to walk that day, not the decision tree for every case that could occur.

Once captured, routines are managed from a Routines panel: they can be enabled or paused, have their schedule or instructions edited, and be run as a test. Scheduling supports time-based triggers — every weekday at 8:00am, with a timezone — and event-based triggers from integrations such as Slack or GitHub. Background routines can run while the user’s laptop is closed. A single Bot supports up to 50 routines, and the panel retains the 20 most recent run records for each routine.

The explicit builders’ counter-argument isn’t speed — it’s paper trail. Each of the three major platforms documents, as a product feature, exactly the things a demonstration-captured routine currently lacks.

n8n keeps a workflow history where a new version is created every time you save the workflow, restore an old version, or pull from Git via source control — though “changes to workflow settings do not create a new version.” Versions and executions are distinct concepts: versions are configurations, executions are individual runs of the current version. You can restore a prior version, clone one into a new workflow, compare versions side by side, or download a version as JSON. Retention is plan-based — full history on Enterprise, the last 5 days on Cloud Pro, the last 24 hours for everyone else — and named versions on Pro and Enterprise are protected from automatic pruning, persisting indefinitely.

Zapier uses a draft-and-publish model: you edit in a draft while the live Zap keeps running, and publishing turns that draft into a permanent, numbered version. A published Zap is read-only until a new draft is created, and only one draft can exist at a time. Every entry in Zap history shows the exact version used for that run, and history is searchable by version. Run data is retained for a maximum of 60 days and up to 10,000 runs regardless of plan — separate from version retention, which scales from none on Free through 1 month on Professional and 6 months on Team to 1 year on Enterprise. Zapier’s help center also describes an account-wide audit log on Team and Enterprise plans that records account-level Zap events with who and when, for admins monitoring business-critical Zaps.

Make frames the same idea as scenario history: run entries capture date, trigger type, status, duration, operations completed, credits consumed and transferred-data size, while separate change-log entries record user actions — scheduling changes, scenario edits, activation. Retention of history entries is plan-dependent (Make’s docs defer to its pricing page rather than stating day counts inline). Full-text execution-log search on Pro plans and higher lets you find any term inside module outputs across past runs, and history can be exported to CSV including status, timestamp, author, operations count and duration — exportable evidence, which matters for audits.

The table below is the paradigm comparison that matters — not features against features, but what each vendor’s documentation publishes about inspecting and reversing change. Where a Grok Bot cell reads “not documented,” the claim is narrowed to the docs.x.ai pages we fetched at the time of writing: a capability may exist unpublished, but nothing published claims one.

Here is the analytical frame we keep coming back to: a reviewer — human or agent — can only correct what it can inspect. An n8n workflow is a graph of nodes and parameters; a Zap is an ordered step list; a Make scenario is modules and routes. All of it is structure you can read without running it, which means you can diff it, review it in a pull-request-like ritual, and reason about what a change will do before it does it.

A demonstration-captured routine inverts that. Its “logic” is whatever the model inferred from watching — and the primary way to find out what it inferred is to run it and compare outcomes. Editing means changing the instructions and re-testing, not reviewing a structural diff. That is a fundamentally weaker position for anyone who has to answer the question every auditor eventually asks: what changed, who changed it, and when?

The second half of the problem is specification. A routine captured from a single demonstration encodes what happened to occur, not what correct looks like across cases. An explicit builder forces someone to write the branches — which is annoying precisely because it is closer to stating a specification. Grok Bot’s own docs concede the point by design: the learned skill is a draft, and the decision rules and approval boundaries are “not evident from a single example.” Vendors are being honest here. Buyers should return the favor and plan for the refinement work rather than treating the capture as done.

We expect this gap to narrow. Version pinning, diffs and change logs are exactly what enterprise buyers demand once automations touch revenue systems, and there is no architectural reason a captured routine’s instructions could not be versioned like any other artefact. But buying on a roadmap you predict is not a governance strategy. Until the capabilities are documented, the paradigm choice is also a change-control choice — and for regulated processes, that usually decides it.

Demonstration capture’s closest structural ancestor is record-and-replay RPA: record a macro of clicks, replay it on a schedule. The mechanism of its signature failure is consistently described across vendor and analyst material. Traditional RPA automates by binding to specific UI elements — selectors, XPaths, object IDs. When a screen refreshes, an application ships a new version, or a vendor changes a class name, the binding breaks and the bot has to be rebuilt or re-recorded.

The consequence, described qualitatively across independent industry commentary, is that maintenance became a recurring, budgeted line item in enterprise RPA programs — bots recorded against one generation of an interface needed rework when the interface moved on. Specific maintenance-share figures circulate in secondary sources, but we could not trace them to a primary report, so we won’t print one. The pattern itself is corroborated widely enough to stand on its own: automation captured from a surface inherits the fragility of that surface.

Model-driven demonstration capture should be less brittle in principle — an agent that understood the intent of a step can re-find a moved button in a way a pixel-bound macro never could. That is our reading, not a vendor benchmark. But note what does not change: when a demonstration-captured routine breaks or drifts, there is still no artefact to diff against last month’s behavior. The RPA era’s deepest lesson isn’t that recordings break — it’s that recordings are hard to maintain precisely because nobody can see inside them.

The decision is rarely about which paradigm is better in the abstract. It is about the maturity of the process, the stakes of a silent failure, and who has to inspect the automation later. Four common situations cover most CRM and operations work:

One more axis worth pricing in: run visibility. A routine that keeps its 20 most recent run records is fine for a personal morning digest. It is not enough for a lead-routing automation where you may need to reconstruct what happened to a specific record three weeks ago. If your process needs durable evidence, the builders’ exportable histories — and Zapier’s account-wide audit log on its top plans — are a real requirement, not a nice-to-have. Our CRM automation engagements treat auditability as a first-class requirement for exactly this reason.

The paradigms combine better than they compete. The pattern we recommend for anything beyond personal-productivity routines: treat demonstration as requirements capture, and explicit building as productionization. Record the tacit process once — the ten-minute cap is a feature here, forcing the demonstration down to the essential path. Then use the captured draft as the specification seed: name the decision points the recording glossed over, write the failure branches, and decide what needs approval before it runs.

Where the routine ends up depends on the decision framework above. Some captures should stay demonstration-native routines — low stakes, personal scope, tolerant of drift. Others should graduate into an explicit builder or an agent workflow with versioned artefacts. If you are weighing that migration economically, our agent-vs-Zapier TCO calculator and the Zapier-and-n8n-to-agent migration playbook cover the numbers and the sequencing; for the wider tooling landscape, see our orchestration-platform comparison.

The discipline that makes the hybrid work is defining done. A demonstration shows the system what you did; it cannot show the system what correct means. Write the acceptance condition down — which record states count as handled, what the routine should do when a lookup fails, who gets notified on an exception — and attach it to the routine as its instructions. That single habit converts a fragile recording into something a colleague can reason about, even without a diff view.