2026 Agents Case Study Series: I built my own n8n

2026 Agents Case Study Series Logo

I did eventually return to A.I.N.D.Y. Just not in the way I expected.

At this point, I was about three or four days into trying to get Nodus to Version 1 within a week. Everything in this part of the story was happening during that same push.

So there wasn’t really a moment where I finished the language, closed that repository, and said, okay, back to A.I.N.D.Y. Returning to the application was one of the things that happened while I was still working toward that milestone.

The work overlapped. In the same Claude conversation where I was trying to finish Nodus, I started auditing the application I had previously been unwilling to give an agent. Meanwhile, I was using ChatGPT and Codex to go through my saved files and conversations, trying to reconstruct the larger vision behind it.

Then I went to Gemini with a question about automation.

At the time, that seemed like a separate conversation. Looking back, it was the beginning of figuring out that several things I had been treating as one project needed their own responsibilities.

But I didn’t arrive at that conclusion first and then ask the AI to build it. I asked a question, followed the answer, and eventually had to stop and ask what we were actually building.

Why I Added Claude

By this point, I had started using Claude and Claude Code alongside ChatGPT and Codex. The reason was mostly practical: usage and cost.

I had originally been using the $20 ChatGPT subscription. When my usage ran out, I paid for a Claude subscription thinking it would help me keep working.

That was how Claude entered the process. I hadn’t compared the models and decided one was more intelligent or better suited to a particular architectural responsibility. I had hit a limit, looked at what I could spend, and added another way to continue.

Once I had access to both, though, I could develop with both. And one of the things AI makes possible is getting multiple pieces of work moving at the same time. I could keep pushing Nodus toward V1 while also auditing A.I.N.D.Y., reviewing its history, and exploring an automation question.

I still had to connect the results and make the decisions. But I didn’t have to finish every piece before beginning the next one.

Figuring Out What I Had and How to Govern It

The first thing I asked an agent to do with A.I.N.D.Y. was audit it. Before adding more, I wanted to understand what I’d already built and whether the pieces actually worked together.

Claude Code examined the architecture, performance, documentation, bugs, and security. It came back with a laundry list of defects: duplicated routes, missing validation, unfinished modules, and components that existed but weren’t properly connected. The Infinity Algorithm’s core formulas were in the code, but their purpose and relationship to the larger system weren’t adequately documented.

Now, I already had a testing method. I’d add something new, break the app, try to restart it, and work through the bugs until it worked again. But the audit was showing me how much could still be wrong even after I’d gotten it running.

And that raised another question: what behavior should I actually be testing?

The repository could show what had been implemented. To recover what I’d intended, I went back to the saved conversations and documents where A.I.N.D.Y. had developed. While Claude Code examined the application, ChatGPT and Codex helped me work through the history behind the Infinity Algorithm, memory systems, the Monday Node, and the Infinite Weave.

That let me compare what the application did with what I’d built it for. My understanding of testing changed through that work: finding defects, recovering the intended behavior, and seeing what my restart-and-debug method hadn’t caught.

Meanwhile, Claude was helping me think about how to govern the project as it continued. I already had guidance documents, and Claude introduced additional project-discipline documents such as FREEZE_PROPOSAL.md, EXTENSION_PROCESS.md, and VERSIONING_POLICY.md.

I used Claude Code and Codex to create those documents, then used them alongside my existing guidance to govern the repository. We were working through what to stabilize, how extensions should enter the project, and how to handle versioning. The AI was helping me develop the process around the code while also helping investigate and build it.

All of this was happening during the same push toward V1. Several pieces of work could move forward at once, but I was still connecting the findings and carrying decisions between systems. The shared documents gave the work guidance beyond an individual chat; they didn’t mean every AI automatically knew what the others had done.

All of that was happening when I took an automation question to Gemini.

Couldn’t I Build My Own n8n?

The question I took to Gemini was pretty straightforward:

Gemini said yes and explained what I’d have to provide myself: a way to trigger work, connect services, execute the workflow, handle failures, and see what happened afterward.

For context, n8n provides things such as a Webhook node to receive an external request and start a workflow, along with execution records for individual runs. Building my own meant taking responsibility for those pieces.

Gemini offered to start with a simple Python webhook listener, and I accepted.

Now, this is where a familiar pattern started happening. We had the first piece, but once I understood what that piece did, I could see another question to ask.

The endpoint could receive a request. Okay, but what if the work took a while? The service sending that request shouldn’t have to wait for everything to finish. So we added background execution.

Then how would I know what happened after the request was accepted? We added PostgreSQL to record the incoming data, status, timestamps, and errors.

That gave us a history. But now we had to think about who could send instructions to the endpoint, so authentication came into it. Then retries for temporary failures. Scheduling for work that needed to happen at a particular time. Replay so a failed event wouldn’t have to disappear just because something went wrong the first time.

Docker, deployment automation, health checks, and execution analytics followed.

Each addition had a reason. And each answer helped me understand enough of the system to recognize something else it would need.

I had started by asking whether I could build my own automation. Now Gemini was helping me put together a prototype, one follow-up at a time.

All within one conversation.

Why I Called It Nodus Runner

Once the prototype had enough shape, I asked Gemini what I should call it. One suggestion was Nodus Runner.

And within the conversation we were having, that made sense. I was still working toward Nodus V1. I’d just created its repository, then stepped away from it for a bit to work on A.I.N.D.Y. That’s why the A.I.N.D.Y. work was happening in the same Claude conversation as the Nodus implementations.

Gemini also had previous context about Nodus, the coding language. It had been discussing the automation build in relation to that language, and I didn’t yet understand that the new piece belonged elsewhere in the stack. So when it suggested Nodus Runner, the name fit what I thought we were building.

But when Gemini explained the runner’s relationship to Nodus, I had a question:

I was only a few days into the push toward V1, but Nodus already had its own language runtime. It could take source code, compile it, and execute it in its virtual machine. So what was this new system adding?

Gemini said I didn’t need another runtime to make the language run and explained how the runner could be used to trigger, schedule, and coordinate work around that execution.

That helped me understand what we’d built. But I still didn’t know where it belonged in my stack.

After naming it, I went back and reread the entire build conversation. That’s when I started seeing how it might be useful for A.I.N.D.Y. The application had background tasks, but they relied on daemon threads and had no external scheduler. The runner’s persistence, scheduling, replay, and execution history seemed relevant to those limitations.

So I took the prototype to ChatGPT.

Finding Where It Belonged

ChatGPT helped me break down what the runner was and what role it could play in the application. Now we could work through the question in the context of A.I.N.D.Y., rather than continuing to assume the new build belonged with the language because that was where the conversation had started.

From there, we built the companion piece I needed to continue: A.I.N.D.Y. Core Loop v1 — Single File Engine.

The core loop brought together a stateful flow runner, a contract for how nodes executed, and PostgreSQL persistence. It also included waiting and resuming, event routing and subscriptions, memory of event outcomes, a basic strategy layer, governance policies, and an intent-to-plan-to-flow pipeline.

So, for example, we were now dealing with how a flow would preserve its progress, wait for something to happen, and continue afterward. Those were responsibilities I needed to understand within A.I.N.D.Y. Nodus executing a program was its own responsibility.

With ChatGPT and Codex’s assistance, I then decomposed both prototypes-the runner and the core loop-into the A.I.N.D.Y. application.

That was the actual progression. Gemini helped me build the runner and clarify how it was used. ChatGPT helped me understand where it fit in my stack and build the accompanying core loop. Then ChatGPT and Codex helped me integrate both into the application I already had.

I hadn’t started with a finished architecture and assigned each AI a piece. I was learning where the pieces belonged while using the AI systems to help me build and connect them.

Having Context Didn’t Settle the Question

Looking back, Gemini’s mistake was about where the runner fit in my stack. It had context about Nodus, and that context shaped the conversation. The connection sounded reasonable enough that I named the prototype Nodus Runner before I understood its role in A.I.N.D.Y.

That was another thing I was learning: an AI having context doesn’t mean it has the context needed for the particular conclusion it’s reaching. And even when the relevant information is available, it can still interpret it incorrectly.

I knew Nodus already had a runtime, so I could question that part of the explanation. Rereading the build helped me recognize a possible use in A.I.N.D.Y. Taking it to ChatGPT let me work through that possibility with more of the application’s context in view.

The project wasn’t held in one place. There was code in repositories, intent in saved conversations, and new prototypes developing in separate chats. I was still carrying those pieces between systems and checking whether their explanations matched the project I was actually building.

Coding agents gave me more direct ways to inspect and change the repository, as the A.I.N.D.Y. audit had shown. But access to the code didn’t automatically settle the intent behind it, just as conversation history didn’t automatically settle the architecture. I still had to examine how the conclusions connected to the evidence.

The same week I was learning to govern the project and test its intended behavior, I was beginning to learn how to separate its responsibilities.

What I’d called Nodus Runner went into A.I.N.D.Y. alongside the core loop. Later, the execution layer was separated from the application into A.I.N.D.Y. Runtime. Nodus continued as its own language with its own runtime.

Those boundaries would take months to define cleanly. But the work of discovering them was already happening during the push to V1. Through an automation question, a name that seemed to fit, and then the realization that I needed to ask where the thing we’d built actually belonged.

What’s Next?

If you’re new to the series, you can catch up on the story so far:

• Article 1 — I Created a Coding Language — How a simple question to ChatGPT became a programming language experiment, and what happened when I let Codex work on it overnight.
• Article 2 — Chat was Control — How I began directing Codex through persistent project documents, implementation constraints, and a manual agentic workflow.
• Article 3 — What a version promisies — How architecture analyses, version control, and AI-assisted evaluation began changing the way I preserved and verified agent-generated work.

By this point, I was working with multiple AI systems to build, evaluate, and connect different parts of my ecosystem.

But the experience was also revealing something I hadn’t fully understood when I started.

An AI could give me useful architectural guidance about a project and still be wrong about how that project actually worked.

In the next article, I’ll explore the difference between chatbots and coding agents, why access to the actual development environment matters, and how the tools available to an AI can fundamentally change what it is capable of doing.

The next installment of the 2026 Agents Case Study Series is coming soon.

Explore the Projects

The systems discussed throughout this series are part of the Masterplan Infinite Weave ecosystem. While not every project has appeared in the story yet, you can explore the technology, examine the source code, and follow its ongoing development.

• Nodus — The programming language that began as the experiment documented in this series. Explore Nodus
• A.I.N.D.Y. Runtime — The governed execution substrate supporting workflow orchestration, persistent execution, memory, and agent coordination. Explore A.I.N.D.Y. Runtime
• A.I.N.D.Y. Platform — The application platform built on the runtime, bringing the underlying capabilities into usable applications and interfaces. Explore A.I.N.D.Y. Platform
• Masterplan Infinite Weave — The broader ecosystem connecting these projects and their ongoing development.

This series builds on the ideas, experiments, and lessons documented in my earlier work.

• 2025 ChatGPT Case Study Series — The original exploration of learning, building, and executing through sustained human-AI collaboration. Read the Series
• 2025 Duality of Progress Series — An exploration of the relationships between constraints, creativity, iteration, and progress. Read the Series

Originally published at https://www.linkedin.com.

---