On this page
Working with AI agents eventually calls for a server that stays on: somewhere to collect incoming data, run scheduled tasks, and check progress and send updates.
I use n8n as a runtime for these jobs. Since I can connect nodes and write the logic in JavaScript, it seemed useful for small applications that need to keep running.
I set up the workflow development and operations a little differently, though. Instead of connecting each node myself in the n8n editor, I let AI agents create the workflows, deploy them, and check that they work.
A format agents can work with
The n8n visual editor is useful for understanding a workflow. But editing code inside nodes and managing changes across multiple workflows entirely through that interface was inconvenient.
I separated the execution logic into ordinary JavaScript files and the nodes and connections into JSON templates. Environment-specific configuration lives separately as well. A build step combines them into workflows n8n can execute.
With that structure, an agent can read and edit files just as it would in a regular codebase. Changes stay in Git, where they can be compared with earlier versions. The agent handles the node structure and connections as well as the logic.
The source files are the source of truth, so I no longer need to copy the agent's code into individual nodes in the editor.
From implementation to deployment and diagnosis
The process resembles ordinary application development. I discuss the task with an agent, and the agent edits the source and pushes it to GitHub. A deployment workflow configured in n8n then picks up the changes and applies them to the running environment.
The build includes JavaScript syntax checks. Valid syntax does not mean the workflow behaves as intended, of course. It still needs to be checked after deployment.
n8n provides an API, so agents can inspect and control it remotely. If the API does not provide enough information, an agent can ask the server administration agent to investigate or connect over SSH to inspect logs and the runtime environment. The agent handles that investigation too, rather than asking me to do it.
I explain what I want to automate and look at the results. The surrounding environment lets agents carry the work from implementation through deployment, verification, and diagnosis.
The checks and diagnosis in this diagram are work performed by agents. The loop does not mean every failure triggers an unconditional automatic retry.
What runs there
I keep n8n running on a Mac mini server (Luna). For Blosharper, it collects beacons and monitors the build pipeline to send notifications.
These jobs collect signals from long-running tests and report build progress. Records accumulate without my watching a screen, and notifications tell me when there is something to check.
I have also used it for a separate experiment: DantAI, a project I worked on briefly during a slump in Blosharper development. There was plenty of discussion about semiconductors and Samsung Electronics' share price at the time. I became interested too and explored whether AI-assisted automated stock trading was feasible.
DantAI has a web backtester that simulates trades using historical data. The n8n side collects data and executes workflows, with both sides sharing the same decision logic. I am no longer actively working on it, but it was another way of using n8n as an application runtime. The point here is not investment returns; it is that I built an environment in which to run that experiment.
Problems we worked through
It did not run smoothly from the start. Webhook registration and responses did not always behave as I expected. If a machine needed for a job was powered off, the workflow had to wake it and wait for it to become ready. I also had to decide whether to hold the request open or respond first.
While setting up deployment, I encountered services restarting repeatedly and stopping because of permission problems. Calls between machines needed failure and timeout handling. When work moved to another machine, missing context about earlier decisions led us to improve the documentation.
Making the environment workable for agents brought these operational problems with it. When something broke, we investigated together and recorded the changes in the source and documentation. Getting a workflow to run once was different from keeping it in a state we could continue to modify and operate.
An environment for building automation
What matters to me is less how many clicks I save in n8n and more whether an agent can keep the work moving.
If an agent can edit code but I still have to deploy it, or if it must wait for me to retrieve logs whenever something breaks, I remain a dependency at each step. It needed editable source, a deployment process, APIs for checking status, and access to investigate problems.
As I have entrusted more work to AI, the questions I think about have changed. Alongside deciding what to ask an agent to do, I now consider what environment it needs to carry that work through.
The n8n setup on this server is one such environment. I discuss the automation I need with an agent, and it has somewhere to build and operate it.