An Agent That Builds Automations, and the Checks Before They Run

A workflow diagram can look finished while leaving the difficult questions unanswered. Are the settings valid? Are the failure branches connected? Who supplies the credentials? What evidence says the automation will do the job your team needs?

Those are the questions behind our internal n8n department. This is our internal name for the agent-assisted build and diagnosis setup I supervise. We have an agent called the Automator that designs workflows, checks their configuration against node schemas and validates the result before handing it back to me.

I want AI to reduce the work involved in building automations. I also want a clear account of what it has checked. In our setup, the agent cannot deploy or activate the workflow. I import it manually and make the necessary adjustments. That division is deliberate.

TABLE OF CONTENTS: The agent's job; schemas instead of remembered settings; validation and review; failure handling; lessons from templates; deployment and diagnosis; what an owner should expect.

The agent has a defined job and limited access

n8n is the workflow tool we use to connect services and arrange automated steps. A node is a step in that workflow, with settings that determine what it does.

The Automator can look up nodes and templates, inspect node definitions and validate workflow files through a local tool called n8n-mcp. In this setup, that tool supplies documentation and validation. It is not connected to a running n8n instance.

That means the agent cannot create, run, activate or inspect a live workflow. Its instructions explicitly prohibit claiming that it has done those things. The output is a workflow definition, accompanied by validation results and instructions for the work that remains.

For an owner, this is an accountability point. A generated file, a file that passes validation and an automation tested in its real environment are different deliverables. If a supplier calls all of them finished, you cannot tell which risks remain with your team.

Our arrangement gives the agent useful work without giving it the ability to change production. Production means the live environment where an error could affect the business. I retain the import and adjustment step, and the agent must make the handover concrete enough for that work to happen.

It looks up settings before choosing them

A schema describes the settings a node accepts and how they are structured. Our agent's rule is to retrieve the node schema before setting its parameters, rather than rely on what the model remembers.

This matters because a plausible setting is not necessarily an accepted setting. The Automator's instructions put the schema returned by the tool ahead of conflicting guidance in its skills, and require it to report the disagreement.

When we say it builds from live node schemas, this is the mechanism: it queries the documentation tool during the task. It does not mean the agent has inspected our running n8n installation. That distinction prevents a useful lookup from being sold as proof of compatibility with an environment it cannot access.

Templates get the same treatment. The agent may use a template as a starting point, but it must check the node versions, identify the original author and source, and explain its changes. Finding a template is the beginning of the job.

The agent also looks up behaviour in n8n's own documentation when a list of settings is insufficient to decide the design. Knowing which fields exist and understanding how a step behaves are related tasks, but neither substitutes for the other.

This is where I expect AI assistance to be useful: making lookup and construction part of a repeatable process. Our dossier does not contain a measured reduction in build time, so I will not attach a saving in hours to that expectation.

Validation is a gate with a specific meaning

The workflow definition is returned as JSON, a structured text format that n8n can import. Before delivery, the agent must validate the whole file, fix errors and repeat the validation until there are 0 errors.

That is an acceptance rule in the agent definition, not a claim that our automations have never failed. I handle the import and adjustments; the agent supplies the test instructions. For a business handover, I would also require agreed expected results and evidence from testing the final imported version. Validation of the generated file does not establish what a subsequently adjusted version does.

Warnings may remain, but they must be quoted in the handover with a reason. I want the unresolved points visible. A warning silently omitted from an answer cannot help the person deciding whether a workflow is ready to test.

There is also a separate review of the connections. The agent must read the connections object itself, check that nodes and error outputs are wired, and count the inputs of Merge nodes, which combine paths in a workflow.

The instructions state the limitation directly: passing validation means well-formed, not correct. A validator can accept a structure without establishing that the structure implements the owner's business rules.

This is the difference I care about when someone says an automation was built by AI. What did the system check, and what does a person still need to establish before relying on it?

The design must include what happens when a step fails

Our agent is required to include error handling in every workflow it delivers. That means an error workflow or an error branch, together with retries on every node that calls outside n8n. A retry is another attempt after a failed call.

The rule makes failure handling part of the build. It does not, by itself, establish how repeated actions are handled safely. The supplied agent definition gives no universal answer to that question, so it remains something to resolve for the particular workflow before relying on its retries. It is not an optional improvement to consider after a successful demonstration.

The Automator also has to identify the core business logic before designing the workflow. Our internal rule puts connections, credentials, triggers, notifications, file conversion and routing in n8n. Logic that decides a result a client could dispute, needs a test or handles large files belongs in code that n8n calls.

In ordinary language, the tool connects the work, while important calculations or decisions get a place where they can be tested explicitly. The handover must explain any core logic left outside n8n and the interface used to call it.

There is an explicit exception for prototypes or internal flows whose results nobody will dispute. Those can keep their logic in n8n until it needs a test, provided the agent says it is using the exception. I prefer a stated shortcut to an invisible one.

For the owner, the question is where the business rule lives and how it will be checked (in Bulgarian). A polished diagram does not answer that question on its own.

Our template review found reasons to inspect beneath the diagram

The department's knowledge notes include a review of external automation blueprints. Those files were treated as reference material, not something to import unchanged into a client deliverable.

The review recorded embedded credentials and other sensitive connection details. It also found problems in document-processing workflows: a change-detection condition that prevented the changed-document branch from firing, old search content remaining in place, and a positional merge that could shift metadata after empty chunks were dropped.

Metadata is information attached to a piece of content, such as which document it came from. If that association shifts, a workflow can keep running while attaching the wrong context to its output.

These are findings from inspected reference files, not claims about a client incident or a measured loss. They explain why our agent treats templates as material to inspect and adapt.

Our own rules prohibit putting keys, tokens or passwords in the returned workflow JSON. Access details must go through n8n credentials, its mechanism for storing service access separately from ordinary workflow settings. The agent refers to credentials by name and type.

Even template searches have a boundary: search by capability, not by client names, email addresses, amounts or copied client material. Convenient discovery should not require sending a client's information into the search.

I deploy it, and the agent must explain what remains

The delivery includes the workflow file, final validation results, remaining warnings and the credentials and values I must supply. It must also explain how to test the workflow in n8n with harmless data.

Those details are part of the result. Without them, the agent has handed me an assembly task whose missing pieces I have to discover myself.

The department's recorded decision is that I import and adjust workflows manually. The agent has no n8n API key, the access token that would allow it to work with the instance through software requests. It builds and diagnoses; it does not silently edit a running automation.

This does not make a workflow correct merely because a human imports it. It gives us an explicit point to connect the validated definition to the actual environment, supply access, test behaviour and decide whether it is ready.

That is the answer to the demo problem. A demonstration can show a promising path. The handover and the execution checks must establish what happens in the environment where the business will use it.

Diagnosis after a failure is a separate system

The department also documents an Error Reporter workflow. Its role is to email an error report without the item data being processed. A local watcher checks for reports every 10 minutes, asks the Automator for a read-only diagnosis and sends the diagnosis to Telegram.

The interval is a polling schedule, not a guaranteed response time or repair time. Repeated reports within 6 hours are grouped into an alert to avoid repeating the same notification.

The diagnosis is intended to explain what broke, the kind of problem, its urgency and the steps to fix it in the editor. I still make the change manually.

There is a material limit in the project notes: the diagnosis path was checked with a simulated report, while a real test from an n8n failure through the reporting chain remains an open item. The notes also leave open what happens when the reporting workflow itself fails. I will not describe those unresolved points as proven production monitoring. The dossier establishes an internal design and a simulated diagnosis test, not readiness of the complete reporting chain for client reliance. Manual repair remains my responsibility, but these notes do not establish a fallback for discovering a failure when the report never arrives. That gap needs closing before treating the watcher as dependable coverage.

Automatic repair is explicitly deferred until diagnoses have a track record of matching the real cause. That is a sensible distinction between generating a plausible explanation and earning permission to change a running system (in Bulgarian).

Buy a working process, with evidence at each handover

The reason to build this department is practical: reduce manual construction work while keeping configuration checks, review and responsibility visible. It is not evidence of a particular saving in hours, revenue or support costs. Those results are not measured in the supplied dossier.

If you are buying an automation, ask for the validated file, the remaining warnings, the test steps and the result of running those steps. Ask who imports it, who receives failures and who is responsible for repair. The answers tell you more about the handover than a confident claim that an agent can build everything.

Bring a repetitive task to a free audit if you want to assess where automation could help. We can look at the hours it consumes, the business rules it must preserve and the evidence you should expect before handing that work over.