n8n AI agent workflows: self-hosted build guide

Why n8n AI agent workflows need more design than a standard automation

An AI agent workflow in self-hosted n8n needs decisions on model hosting, tool scope, memory, approval and logging before the first build. A standard automation follows a fixed path from trigger to output, so you can test it once and trust it. An agent chooses its own path at runtime, which means the design has to limit what it may do before it is allowed to run against your systems. Teams that treat the agent as a normal workflow with a language model step usually discover the gaps in production, when an agent has already written to a record it should only have read. The core difficulty is that agents combine three properties that linear workflows rarely have together. First, the path is non-deterministic: the same input can lead to different tool calls, so test cases must cover sequences, not single steps. Second, tool calls have side effects. A tool that creates a ticket, updates a customer record or sends an email is a live action, and a retry or a loop can repeat it. Third, cost is driven by tokens rather than by the number of executions. n8n counts an execution as one run of a whole workflow regardless of steps, but a looping agent can consume far more model capacity inside one run, so the bill can move without any change in workflow count. Data location is the fourth factor. If the agent calls a hosted model, prompts, retrieved records and tool outputs leave your network for that provider. Some of that data may be regulated or confidential. Confirm with your security and privacy owners which data classes may be sent to an external model, and which must stay with a model you run yourself. Also confirm the provider's data retention and training terms in writing, because n8n does not control them. The choice of model hosting is therefore a data governance decision, not only a performance decision. Licensing matters if agents will be offered to customers. n8n's Sustainable Use License allows use or modification only for your own internal business purposes or for non-commercial or personal use. An internal agent that supports your staff fits that scope. An agent sold or exposed as a product to external customers may not, so have counsel confirm the terms against your business model before you design customer-facing agents. Files with .ee in their name or directory fall outside that license and need a valid n8n Enterprise License, so check which features your agent design depends on. Before building, write down four things for each agent: the model hosting location, the exact list of tools it may call with read or write rights, how it stores memory and for how long, and which actions require a person to approve them. Add a logging standard that records each prompt, tool call and outcome. These decisions shape the workflow more than the canvas does, and they are easier to change on paper than after several agents are in production.

Which n8n components an AI agent workflow depends on

An AI agent in self-hosted n8n is not a single node. It is a set of connected parts: the canvas and triggers that start a run, the agent and model connections, the tools it can call, the memory it reads and writes, and the credentials and execution log that make it work and show what it did. Review each part before you size the server or assign owners.

Canvas and trigger types

Every agent run starts from a trigger, such as a webhook, a chat message, a schedule or an event from another system. The trigger type decides who or what can start the agent, how requests arrive, and whether the instance must accept inbound traffic. Confirm the trigger node names and their current options against the n8n documentation for your installed version, because node names and parameters change between minor releases.

AI agent and model connection points

The agent node takes its reasoning model, tools and memory through dedicated connection points on the canvas rather than through ordinary data wires. Check which chat model nodes your version supports, whether your chosen hosted or local model provider has a node for it, and how the agent behaves when a model call fails or times out. Connection type names are version dependent, so confirm them before you document the design.

Tool connections to workflows and APIs

Tools are the actions an agent may take, usually a sub-workflow or an HTTP or service node exposed to the model. Each tool widens what the agent can change in your systems, so list every tool, the system it writes to, and the permission it runs under. Keep tool descriptions precise, because the model chooses tools from those descriptions. Test each tool alone before connecting it to the agent.

Memory storage

Memory lets an agent keep context across messages or runs. Decide whether memory lives in the n8n database, an external store, or only inside a single execution, and who can read it. Stored conversation data often contains personal or confidential content, so define retention and deletion rules before go-live. Confirm the memory node options and storage backends that your installed version provides.

Credentials and the encryption key

Credentials for model providers and tools are stored encrypted in the n8n database, and decryption depends on the encryption key of the main instance. Losing that key or restoring a database with a different key leaves stored credentials unusable. In queue mode, the same key must reach every worker and webhook processor. Record where the key is kept, who can access it, and how backups and restores handle it.

Execution log and action history

The execution log records each workflow run, including node inputs and outputs, which is how you reconstruct what an agent did and why. Set the retention period and decide which runs must be kept for audit or incident review. Execution data can contain sensitive values, so restrict who can open it. Confirm the saving and pruning settings for your version, and check that the log is included in your database backup plan.

Which model hosting, memory and approval options fit your team

This table compares the main choices for an n8n agent: where the model runs, where conversation state lives, which tools the agent can call, and how a human approves actions. Read each row for when the option fits and what it costs your team to run, including residency review, capacity ownership, token spend, latency and store maintenance.

Decision	Option	When it fits	Operational cost to plan for
Model hosting	Hosted model API	Non-sensitive prompts, small team, fast start, and data handling terms already approved by your privacy team	Recurring token spend that scales with runs, a data residency review of the provider, and network egress from n8n to the external endpoint
Model hosting	Locally served model on the internal network	Prompts contain regulated or confidential data that must not leave your environment	GPU or capacity ownership, model updates handled by your team, and latency tied to your own hardware and queue depth
Model hosting	Hybrid with sensitive steps kept local	Most steps are low risk but some inputs such as customer identifiers must stay inside the boundary	Two model paths to test and monitor, routing logic to maintain, and a residency review that covers each path separately
Memory	In-workflow state	Single-run tasks where context is passed between nodes and nothing must persist after the execution ends	Low storage overhead, but context resets on each run, so long conversations need a design change rather than more configuration
Memory	External store such as a database or vector index	Agents must recall prior sessions, customer history or documents across many executions	Your team or a named owner maintains the store, including backups, retention rules, access control and pruning of old records
Tool scope	Read-only tools	Early pilots, summarization, lookups and drafting where the agent must not change source systems	Low risk to downstream records, but you still review what data the agent can read and log those reads
Tool scope	Write-capable tools	Agents must create tickets, update records or send messages once the workflow logic and inputs are proven	Needs idempotency checks, rollback steps, and test runs against non-production systems before each change
Human approval	No approval gate	Low-impact actions with reversible outcomes and tested guardrails in the workflow	Lowest latency and staffing load, but errors reach downstream systems directly, so monitoring of agent actions is essential
Human approval	Wait step for a human reply	A single reviewer approves each action inside the same workflow, such as one sending a customer message	Reviewer time per action, timeouts and reminders to design, and a clear owner for pending executions
Human approval	Separate review workflow	Several teams approve actions, or approvals need their own audit trail and access rules	Two workflows to version and test, shared queue of pending requests, and an approval record your auditors can follow

How to build an n8n AI agent workflow step by step

This sequence takes an agent from a verified model connection to a governed production workflow, with a check at each stage that shows the step is finished before the next one starts. It is written for teams building agents on self-hosted n8n who need controlled tools, bounded cost and an audit trail from the first run.

Confirm the model endpoint and credential
Create a test workflow with a single chat model node, using the model provider or local endpoint your organization has approved. Store the API key or endpoint details as an n8n credential rather than typing them into node fields, then send one fixed prompt and read the response. The step is done when the call succeeds from the test workflow, the credential appears under the expected owner, and the response is logged with the model name, so you can later show which model produced each output. Confirm with your security team where the model endpoint sits, since hosted and local models have different data-handling implications.
Define narrow tools as named sub-workflows
Give the agent only the actions it needs, and build each one as a separate, named sub-workflow with a fixed input schema and one clearly defined purpose, such as looking up an order status. Avoid a general-purpose HTTP tool that can reach any endpoint. Test each sub-workflow on its own with valid and invalid inputs before attaching it to the agent. The step is done when every tool is listed in a short inventory with its owner, its inputs, and whether it reads or writes data, and when the agent can call each tool in a test run and nothing outside the list.
Add memory with a bounded window
Attach a memory node to the agent so it can refer to earlier turns, and set a fixed window of recent messages instead of storing the full conversation. Decide what must never be stored, such as personal data or secrets, and make sure the memory store uses the same retention rules as your other data. The step is done when a multi-turn test shows the agent recalls the recent context, and when a message older than the window is no longer used in the reply.
Wire a trigger from a test source
Connect the agent to a trigger that carries test data, such as a manual trigger, a webhook called from a test client, or a sample message from a chat or email test account. Do not connect a live customer channel yet. Confirm that the trigger payload reaches the agent with the expected fields and that the workflow runs once per event. The step is done when a set of test events produces one execution each, with no duplicate runs and no unexpected data in the agent input.
Add an approval gate on write actions
Place a human approval step, such as a message to a reviewer with approve and reject buttons, in front of every tool that creates, updates or deletes data or sends a message outside the organization. Reads can run without approval. Record who approved each action and what the agent proposed. The step is done when a test write is held until a reviewer decides, a rejection leaves the target system unchanged, and an approval produces a single write with the approver recorded in the log.
Set execution and token budgets
Limit how much work one agent run can do by setting a maximum number of tool calls or loop iterations in the agent configuration, a maximum output length on the model node, and a timeout on the workflow. Also check how your n8n plan or license counts executions, since n8n counts one execution as one run of a whole workflow regardless of its steps. Ask your model provider which usage limits and billing controls apply to your key. The step is done when a deliberately looping test stops at the configured limit, the run is marked as stopped, and the token count for that run is visible.
Route all agent outputs to a log
Send every prompt, tool call, tool result, approval decision and final answer to a logging destination that your operations team controls, such as a database table, a log platform or a file store with restricted access. Remove or mask fields that contain personal data or credentials before they are written. The step is done when a test run leaves a complete, ordered record of its actions that can be found by execution ID, and when a reviewer can reconstruct why each write happened without reading the workflow.
Run against a sandbox system
Point every tool at a sandbox copy of the systems it will change, using separate credentials that cannot reach production. Run a set of scripted scenarios that includes normal requests, ambiguous requests, malicious input in the user message, and tool failures. Review the agent's proposed actions against the expected results. The step is done when all scenarios produce the expected tool calls and approval prompts, no production system is touched, and each failure has a recorded fix or an accepted risk signed off by the owner.
Promote through environments
Move the workflow from development to a staging environment and then to production, changing only the environment-specific credentials and endpoints. Keep the approval gates, budgets and logging in place in every environment. If your n8n edition includes environments with Git, use them to version the workflow; otherwise export and store each version under change control. Confirm the plan or license you need for these features before you commit to the design. The step is done when production runs a version that passed the sandbox tests, the deployed version matches the stored one, and the first live executions appear in the log with the expected approvals.

Where human approval steps belong in an agent workflow

Place the human approval step between the model's proposed action and the tool call that carries it out. Any action that writes, sends, pays, deletes or changes access should wait for a person before it runs. Before building, the business owner and the security lead should agree in writing which actions count as write actions and what threshold triggers review, such as a monetary amount, a record count, or a recipient outside an approved domain. Those decisions set the design. Without them, the builder has to guess where the line sits. Several guardrail patterns matter in n8n. First, restrict the agent to the smallest set of tools it needs, and give each tool credentials scoped to the narrowest permissions the task allows. Second, validate the model's output against an expected schema before any tool node receives it, using IF or Switch nodes to check required fields, allowed values and types. Third, block write actions above the agreed threshold until a person approves. Fourth, fail closed: when the model returns an unexpected format, route the execution to a stop or error branch and never to a default branch that calls a tool. Confirm in your installed version how each of these nodes behaves when inputs are missing. A Wait node or a form-style pause can hold an execution until a reviewer responds. The reviewer should see the exact payload the agent proposed, the reason it was flagged, and the context needed to decide. While the execution waits, the tool call has not run, and the execution's state and data are kept so it can continue after a response. Define in advance what happens if nobody responds within the time you can accept, and make the default a rejection. Also confirm how long paused executions are retained and whether a paused execution occupies a worker slot in queue mode, because both affect storage and capacity. Prompt instructions such as "never send email without approval" are not enforcement. Model output can be influenced by content the agent reads, including documents, web pages and tool responses, so the model may ignore an instruction. Enforcement lives in the workflow structure: the validation nodes, the branch conditions, the scoped credentials and the approval gate. Before go-live, test the gate deliberately. Submit a flagged action, reject it, let an approval window expire, and restart the main instance and a worker during a pause. Confirm how the installed version pauses and resumes executions, and have the implementation partner record those results as part of the handover.

What drives the effort and cost of an agent build

This table lists the factors that change how much work an n8n agent build takes and what it costs to run, with ways to keep each one down. Read each row as a lever you can set during scoping, starting with the tools, permissions and approvals that shape the design. The main takeaway is that model and tool usage carry most of the running cost, because n8n counts each workflow run as one execution no matter how many steps it contains.

Driver	Why it changes effort or cost	How to keep it down
Number of tools and systems the agent touches	Each connected system needs its own credential, error handling, test data and access review, and adds to the workflow logic the agent must navigate.	Narrow the tool list to the actions the use case needs, and reuse one sub-workflow per system instead of building separate tool chains.
Write versus read permissions	Write actions change data in production systems, so they need stricter testing, rollback planning and review than read-only lookups.	Start with read-only agents, then add write tools one at a time once outputs have been checked in a test environment.
Approval paths	Human approval steps require an approver channel, timeout handling and a record of who approved what, which adds design and operating work.	Limit approvals to high-impact actions, and use one standard approval sub-workflow across all agents.
Model hosting (hosted, local or both)	Hosted models bill per model call through the provider, while local models need GPU or server capacity, patching and monitoring inside your environment. Running both adds routing and testing work.	Pick one model path per agent where possible, and confirm current provider billing terms and hardware needs with the provider and your infrastructure team before quoting.
Data sensitivity and review	Personal, financial or health data may limit which models and tools can be used, and may require data handling review before go-live.	Classify the data each agent can see, and keep sensitive fields out of prompts and tool inputs where the use case allows.
Number of environments	Each environment needs its own n8n instance or project, credentials, test data and promotion steps. Git-based environments are a Business and Enterprise plan feature.	Keep one development and one production environment for the first agents, and confirm with n8n whether your plan includes environments with Git.
Logging and audit requirements	Recording prompts, tool calls, approvals and outputs needs a consistent logging design, storage and retention rules. Log streaming is included only in the Business and Enterprise plans.	Standardize one logging pattern for every agent, and confirm retention and log streaming needs against your plan before design starts.
Volume of agent runs	Each agent run triggers model and tool calls, and those calls drive the usage charges. n8n counts an execution as one run of a whole workflow regardless of the number of steps, so n8n execution counts are not the main cost control.	Track model tokens and tool calls per agent, set limits on loops and retries, and cap how often triggers can start an agent.

How to protect credentials, data and tool access in agent workflows

An AI agent in n8n holds model API keys, tool credentials and the ability to write to other systems, so its risk sits in several places at once. The cards below cover the controls that connect those places: where secrets live, who can use them, what content can steer the agent, and how actions are traced back to a person.

Store model and tool keys in the credential store

Keep model API keys and tool credentials in n8n's credential store rather than in Code nodes, expressions or workflow notes, where they can be copied into execution data or exported with a workflow. The encryption key that protects stored credentials should be managed outside the repository and backed up separately, because n8n needs the same key on every instance and worker that reads credentials. Check which credential types each agent tool uses and whether any service account has broader permissions than the agent needs.

Limit who can use shared credentials

Credentials are shared through projects, so a credential is only as protected as the group of people and workflows that can reach it. Decide which projects may use a model key or a CRM credential, and keep production agents in projects separate from experiments. Review project membership and user roles on a schedule, and confirm which roles can view, edit or use a credential, since the exact permission model depends on the edition and version you run. Where identity provider control matters, SSO and LDAP are included only on the Business and Enterprise plans, and enabling them depends on the edition you choose.

Block retrieved content from triggering write tools

Prompt injection happens when text the agent reads, such as a web page, email, support ticket or document returned by a retrieval step, contains instructions the model follows. If that same agent can call tools that send messages, update records or move money, the injected text can cause real side effects. Separate read-only retrieval agents from agents with write tools, pass only the fields a tool needs, and require a deterministic check before any write executes. Test the workflow with hostile sample content to confirm the boundary holds.

Restrict Code node use inside agent tools

Code nodes run arbitrary JavaScript or Python, so a Code node inside an agent tool gives the model's chosen inputs a path to logic you did not review. Decide which users may create or edit Code nodes, and whether agent tools may contain them at all. Where code is needed, keep it in version-controlled sub-workflows that go through review, and check the instance's settings for restricting Code node and community node use before you rely on them. Confirm the exact options available in your n8n version with the vendor documentation.

Control webhook exposure for agent triggers

Webhook triggers that start an agent are reachable by anyone who can send an HTTP request to the URL, so an unauthenticated agent endpoint can be used to spend model budget or push malicious input. Limit which webhook paths are public, require authentication on triggers where your n8n version supports it, and put the instance behind a reverse proxy with TLS and rate limits. In queue mode, the main instance handles triggers and webhooks, so review what it exposes and which network segments can reach it.

Record who approved each write action

For any agent action that changes an external system, log the approving person, the time, the input the approver saw and the action taken. Human approval steps are only useful if the approval is attributable and the approved payload is the one that executes. Send execution and audit events to your central logging system, and confirm that log streaming is available on your chosen plan, since it is included only on the Business and Enterprise plans. Test that a rejected or timed-out approval never reaches the write tool.

How agent workflows change across single node, queue mode and high availability

On the Community edition, a single n8n instance runs the editor, webhooks, scheduled triggers and workflow executions in one main process. An agent run executes inside that process, so model calls, tool calls and memory lookups compete with the editor and every other workflow for the same CPU and memory. This model is the simplest to build and operate, and it suits pilots, internal assistants and low-volume agents where a short interruption is acceptable.

Agent runs: each agent execution shares the main process, so a burst of agent traffic can slow the editor and webhook responses.
Throughput: the practical ceiling is set by the host, so plan for vertical growth and confirm limits with your own load tests.
Long approval waits: a paused execution still depends on the single instance being up when the approver responds, so confirm how waiting executions survive restarts in your version.
Credential access: credentials are read directly by the main process using its encryption key, with no second process to synchronize.
Failover: there is no multi-main failover on the Community edition, so a host failure stops agents until the instance is restored.

Before committing to this model, ask your team to measure peak concurrent agent executions and confirm the restart behavior of approval waits with a test workflow.

How to test that an agent workflow works and fails safely

Test the failure paths of an n8n agent workflow before you test its happy path. Start by recording real inputs from a pilot run, removing personal and confidential data, and replaying them through the same workflow with the chat model node pointed at a sandbox endpoint and every tool node pointed at a test account or a staging copy of the target system. For each replayed input, write down the expected tool calls and the expected final state of the target system, then compare the execution history against those expectations. A replay that only checks the final chat reply will miss an agent that called the wrong tool and happened to produce a plausible answer.

Next, force the failures the workflow will eventually meet. Point the model node at a stub that returns malformed JSON, a truncated response, an empty reply, and HTTP errors such as 429 and 500 (illustrative cases you should adapt to your model provider). Confirm that the output parser or validation step rejects bad output and that execution follows your fail-closed branch, which should stop before any write node runs. Repeat with a tool node that hangs past its timeout. Check the timeout values set on each node and the workflow-level error handling, and confirm the error branch notifies an owner and records the failure without retrying writes blindly.

Test the controls that protect systems of record. Place a Wait node or other approval step in front of every write, then run a case where no response arrives and confirm the target system is unchanged after the execution times out or stays paused. Run a second case where the approver rejects the request and compare a before and after snapshot of the affected records. For tool scope, connect only the tools the agent may use and send prompts that ask for other actions, including instructions hidden in retrieved content. Then check the execution log to confirm no tool outside the allowed list ran, not just that the reply declined the request.

Verify logging and reruns last. Confirm that each execution records the input, every tool call with its parameters, each approval decision with the approver, and the final output, while credentials, API keys and tokens appear nowhere in the stored data or in any log stream you forward. Check your execution data saving settings, and if you forward logs, confirm that log streaming is available on your plan, since n8n's pricing page places it in the Business and Enterprise plans. Finally, pause a workflow mid-run and rerun a failed execution. Each write should carry an idempotency key or a lookup that makes the second attempt a no-op. Repeat the full set in queue mode, because worker pools can execute the same steps differently from a single main instance.

What to monitor, log, upgrade and document after go-live

After go-live, an agent workflow can change behavior without any edit to its own logic: model providers update endpoints, n8n ships minor releases, and tools return different data. The four areas below are where a self-hosted team needs a named owner, a routine and a written record. They depend on each other, so each upgrade test should reuse the tool inventory and approval matrix described in the documentation card.

Monitoring execution, errors and cost

Track failed executions for each agent workflow, model error rates by provider and endpoint, and, in queue mode, the depth of the Redis queue that workers drain. A queue that keeps growing usually points to undersized workers or a tool call that hangs, so alert on sustained growth rather than single spikes. Where your model provider reports usage by request, also track spend by workflow. Confirm with each provider which usage fields it exposes, since not every provider attributes cost to a workflow.

Logging agent actions

Record each tool call an agent makes, the inputs and outputs needed for audit, and the identity of the person who approved any write action. According to n8n's pricing page, log streaming is included only in the Business and Enterprise plans, so Community edition teams need a different route. Confirm what the Community edition can export from executions and where it can be sent before you rely on it as evidence. Mask personal data and secrets before logs leave the workflow.

Retesting after each upgrade

n8n uses semantic versioning and ships minor releases roughly weekly, so an agent can change behavior after an upgrade you did not write. Treat each upgrade as a change: read the release notes for every version between your current and target release, rerun the agent test cases in staging, and confirm that tool schemas and model node parameters still resolve. The release notes list n8n 2.43 as released on 6 October 2026, so check the notes for the version you intend to run before you schedule the change.

Documenting tools, approvals and owners

Keep a current record of the tools each agent can call, the approval matrix that states which actions need a person to confirm, the model endpoints in use, and the named owner of every credential. For each write-capable agent, file a review record showing the date, the reviewer, the scope tested and any open risk. Review this record whenever a tool or endpoint is added, since a new tool without a matching approval rule is the gap auditors and incident responders look for first.

Questions teams ask before building AI agents in self-hosted n8n

How much effort does building an AI agent workflow in self-hosted n8n take?

Effort depends mainly on how many tools the agent calls, how many systems those tools touch, and how much human approval and logging the process needs. A single agent that reads one knowledge source and posts a summary is a small build. An agent that writes to a CRM, a ticketing system and a payments or HR platform needs credential scoping, error handling, test data, and an approval path for each write action, which multiplies the work. Model choice adds effort when you must decide between a hosted API and a local model, because that choice changes data residency, latency and cost review. Ask any partner to break the quote into tools, approval steps, logging, and testing, and to state which systems will be used in a sandbox before production access is granted. No effort figure is given here; confirm it against your own system inventory.

Can our internal team build AI agents in n8n without outside help?

Often yes, if you already run automation or integration work and have someone comfortable with n8n's visual canvas and, where needed, its Code nodes in JavaScript or Python. The harder parts tend to be operational rather than visual: securing the encryption key and credentials, separating test and production environments, defining who approves agent actions, and keeping a reliable log of what the agent did. Teams usually check three things before deciding: whether they have a named owner for the platform after go-live, whether they can staff reviews of agent behavior, and whether they have time to test failure cases such as malformed model output or a tool returning an error. A fixed-scope engagement can cover only the agent build while your team keeps ownership, or it can include handover so your staff can run it.

What do we need to provide for an n8n AI agent build?

Plan to provide four things early. First, a sandbox or staging environment with test copies of every system the agent will call, so no agent run touches live records during testing. Second, decisions on model access: which hosted model providers are approved for your data classification, whether any workload must run on a local model, and who holds the API keys. Third, named approval owners for each action that changes data or money, plus a fallback when they are unavailable. Fourth, a log destination such as your existing SIEM or log platform, with retention rules agreed with security and compliance. Missing any of these usually pushes work into the final weeks of a project. Confirm each item with your security, data protection and business owners before you request a quote.

Does the n8n Sustainable Use License allow us to run internal AI agents?

The Sustainable Use License permits use or modification for your own internal business purposes, so running agents that automate your own internal processes falls within that grant. It does not permit distributing n8n free of charge for commercial purposes, and it does not cover any file with .ee in its name or directory, which requires a valid n8n Enterprise License. Agents that you offer to outside customers as a product, or that you bundle and distribute, need a legal review against the license text before you build. Read the current LICENSE.md in the n8n repository and have your counsel confirm how your deployment fits, because the license terms are the authority, not this summary.

Do we need n8n Business or Enterprise for SSO, log streaming or multi-main?

Yes, according to n8n's pricing page, SSO and LDAP, environments with Git, and log streaming are included only in the Business and Enterprise plans. SAML single sign-on is documented for those plans, with setup guides for Okta Workforce Identity and Azure AD. Multi-main setup, which runs several main instances for high availability, is restricted to Enterprise self-hosted deployments. The Community edition is free to self-host but does not include these features, so an agent platform that needs centralized login, streamed audit logs or a highly available main tier must budget for a license. The Business plan is listed at 667 euros per month billed annually and is currently self-hosted only, while Enterprise uses custom pricing. Confirm current plan contents on n8n's pricing page before you commit, since editions can change.

What drives the cost of a fixed-scope quote for n8n agent workflows?

A fixed-scope quote follows from a written statement of what will be built. The main drivers are the number of agent workflows, the number and type of tools each one calls, the approval and escalation rules, the logging and retention requirements, the model access setup, and how many environments must be built and tested. Quotes also differ in whether they include handover, documentation, and post-go-live support, which is available as a retainer. Your own costs sit alongside the partner fee: infrastructure, any license you choose, model API usage, and staff time for reviews and approvals. Ask the provider to state what is one-time and what recurs, and to list the assumptions behind each line. DeployOpen does not publish prices and gives a quote from the agreed written scope.

How should we ask for a fixed-scope quote for an n8n AI agent project?

Write a scope brief before you contact any provider. List each agent's goal, the systems and actions it may touch, the decisions that need human approval, the model providers you will accept, the log destination and retention needed, and the environments you require. Name the owner on your side who signs off on scope and acceptance. Ask for deliverables, acceptance tests, timelines and exclusions in writing, plus a clear statement of what is charged once and what recurs. Request a separate line for testing against sandbox data and for any follow-on support. DeployOpen works from written scope, deliverables and timelines agreed before work starts, so a detailed brief shortens the path to a quote.

How DeployOpen works on this

DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, including n8n AI agent workflows. Engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts.

How we scope

Inventory the agent use cases, the models they call, and the tools and data sources each agent may touch.
Record which agent actions need human approval, and which must never run without a person reviewing them first.
Agree in writing whether the build uses Community or licensed n8n features, and confirm license fit with your legal team.

How we build

Set up agent workflows with explicit tool allowlists, memory scope, and guardrail checks before any live data is connected.
Route approval steps, retry limits and spend caps into the workflow design, and test each branch with illustrative inputs.
Keep credentials in n8n's credential store with access limited to the workflows that need them, and review the Code node usage.

How we hand over

Deliver workflow documentation covering each agent's purpose, tools, model choice, approval points and failure handling.
Provide logging configuration for agent actions and a test record showing guardrails and approval steps behaved as specified.
Walk your operations and security teams through runbooks for changing models, rotating credentials and disabling an agent.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, covering agent workflows after go-live.
Retest agent workflows when n8n ships new releases, since minor versions arrive roughly weekly and can change node behavior.
Confirm with us in the quote which support hours, response expectations and review cycles apply to your environment.