Connecting the Dots

Introduction

Recently I’ve been integrating AI into some pipeline development. The goal was to automate some of the tasks I do repeatedly into scripts that process data in a specific way. My goal is to use them to build local systems which will eventually run independently of the harness or model used to create them.

I've done some automations before agentic integration came online, but it involved me connecting a bunch of it. I’d run scripts with a limited focus, piece together customizations, add images, update metadata, draft, edit and QA much of it manually.

In my system, text files became Markdown files. Markdown became HTML. I added images, updated metadata, checked the output and carried everything forward.

Having spent much of my career working closely with developers — shaping products, working through behavior and structure and translating between creative and technical priorities — it is liberating able to build more complicated systems myself.

Editorial illustration of a looping workflow between a conversational assistant, script testing and local files.

1. ChatGPT

Initially, I got a few basic automation pipelines going with ChatGPT. Describing what I wanted, I would then iterate on the scripts ChatGPT produced, pasting them into place, testing the output and repeating the process until it did basically what I wanted it to do.

While it worked to a certain extent, I was still involved a lot and connecting everything myself. The individual parts were becoming more automated. However, the larger process was not.

Editorial illustration of a software architecture organized like a building with folders, scripts, tools and roles.

2. Codex Takes Over

Recently, I have been using Codex to build more integrated systems. It's great being able to give it access to a local project folder, set some boundaries where it can operate and let it inspect files, modify them in place and run more integrated processes with them.

As an early experiment, I started testing the capability by asking it to rename my recent photograph archives with a date and timestamp while using a visual parser to semantically name the files. Having just come back from vacation, this would help me intake my latest photos better than a random numbered list like DJI0001.jpg, DJI0002.jpg, .... Instead it could produce something like 20260714-MKE-Domes-Selfie.jpg.

I had seen a YouTube video about setting this up as a script action, but decided to see if Codex could handle it. I was pleasantly surprised.

Next, I had it start on another idea. It was able to set up the file architecture, help me establish and implement specialized skills, create records and associated Markdown files, scripts and reference banks, ingested local files and directories and categorized everything for an integrated build—the way a software system might do so.

One key function I have come to want is to maintain a narrower task or project focus between threads while retaining integration between them. This is important so I don’t have to continuously paste between threads, which turns me into a potential bottleneck for continued progress and development.

Editorial illustration of temporary conversations being distilled into persistent records and team roles.

3. Down the Rabbit Hole

As I got further into development, I started wanting greater levels of transference and persistence between sessions, and turned that into documentation protocols and build archives which could create a trail showing the trajectory of the project.

Some of this included wanting to reference date and timestamped archives of my own chat and prompt history. For example, how could I keep a record of my interactions with an AI and leave a trail of breadcrumbs if I used a different handler or model to analyze, assess, troubleshoot or even take over when the preceding one ran out of tokens or hit a limit on quota.

On a phone call with my brother, who is a talented software developer, he told me about “his team” of 26 concurrent instances of Claude, each running different processes and communicating with the others. I wanted my own team.

So, I started setting up parallel threads on the same project, each focused on a different aspect of the development. Or the design of the development. Or the integration of the two. I wanted managers talking to one another so I didn’t have to paste between threads, while they transferred vastly more data faster than I could.

Editorial illustration of a queue reaching a turnstile as the available token supply runs out.

A pipeline is only as continuous as the service beneath it.

4. Denied

As I spun up multiple teams running parallel threads on several projects, I found myself hopping between them, authorizing actions and becoming a bottleneck because my “managers” were only taking their instructions so far. I had to authorize them to download parsers, install tools and toolkits, still keeping the balls rolling in each thread. Sure, I had a manager watching open processes and informing me if something needed attention. But I had to authorize everything in the end. Still, at least the threads were communicating.

After starting a few new projects the same way, I burned through all of my Codex tokens for the week. It was the first time I had run through any quota on my ChatGPT account. I had found the wall. But, I had barely gotten started for the day, so I tried adding paid credits to keep the ball rolling.

Less than two hours later, those were gone too, which got my attention. I needed to understand how quickly the system was consuming resources, what sustained use would actually cost and how I could get around this single point of failure.

Okay, think fast. What next?!

Editorial illustration of a cloud architecture translated into three local manager applications.

5. ChatGPT (Again)

As a fallback and to keep development moving, I went back to ChatGPT Classic and set up duplicate manager threads there to intake the project where Codex stalled and plot a new way forward.

Using Classic, I was able to download ZIP files and extract them, placing files manually or running scripts in Terminal to install and move them automatically.

Thankfully, it could understand the project structure created through the Codex development. I zipped most of the project architecture and uploaded it. Now, however I have duplicate threads in both apps. But progress must continue.

Editorial illustration of a person waiting through several stages for a software response.

6. Throttled

Back in a more manual workflow, I was placing files within an increasingly interconnected architecture, running scripts, testing and carrying messages between threads. It was maddening.

Here I was again doing work the AI could have done. The individual steps were simple, but so mundane and tracking everything across parallel developments was a challenge.

After getting the roles and thread priorities straight, the process seemed straightforward but much more piecemeal. Now it felt like this update needed oversight of its own. This was where Codex’s ability to see the local directory, modify files in place and communicate between its own threads had been so powerful.

Local Python

Considering the token limitations, I had decided to change direction, instead using ChatGPT to translate the system I had established with Codex into a local, Python-enabled architecture.

I still focused on persistent roles and records, charters and canonical Markdown files outlining the behavior of each vertical. That way, when I could jump to a different system or process, I would have documentation for the next system to learn what I was trying to do.

As recently as mid-August, daytime responses were taking approximately two minutes from sending a prompt to receiving a response.

0<30s: For the first thirty seconds, the app appeared stalled with the macOS beachball spinning. The submit button floated somewhat offscreen, almost outside the app window, as if it were about to crash.
30<60s: Still sending and beachballing, with a white screen and blue dot.
60<90s: Thinking. Analyzing....
90<120s: Then, after up to 2 minutes it responded.

With multiple threads, keeping everything going felt like a juggling act.

Editorial illustration comparing large, medium and small local AI models as specialized toolboxes.

7. Local AI with LM Studio

The ChatGPT throttling and Codex development interruption exposed another bottleneck and point of failure. If I could bring more of the process local, I could create more predictable capacity and parse basic parts of the system with local, open source models, reserving the token-hungry frontier models for work that actually needs their cutting edge intelligence and power.

LM Studio is a native Mac app that allows users to download and run models from their computer rather than over the cloud.

Having used LMStudio a bit before, I began evaluating three local models with different capability and performance profiles:

Coding: A coding-focused model around 30B parameters.
General Purpose: A similarly sized, more general-purpose model.
Mobile: A smaller 9B model for faster, lighter and mobile friendly tasks.

Editorial illustration of AI models and media files overflowing from a local storage drive beside a backup clock.

While many local models are free, they still occupy large quantities of physical hard disk space. (Click to open larger image in a new tab)

8. File Management

As I downloaded the recommended models just to try them, my disk filled up. Each one—and I already had others downloaded—was multiple gigabytes.

Unfortunately, I had also recently backed up photos onto my hard drive while on vacation. So my disk already contained backups and temporary archives, along with several other large LM Studio and AI models.

After some transfers, I made enough space to finish downloading the remaining models. Then I heard about Bionic, an app that runs with LM Studio for local agentic development. I downloaded that too and started working to get it all hooked up.

Editorial illustration of tasks being sorted into scripts, local models, cloud models and frontier intelligence.

9. Model-Aware Development

I mentioned this briefly above, but considering how real token burn is, I am thinking more carefully about how to use the different systems for what each does best.

Frontier models and agentic services such as Codex or Claude Code may be appropriate for more intensive development. Deterministic processing can move into local Python scripts and automation, while local models running through LM Studio can handle tasks that benefit from inference, analysis or generation. Python can act as the connective layer between them, allowing different parts of the system to use different capabilities depending on what the work actually requires.

So, with each part of the process asking for a different balance of intelligence, access, speed and expense, the emerging question becomes "How can we create systems using these platforms of differing capabilities to create robust tools with their own strategic advantage?"

Editorial illustration of one agentic pipeline branching into blogging, career, time-tracking and interactive-tool workflows.

10. Full Circle

Without agentic integration, some related development slowed. Luckily it was not a time-sensitive or critical experiment so in the interim I could focus on other things and wait out my credit turnover. With access restored, I returned again to Codex to refine and integrate the system—with the new direction, no longer using Codex as its only runtime operator or environment.

The goal remains a self-contained, process-driven automation that can handle as much as possible without requiring an AI model at every step, with parsers, a scannable knowledge bank and sophisticated value functions to monitor quality, along with automated process-driven QA and qualitative refinement.

So, I have come full circle, but with a different direction and a much clearer idea of what should remain local, what needs a model and what documentation has to survive when I switch between them.

Editorial illustration of a creative technologist considering a connected software constellation with room to grow.

Conclusion

This process is exciting to explore, especially considering the speed and scope of what is possible now. However, it has not been a smooth road forward. Certainly, beyond simply being able to code, what an agent can do with deep but still bounded access to a project is extremely powerful. It can setup or understand an existing file structure, work from best or guiding principles and modify a system in place without requiring every instruction to be pasted and handed off manually between threads.

At the same time, these products are changing noticeably in real time. I'm suppressing an extreme rant, but watching ChatGPT and Codex morph and change between uses was very disruptive. Interfaces shifted, capabilities moved between surfaces and familiar workflows behaved differently from one version to the next. At one point Codex literally disappeared off of my machine after I quit the app one night. (?!!!) The more that happened, the more important local portability became.

There is still tons to explore: frontier-model capabilities, project guide files and settings, persistence, communication between threads and documentation that allows another system to understand the architecture and its intentions.

For now, it’s becoming a hybrid process. Some parts are local, some parts are agentic and there are still parts that require me to push buttons. But recent development has already proven usable and definitely shows promise for improvement.

Lastly, I'm curious how other people are coming up with systems for persistence between sessions and threads, inter-thread communications protocols and other kinds of model or platform based silo'ing you might be doing. Have you found yourself experiencing any of these same issues? Do you have different concerns? Reach out on social media (links below) with any comments or questions.