2026 Agents Case Study Series Logo
How auditing A.I.N.D.Y.’s existing subsystems led me to discover the runtime underneath the app
In the previous article, Where Does the Work Exist?, I explained how my development workflow gradually moved from conversational AI into the terminal.
I’d spent a considerable amount of time moving prompts from Claude Chat into Claude Code, then carrying implementation reports back into the conversation to decide what should happen next.
Eventually, I noticed I wasn’t doing that nearly as often.
Not because I’d stopped having architectural discussions, but because I was already having those discussions with Claude Code.
And unlike a chatbot working primarily from what I’d provided, Claude Code could inspect the repository while we talked.
That changed how I approached A.I.N.D.Y.
Instead of beginning with a feature request, I increasingly began with an audit.
What already existed?
What was actually implemented?
What did the repository say the system was doing?
And how did that compare with what I remembered building?
Those questions became especially important because A.I.N.D.Y. wasn’t an empty app waiting for me to introduce a new architecture.
I’d already spent months building it.
I Already Had an Application
Before I began integrating the Nodus Runner and Single File Engine, A.I.N.D.Y. already contained a collection of subsystems.
There was the Infinity Algorithm, supported by formulas intended to measure different aspects of performance and progress.
There was the Memory Bridge, which I’d originally thought of as the system’s memory before learning that its responsibilities were closer to memory orchestration: persistence, recall, routing, and feedback.
There was an AI SEO tool, RippleTrace for tracking articles and related activity, a DeepSeek-based code analyzer, and parts of a social media layer.
And there was Genesis, the MasterPlan component that helped users develop plans through conversational interaction.
Genesis had been one of my last significant non-agent development changes to A.I.N.D.Y.
So when I started returning to the application with coding agents, the objective wasn’t to replace everything.
It was to figure out what I already had, what was missing, what needed correcting, and how the different parts were supposed to work together.
Make It Real. Make It Intelligent. Make It Useful.
One of the earliest comprehensive audits had revealed substantial technical debt.
Some capabilities existed only partially. Others had competing implementations or weren’t properly connected to the parts of the application that were supposed to use them.
So before introducing the two larger prototypes, I spent time working through the existing subsystems.
The process generally followed three phases.
Phase 1 — Make It Real.
Determine whether the subsystem actually did what it was supposed to do.
Not whether a file existed with the correct name.
Not whether the implementation sounded reasonable.
Whether the behavior was actually there.
If something was missing, broken, or incorrectly connected, we needed to establish the correct implementation.
Phase 2 — Make It Intelligent.
And by intelligent, I don’t necessarily mean introducing an AI model.
I mean making sure the subsystem could receive the information it needed, process that information correctly, and use the results appropriately.
A scoring system isn’t particularly useful if its inputs aren’t reaching it.
A memory system isn’t providing continuity if the relevant workflows never recall what it stores.
And a subsystem isn’t really integrated if the rest of the application has no way to use its output.
Phase 3 — Make It Useful.
Connect the capability to the places where it was supposed to matter.
Make sure its behavior could influence the application rather than remain isolated behind an implementation that technically worked.
Those three phases became a recurring method.
And the more I used coding agents, the more I began relying on them to help establish what each phase actually required.
Auditing My Own History
Something else was happening alongside the repository work.
I had accumulated a considerable amount of conversational history from developing A.I.N.D.Y.
Those conversations contained ideas, architectural decisions, experiments, and features I’d discussed at different points in the project.
But not everything we’d discussed had necessarily been implemented.
And not everything that had been implemented still matched the original idea.
So I began using Codex and Claude Code to review my saved conversations and compare them with the actual repository.
Some of those reviews revealed additional concerns around automation, agentic capabilities, and freelancing-related functionality.
The process wasn’t simply asking an AI to summarize an old conversation.
I wanted to know which ideas were relevant to the current system.
Which ones already existed. were incomplete or would require new implementation work.
From those findings, we could create implementation plans.
Then I could take those plans back into the repository and work through them using the same three-phase approach.
Make it real.
Make it intelligent.
Make it useful.
There was a lot of back-and-forth between what I’d originally envisioned and what the code actually contained.
And I was learning more about my own system through that process.
Sometimes an audit confirmed that something I’d intended was already there.
Other times, it revealed that I’d misunderstood the responsibility of a component.
And sometimes it showed that the implementation was only part of what I’d thought I’d built.
The Memory Bridge had already been a good example of that.
But the same general problem existed across the larger application.
The Prototypes Finally Had Somewhere to Go
By the time I’d worked through the existing subsystems, I could finally return to the two prototypes that had been waiting for integration.
The Nodus Runner and the Single File Engine.
But neither prototype was intended to replace A.I.N.D.Y.
They represented patterns and responsibilities that needed to be evaluated against the application.
And I’d already established an instruction for the agent:
Do not modify it. Extract the pattern. Rewrite clean.
Just because a mechanism existed inside a prototype didn’t mean it belonged in A.I.N.D.Y. in exactly the same form. And it didn’t mean every mechanism needed to be transferred at all.
Claude Code needed to inspect what already existed, identify where the proposed responsibilities belonged, and determine which parts of the prototypes could be adapted to the application.
The Nodus Runner offered patterns for scheduling, retries, background execution, task registration, and replay.
The Single File Engine offered a model for persistent workflows, execution state, WAIT and RESUME, event routing, and recording outcomes.
But the repository already had its own services and execution paths.
The task was to reconcile those responsibilities, not create a second application inside the first one.
Porting Patterns, Not Copying Code
The integration followed the same general method I’d been using across the other subsystems.
First, establish what needed to exist.
Then make the components work with the necessary information and execution paths.
Finally, connect them to the application so they could actually be used.
For the Nodus Runner, that meant addressing weaknesses in the existing background execution system.
A.I.N.D.Y. could start work, but some of that work was still handled through daemon threads without the kind of durable supervision, replay, and execution history I wanted.
The integration introduced more explicit scheduling, retry behavior, and automation records.
The work wasn’t considered complete simply because a new scheduler existed.
The implementation needed to replace the relevant old behavior and survive the repository’s checks.
One reported milestone was 690 passing tests and zero remaining daemon threads.
The Single File Engine presented a different problem.
Its purpose wasn’t simply to launch work.
It was to preserve the identity and state of work as it progressed through multiple steps.
That led to the persistent flow engine.
Instead of every subsystem maintaining its own idea of what execution meant, the application could begin using shared concepts for a running flow, its current state, its history, and the events that allowed it to continue.
One of the most important capabilities was WAIT and RESUME.
A workflow could stop because it needed approval, external information, or another event.
Rather than keeping a process running while nothing happened, the engine could preserve the workflow’s state and resume when the required event arrived.
That was particularly relevant to an application intended to support human participation in automated work.
The implementation also began connecting Genesis plans to executable workflows.
A MasterPlan could describe what needed to happen.
The flow engine provided a way for those steps to become work the system could track.
And execution outcomes could feed back into the Memory Bridge.
These were not isolated additions.
They were ways of connecting responsibilities that had previously existed in different parts of the application.
By the end of the integration work, the reported test suite had reached 790 passing tests with zero failures and 69.22 percent coverage.
But the test totals weren’t the most interesting part of what happened next.
Because once the prototypes had been integrated, I found myself asking a familiar question.
What had we actually built?
Everything Worked. But Did It Work Together?
That question led to another round of audits.
And this time, the findings were different.
The problem wasn’t simply that a particular subsystem was incomplete.
Two larger issues kept emerging.
The first was cohesion.
Individual subsystems could function correctly in isolation without necessarily operating as one coordinated system.
The formulas worked.
The scoring mechanisms could produce results.
The memory components could preserve and retrieve information.
The execution machinery could run workflows.
But that didn’t automatically mean information moved through the entire application in a way that produced the intended outcomes.
The second issue was the repository itself.
And this one irritated me a little.
Because I’d already spent a considerable amount of time learning how to organize a repository.
I’d been moving files, examining project structures, creating documentation, and trying to make the codebase easier to understand.
Then another audit came along and effectively told me the organization still wasn’t good enough.
But the reasoning was important.
The agent wasn’t merely suggesting a cleaner folder structure because it looked better.
It was identifying an obstacle to future development.
For an agent to work effectively in a repository, it needs to understand the boundaries between components.
What owns a particular responsibility?
Where should a new implementation belong?
Which parts of the system depend on it?
What changes are allowed to affect other components?
And which assumptions need to remain true?
If those boundaries aren’t clear, the agent can make changes that seem correct locally while creating problems elsewhere.
And that was especially concerning in an application with as many interconnected responsibilities as A.I.N.D.Y.
So the audits began driving a different kind of work.
Not simply adding or repairing capabilities.
But reorganizing the repository and clarifying the relationships between them.
The Repository Needed an Architecture It Could Explain
I’d already been creating documentation for a while.
There were repository maps, roadmaps, audits, implementation plans, and reports derived from my earlier conversations.
But this stage was different.
The documentation was no longer only about recording what I wanted to build.
It was becoming part of the process of deciding how the existing system should be organized.
We needed clearer ownership.
Clearer boundaries.
More explicit relationships between services.
And a better understanding of how changes to one part of A.I.N.D.Y. affected the rest of the application.
The agents were helping identify those relationships by examining the actual implementation.
Then the documentation and repository structure could be updated to reflect them.
And the more we did that, the more the audits started describing the system in a way I hadn’t expected.
They kept using language like:
OS-like. Runtime-like.
At first, I didn’t really know what to make of that.
Because as far as I was concerned, I was building an application.
I wasn’t trying to build an operating system.
And I didn’t even have a clear understanding of what a runtime was.
But the description kept appearing.
As we connected more subsystems and clarified more of the architecture, the classification kept coming back.
Eventually, I decided to ask why.
Why Do These Audits Keep Calling This a Runtime?
So I went back to ChatGPT.
Which is somewhat funny considering I spent the previous article explaining why I moved most of my implementation work into the terminal.
But this wasn’t an implementation question.
I wanted to understand something.
Why did these repository audits keep describing A.I.N.D.Y. as OS/runtime-like?
What was it about the architecture that led to that classification?
I brought several of the audit documents into the conversation.
ChatGPT examined the descriptions and pointed toward a few recurring architectural responsibilities.
The kernel-like coordination mechanisms.
The memory system.
And the agent execution infrastructure.
Those weren’t just features sitting next to one another.
They were increasingly responsible for governing how work happened inside the larger application.
And that explanation started making sense when I compared it with another problem I’d been noticing.
The Infinity Algorithm Was Still Just an Algorithm
The Infinity Algorithm had been part of A.I.N.D.Y. for a long time.
I’d developed formulas to measure different aspects of performance, productivity, and progress.
And those formulas worked.
They could receive values, perform calculations, and produce results.
But I’d begun realizing that the calculations alone weren’t enough.
For the larger system to use those results meaningfully, something needed to gather the relevant inputs.
Something needed to determine when the calculations should happen.
Something needed to process the results.
And something needed to make those results affect what happened next.
Otherwise, I could have a perfectly functional set of formulas without a system that actually used them.
The same problem had appeared in different forms throughout A.I.N.D.Y.
The Memory Bridge could retrieve information, but that information needed to become part of execution.
Genesis could create plans, but those plans needed a way to become actionable workflows.
The execution engine could run work, but the results needed to reach the systems responsible for memory, feedback, and future decisions.
And suddenly the earlier audit findings made more sense.
The lack of cohesion wasn’t simply an organizational inconvenience.
It was preventing the larger application from operating as the kind of system I’d been trying to build.
And the repository boundaries weren’t simply about making the code easier to navigate.
They were necessary for maintaining and extending the machinery that connected everything.
I Thought I Was Building an App
So when ChatGPT explained why the architecture kept being classified as runtime-like, I started looking at A.I.N.D.Y. differently.
I’d been thinking of the project as an application with a growing collection of capabilities.
But the more those capabilities became connected, the more I needed something underneath them to coordinate execution, state, memory, and feedback.
I needed the machinery that allowed the different parts of A.I.N.D.Y. to function as one system.
And a lot of that machinery was already beginning to exist.
The prototypes had helped define it.
The subsystem audits had helped correct the existing implementations.
The integration work had begun connecting the responsibilities.
And the later audits had exposed the architectural boundaries that still needed to be established.
I hadn’t set out to build a runtime.
But I could now see why the agents kept describing the architecture that way.
So I made a decision.
Well, let’s lean into that.
Instead of continuing to treat the execution machinery as a collection of features inside A.I.N.D.Y., I began developing it deliberately as the underlying runtime.
That didn’t mean every part of the application suddenly became runtime code.
And it didn’t mean the architecture was complete simply because I’d recognized what it was becoming.
There were still boundaries to establish, responsibilities to separate, and existing implementations to reconcile.
But the direction had changed.
I was no longer only asking how to make the application work.
I was asking what the underlying system needed to provide so that applications, workflows, and agents could work on top of it.
And that was a much larger architectural question than the one I’d started with.
Discovering the Architecture Doesn’t Finish It
Looking back, what’s interesting is that no single AI system made this happen.
Gemini helped me develop the automation prototype.
ChatGPT helped me understand where that prototype belonged and what execution concepts A.I.N.D.Y. was missing.
Codex and Claude Code helped examine the conversational history, audit the existing application, identify implementation gaps, and turn those findings into work inside the repository.
Claude Code then helped adapt the prototypes, connect existing subsystems, and expose architectural problems that weren’t obvious when the components were examined individually.
And ChatGPT helped me understand why those findings kept pointing toward a runtime.
But I was the one bringing those sources together.
I was deciding what needed investigating.
Which implementation gaps mattered.
Which plans to follow.
When the evidence justified moving forward.
And ultimately, whether the direction the architecture was taking was one I wanted to pursue.
The interesting part wasn’t that an AI told me I’d built a runtime.
It was that the process of examining what I’d built gave me enough information to recognize the possibility and decide what to do with it.
And that decision introduced another challenge.
If A.I.N.D.Y. was going to have a runtime, then what actually belonged inside it?
What belonged to the application?
What should be exposed through an SDK?
And how should those responsibilities be separated without breaking the system I’d already built?
That would become the next stage of the work.
Because discovering that I’d been building a runtime was one thing.
Learning how to separate it from the application was another.
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 Promises — How architecture analyses, version control, and AI-assisted evaluation began changing the way I preserved and verified agent-generated work.
- Article 4 — I Built My Own n8n — How an automation question led me to build a runner with Gemini, question its place in my architecture, and begin integrating it into A.I.N.D.Y. with ChatGPT and Codex.
- Article 5 — It’s Just a Conversation — What working across different AI systems taught me about context, tools, execution environments, and why the model alone doesn’t determine what an AI can accomplish.
- Article 6–1 Week to Vibe Code V1 — How my attempt to finish Nodus in a week led me from Codex to Claude Code and helped turn conversational testing requirements into enforceable engineering practices.
- Article 7 — Discovering The Arcitecture — How Gemini, ChatGPT, and Codex helped me discover where the Nodus Runner belonged and begin defining the execution architecture A.I.N.D.Y. needed.
- Article 8 — Prototyping with AI — How I developed a repeatable AI-assisted prototyping method, used single-file implementations to preserve architectural ideas, and worked with coding agents to translate those ideas into existing software.
- Article 9 — Where Does the Work Exist? — How auditing A.I.N.D.Y.’s Memory Bridge with Claude Code changed my development workflow, helped me understand my own architecture, and taught me to evaluate agent-generated work through repository evidence rather than blind trust.
By this point, I’d spent months building, auditing, and connecting the different parts of A.I.N.D.Y.
What began as an application had gradually developed the responsibilities of something much larger. And after repeated repository audits kept describing the architecture as OS/runtime-like, I finally began understanding why.
So I made a decision.
Instead of continuing to treat execution, memory, orchestration, and feedback as separate capabilities inside an application, I would begin developing them deliberately as the underlying runtime.
But recognizing that I was building a runtime introduced another problem.
A.I.N.D.Y. already had an application, existing services, interfaces, and dependencies. I couldn’t simply declare part of the repository a runtime and assume everything would fall into place.
I needed to determine which responsibilities belonged to the runtime, which belonged to the application, and how the different pieces should communicate without becoming dependent on one another’s internal implementations.
In the next article, I’ll explore how I worked with coding agents to decompose A.I.N.D.Y. into separate architectural layers, why that required more than reorganizing files, and how repository audits helped establish the boundaries between the runtime, SDK, UI kit, and application.
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.
Previous Work
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.
Top comments (0)