n8n Agents Splits One Quote Into Two Products

The n8n Agents launch reads as a feature announcement, and for your clients it is. For the person writing the quote, it is a fork in the pricing sheet. A deterministic workflow is a finite build: you acceptance-test it to completion, hand over credentials, and bill it flat. An agent is an operating obligation: you can bound its behavior with evals and guardrails, but never fully verify it, so it carries a risk premium, a monitoring commitment, and a monthly invoice. Freelancers who keep selling both under one per-automation price are volunteering to absorb the agent's failure risk and its usage-driven costs at zero margin.

The announcement explains what agents do. It stays quiet on what an n8n consultant actually needs: which client problems should become agents, what to charge on each side of the fork, and what you are signing up to maintain. This piece fills that gap: a five-question test for classifying briefs, a quote template for each paradigm, the margin math where each model leaks, and contract language that keeps an agent from becoming a 2 a.m. obligation. Five worked examples run through it.

What n8n Agents Ships and What It Does Not Change

Per n8n's launch announcement, an agent is something you describe in plain language, hand a model and a set of tools, and let it work out the steps itself. Starting one is cheap by design: create it from the Agents tab, or describe the job to n8n Assistant. Trial on Gateway credits before attaching your own model API keys, so you know the prototype's real cost before quoting. Once it exists, that one agent answers in Slack, runs on a schedule, and takes calls from any workflow. The surrounding machinery is what a service needs: approvals before sensitive tools, drafts that edit while the published version serves, and session logs that show every tool call from last Tuesday. It is still in preview, live on n8n Cloud for workspaces on the latest stable version, with extra setup required for self-hosting.

Underneath, this packages patterns you may already assemble by hand around the AI Agent node, which n8n says is unchanged.

What the launch does not change matters more to your quote. Your deterministic builds, test suites, and fixed fees are as billable as ever. Workflows and agents are positioned as complements, with any workflow callable as an agent tool and a Message an Agent node for the reverse direction. Price them as two products on one platform: QA, acceptance, warranty, and support all behave differently on each side.

Workflow vs Agent Comes Down to Verifiability

Anthropic's engineering guidance draws the line in a way that maps directly onto a freelancer's risk. Workflows route LLM steps through predefined code paths you laid out in advance. Agents let the model direct its own process, choosing which tools to use and in what order. The distinction is about control, and control is what makes QA possible.

A workflow can be accepted against a finite suite of input-output test cases. Thirty inputs in, thirty expected outputs, all pass, signed off. An agent given the same input twice can produce different runs, so no finite suite proves it correct. Agent acceptance has to become measured behavior: a pass rate on an agreed eval set, plus hard guardrail limits that bound the worst case. If you have not run evals before, OpenAI's evals guide covers the mechanics of scoring.

Scope fights are born here. A workflow defect is provable: input X produced output Y, test case 14 fails, fix it under warranty. An agent that answered strangely on Tuesday is a distribution question. Unless the contract defines the line between a defect and a tuning request, every odd answer arrives as a free bug report.

The Decision Test for Every Client Brief

Run every brief through five questions before quoting:

The ruling, so the table decides:

1. One agent-column answer on the "gets one wrong" row disqualifies autonomy. Mistakes that move money or cannot be unwound get a workflow with a human approval node, not an unattended model.
2. Two or more agent-column answers otherwise: quote the agent, with the eval-gated acceptance from the last section.
3. Anything less is workflow first. Most "agent" briefs are exception-handling or routing problems that a workflow with a human approval step solves more cheaply and more safely.

Quote the agent when the test returns one, not because the brief used the word.

Worked example one: a lead router, not an agent

The client wants "an AI agent" that takes Typeform leads, enriches them, scores them, and alerts a rep about the hot ones. Every step is known in advance, and the model appears once, as the scorer. This is a workflow with an LLM step. Quoting it as an agent bills the client for an operating obligation they do not need and commits you to monitoring a routing job.

Worked example two: an open-ended Slack brief that needs an agent

The client's team keeps asking in Slack why a customer's usage dropped last month. Answering takes rounds: pull the account, ask which product line they mean, check support history, return a short readout plus a clarifying question. What to check next depends on the last answer, so there is no canvas to draw before the conversation starts. This is the open-ended shape the announcement itself calls out, and it genuinely needs an agent.

Quote the Workflow as a Finite Build

Pricing an n8n automation project of this shape already has a stable answer, and the launch does not move it. What changes is that the answer now needs defending: a client asking for an agent forces a finite quote to justify its finiteness, and the five questions are that justification.

1. Scope. The enumerated input shapes from the decision test. The forms, payloads, and file types the five questions let you list, and nothing else.
2. Acceptance. A finite suite of roughly 20 to 50 representative input-output cases, agreed before the build. The suite is the contract.
3. Price. A flat fee, or per-automation pricing for small jobs. Flat is defensible because the suite is finite.
4. Warranty. Thirty days. A defect is a suite case that used to pass and now fails; suite membership defines what is free to fix.
5. Change orders. Any input shape outside the enumeration is a change, priced before it is built.

Build the failure paths too, and bill them. Retries, error branches, and alerting are node work like any other, scoped and priced in the quote, not free insurance for the flat fee; n8n's error-handling guidance covers the patterns you are selling.

A finite build also ends: credentials, instance ownership, and the test suite hand over to the client, and your obligation stops with the warranty. An agent never ends, which is why the two cannot share one price.

Worked example three: an invoice job mislabeled as an agent

A client asks for an invoice-processing agent. Unpacked, the job is: parse the PDF, extract fields, match against a purchase order, post matches to the accounting system, route mismatches to a person. The only judgment is extraction, and the exceptions already have a human home. Quote it as a workflow with an approval node. The client can keep the word "agent" internally; your quote describes a build with a test suite.

Quote the Agent as an Operating Obligation

The moment a client can message your deliverable in Slack, you have shipped a service, not a script. Uptime, response time, and tone become product features, and an outage becomes a performance review. Price the obligation or bound it contractually, because the expectation exists either way. That is why AI agent pricing carries a risk premium the workflow quote does not.

The quote has four parts:

• Discovery and eval set. Agree on 50 to 100 real historical cases and a scoring rubric before building. This is how you QA an AI agent before delivery, and it is billable.
• Setup fee. Build, guardrails, and calibration until the agent reaches the target pass rate. Expect two to three times a comparable workflow build, since you are also building the eval harness; treat that as an illustrative range.
• Monthly retainer. Monitoring, session review, tuning within included hours, and a quarterly eval refresh.
• Guardrails as deliverables. Human approval on write actions, spend caps on model calls and tools, a stated response window, and a monthly usage cap.

Put acceptance in writing, in behavior terms:

Acceptance means the agent reaches the agreed pass rate on the eval set in two consecutive runs, with no guardrail violations in the final test week. After launch, a defect is a drop below threshold or a guardrail breach. Everything else is tuning, delivered within retainer hours or quoted separately.

Worked example four: a lead-qualification agent with placeholder numbers

A Slack lead-qualification agent that researches inbound leads and posts a summary. Illustrative shape: setup in the low four figures, covering eval set construction and calibration, plus a monthly retainer of roughly 15 to 25 percent of setup for a fixed block of tuning hours and monitoring. The structural point survives any rate card: the quote has two numbers, and the second recurs. Monitoring is what catches drift before the client does; standard LLM observability practices like tracing every run, watching failure patterns, and reviewing sessions on a schedule rather than on complaint are the retainer's actual content.

Where the Margin Leaks in Each Model

The two paradigms leak in different places.

The workflow leaks through scope creep. A new edge case presented as a bug ("it broke on multi-currency invoices") is a change order if the suite never covered it. Free enhancements in the same breath as defect reports, plus unpaid hosting babysitting, do the rest. Scope creep in AI automation projects rarely announces itself; it arrives dressed as QA feedback.

The agent leaks through usage and ambiguity:

• Recurring, usage-linked costs. Model calls bill on tokens, and n8n Cloud plans bill by execution per n8n's pricing page. The announcement counts one agent turn as one execution sharing the workflow quota, with tool calls to workflows and sub-agents not counted separately. But helper workflows that fire on their own triggers (webhook relays, scheduled sweeps) bill as executions themselves, and error workflows or retry loops can consume quota. Depending on how you wire it, an agentic pattern can multiply executions per user interaction, so model the wiring before you set the price.
• Unbounded conversational load. Connect an agent to a forty-person channel and usage grows with enthusiasm, not with any decision of yours.
• Tuning disguised as bug reports. The largest leak, because each request looks small and arrives individually.

Worked example five: the margin math

Illustrative assumptions:

• Flat build price: $3,500, about forty hours at roughly $85 billed
• Internal cost: $70 an hour, leaving $700 of build margin
• Load by month three: about 2,500 turns a month
• Model spend: on your keys, if set up that way
• Tuning: two to three unpaid hours monthly
• Quarterly eval refresh: one unpaid day

The arithmetic: tuning alone runs $140 to $210 a month. The eight-hour refresh day costs about $560 a quarter at the $70 rate, roughly $190 a month amortized, so tuning plus amortized refresh runs $330 to $400 a month and crosses the $700 build margin inside the first quarter. Replace every number with your own; the shape holds. Usage scales with the client's success, and a one-time price does not scale with anything.

When tuning requests cluster on one task, formatting the summary, say, pull that task into a workflow and leave the agent the judgment-heavy steps. The announcement supports moving that line explicitly: fix what should be fixed, leave discretion where discretion pays. Knowing when to build a workflow instead of an agent is a post-launch skill too, not just a pre-sale one.

Contracts, Client Transitions, and Your Next Three Moves

Five clauses do most of the protective work:

• Defect versus tuning, defined per paradigm. For workflows, a defect fails an agreed test case. For agents, a defect drops below the eval threshold or breaches a guardrail. Everything else is billable work.
• Account ownership. The client owns the n8n instance, the model keys, and the API accounts, including their spend. If you host anything, it is a billed line item.
• Response expectations. Business hours, defined in the retainer. An agent that lives in Slack does not create pager duty unless you sold pager duty.
• Usage caps. Monthly turn or tool budgets, with an overage conversation triggered automatically.
• Downgrade rights. Either side can move a step from agent to workflow as a quoted change order, which often saves the client money.

Selling AI agents to clients at a per-automation price is how these obligations accumulate. A direct transition resets the frame:

"The platform just added agents, so we reviewed your setup. The automations we built are tested workflows, and their pricing stands. Two of your requests, [X] and [Y], are open-ended in a way agents now handle better. Here is what an agent version would cost to set up and monitor, and our honest read on whether it is worth it at your volume."

Retainer pricing for agent maintenance follows ordinary consulting logic: retainer versus project pricing trades scope certainty for availability, and monitoring is availability. Sell the retainer as continuity, not hours.

Your next three moves:

1. Audit your last five quotes. Classify each deliverable as a build or an obligation. Anything you still answer emails about after warranty was priced wrong.
2. Build one eval template. A scoring rubric plus 50 to 80 real cases per client type, reusable on every agent quote.
3. Productize two offers. A fixed-scope automation build accepted by test suite, and a monitored agent sold as setup plus retainer. Publish starting prices for both.

The workflow stays your default quote. The agent is a different business, and it should look like one on the invoice.