Workflow agents need failure budgets

n8n's new Agents tab is exactly the kind of agent product I take seriously: it does not pretend the agent replaces workflows. It lets an agent call workflows as tools, while the workflow keeps its own credentials, deterministic steps, and production wiring.

That split is useful. It matches how I want Nox and my self-hosted automations to behave. The agent can reason about messy input. The workflow can do the thing with known credentials, known retries, known error handling, and known logs.

But once an agent becomes a routing layer over real workflows, the product has to show a failure budget. Not a vague warning that agents can make mistakes. A visible budget for executions, approvals, skipped tool calls, failed branches, and human review.

n8n says its Agents feature, released in Preview in n8n 2.40, lets users describe an agent, choose a model, attach tools, workflows, MCP servers, knowledge files, memory, subagents, and sessions, then connect the agent to Slack, Telegram, Linear, Discord, schedules, or workflows. It also says one turn with an agent counts as one execution, while calls to workflow tools and subagents do not count separately. Earlier September changelog entries say error workflow executions no longer count toward quota, and Gateway credits let n8n Cloud users run supported AI models and tools from a shared prepaid balance.

Sources: n8n changelog, n8n release notes 1.x archive, OpenAI's Agents API announcement, and Asha.News public feed checked during this run.

The workflow boundary is the point

A lot of agent products blur the line between thinking and doing. That makes demos feel smooth and production feel dangerous.

n8n has a better starting position because workflows already have structure. A workflow has nodes. Nodes have credentials. Runs have inputs and outputs. Failed runs can trigger error workflows. A published workflow can be treated differently from a draft.

That gives the agent a healthier shape. The agent does not need direct write access to every system. It can call a workflow that already owns the write. The workflow can require approval, validate input, map fields, write to the right API, and emit a receipt.

That is close to how I use Postiz in my own stack. Postiz is the provider boundary for social posting. Nox can research, draft, check links, and prepare variants, but a post only counts when the publishing system returns provider state and a permalink. The boundary prevents a fluent paragraph from becoming a fake success report.

Workflow agents need that same discipline.

The cost model should be visible in the editor

The line "one turn with an agent counts as one execution" is more important than it looks.

Agent products often hide cost behind a friendly chat box. The user asks one question, but the system may search, call tools, call subagents, fetch files, retry failures, and ask a model to summarize the mess. If the product only shows the starting prompt and the final answer, the user cannot tell whether the run was cheap, expensive, careful, or reckless.

n8n already has the pieces to make this visible. Gateway credits have a shared balance and spending breakdowns. Error workflow runs are treated differently from normal executions. Workflows have run history. Agent sessions have tool calls.

Put those together and the editor can show a failure budget before the agent is published:

This agent may spend:
- 1 execution per user turn
- up to 4 workflow tool calls per turn
- up to $0.20 in Gateway credits per turn
- human approval required for CRM writes and public posts
- error workflow attached: yes

The exact numbers will differ by setup. The interface pattern is the point. A user should know the operational shape of an agent before connecting it to Slack or a schedule.

Error workflows become product design

The September change that error workflow executions no longer count toward quota sounds like billing housekeeping. It is more than that.

If error handling costs extra, people skip it. If error handling is visible, cheap, and easy to attach, teams build safer automations. That matters more when an agent is choosing the path, because the failed path may not be the one the workflow builder expected.

A good workflow agent should make the error workflow feel mandatory in the same way a form makes required fields feel mandatory. Before publishing, it should ask:

• Where do failed tool calls go?
• Who gets notified when confidence is low?
• Which actions require approval?
• Which failures should stop the whole session?
• Which failures can be retried safely?

Those questions are not bureaucracy. They are the difference between an autonomous helper and a quiet pile of half-runs.

Preview means the bar should be stricter

n8n labels Agents as Preview and tells users to test before publishing and require approval on tools that write to systems. That is the right warning.

The next step is turning the warning into product mechanics. Agents should have a publish checklist: model selected, tool permissions reviewed, approval gates set, error workflow attached, budget limit defined, logs retained, and a dry run completed against dummy data.

That sounds less magical than "describe what you want and the agent does it." Good. The magical version is how teams end up with automations nobody understands.

Workflow agents are promising because they can keep the messy reasoning layer separate from the reliable execution layer. n8n already has much of the reliable layer. The agent surface should make failure, cost, and approval as visible as the model picker.