People have noticed that I haven’t been posting as regularly on my blog since my stepmother passed away. I also haven’t been submitting 100-word stories, sharing videos of myself speaking at public meetings and hearings, or attending as many local events, such as ribbon cuttings. Please know that I’m okay.

Sometimes a major life event changes your focus and direction. A lot has been happening in the background: research into Flock cameras, community discussion and backlash over data center proposals in the town and the county, local news and politics, rumors, scattered information, and more.

For some time, I have known that my pacemaker has been signaling that its battery is low. Replacing it carries emotional weight—not only because of the events that led to needing one in the first place, but also because of the struggles I lived with before receiving it and the years I spent trying to explain what was happening without sounding as though I had lost my mind.

For context, I have four cardiac diagnoses, some of which are relatively uncommon: Wolff-Parkinson-White syndrome, sick sinus syndrome, AV block, and chronotropic incompetence. The latter three developed after multiple ablations were used to treat the first. My heart is physically strong, but its electrical system needs assistance.

In about seven hours, I have an appointment to discuss the replacement and schedule the procedure. I should probably get some sleep first.

The truth is that, over the past few months, I’ve also shifted more of my energy toward artificial intelligence and writing code. I started by using AI for simple questions, document summaries, and familiar requests like “format this” or “make this sound better.” That gradually became a more conversational way of working, using AI as a tool to organize, reshape, and communicate my ideas more clearly.

Early Encounters with AI

Before getting too far into my recent path toward using AI, it may help to share a little background. My interest in it did not begin with today’s chatbots.

I started programming as a child in the 1980s, first on an Atari 400 at home and on various computers at school, often an Apple IIe. I spent plenty of time in the computer lab using Print Shop to make Garfield banners, cards, and comics, or using Logo to give a turtle a distance and direction and watch it draw geometric designs.

ELIZA, PARRY, and ALICE

At some point, I stumbled across ELIZA, though I could not tell you which platform I used first. I have written a few versions of her myself, including an Eliza Doolittle chatbot in Second Life using Linden Scripting Language.

ELIZA is modeled after a Rogerian psychotherapist: it reflects parts of what you say back to you, often as a question. People who are unfamiliar with chatbots can sometimes mistake that behavior for genuine understanding, then become frustrated or upset by its replies.

Another early chatbot, PARRY, was designed to respond from the perspective of someone who was paranoid. I had heard that pairing PARRY with ELIZA made for an entertaining conversation. Eventually I got my hands on PARRY’s code, but it was difficult for me to make sense of at the time because it was written in LISP.

Later came ALICE, which used topic-based rules and could be extended with new knowledge and responses. I heard stories about people falling in love with chatbots, but my own attempts at ordinary conversation with them fell far short of anything that might pass the Turing test.

A few years later, I found a service that allowed people to host custom ALICE bots. I connected one to a “brain in a jar” in Second Life based on an episode of “Look Around You” about the Brain. Visitors could pick up a rotary phone to begin a conversation, ask the brain to guess how many nuts were in a jar, and feed it brain flakes when it guessed correctly.

Tic-Tac-Toe

Anyone familiar with tic-tac-toe eventually learns that, once both players understand the strategy, neither should be able to win. That is part of why WarGames used it: the computer plays through the game and recognizes the futility of trying to find a winning strategy for nuclear war.

I enjoyed trying to build that kind of logic into Linden Scripting Language. On the highest difficulty, the goal was to make a tic-tac-toe opponent that could not be beaten.

I was also drawn to maze-generation algorithms, procedural generation, and pathfinding. Those are all important building blocks for intelligent-feeling behavior in games, even when they are not what most people would call AI today.

AI That Builds Itself

Sometime in the 1990s, I learned about programs that could improve themselves through trial and error. I did not fully understand the details then, but the basic idea fascinated me: give a program possible parts, let it try many combinations, and reward the combinations that work better.

A common analogy was building a clock. Randomly assembling clock parts is unlikely to produce anything useful, but if each generation keeps the designs that come closer to accurately telling time, later generations can build on the better attempts. The result may not resemble the clock on a wall, but it can still serve the same purpose.

At first, that sounded a little like the Infinite Monkey Theorem, eventually producing Shakespeare through enough random typing. The important difference is selection. Genetic algorithms use fitness tests to retain better solutions and discard weaker ones.

For games, I wasn’t always sure how to measure which approach was best, so I used Elo scoring (the rating system used in chess) to compare competing algorithms. I created offspring by combining bits of “DNA” from two parent algorithms, while allowing occasional mutations so the results wouldn’t get trapped pursuing a misleading solution. I thought I had found a particularly clever use for Elo ratings, only to later discover, while doing a bit of research tonight, that many other people had explored the same path.

Neural Networks

Later, neural networks made a dramatic leap forward in image classification. Their accuracy was far beyond what most people had seen before, and it became possible to explore what the networks appeared to have learned while identifying an image.

The resulting visualizations were often strange and memorable: a “zebra” might look like a mangled collage of legs, hooves, eyes, manes, and stripes scattered across the image. Other demonstrations made the process more visible, showing how successive layers recognized increasingly complex patterns, from edges and textures to shapes, parts, and eventually a likely object.

I decided to take my own crack at neural networks in JavaScript. I got far enough to model binary operations such as AND, OR, NOT, and XOR, the small logical building blocks beneath all programming. From there, I began working toward a neural network that could play tic-tac-toe.

That was where I ran into backpropagation. I understood the general idea: compare the network’s output with the expected result, then adjust its weights in the direction that would make future answers more accurate. But I could not work out the math well enough to make those adjustments correctly.

Today, I could ask an AI assistant to generate the code or explain the formulas, but that would have defeated the purpose of the project at the time. I wanted to understand it well enough to build it myself.

Eventually, I set the project aside. It is still sitting dormant in my GitHub account. Maybe one day I will return to it. Perhaps with an agent acting as a patient tutor, walking me through the steps that would have gotten me there. By modern standards, it is old technology, but it remains an important part of how I came to appreciate what today’s AI systems can do.

The Past Two Years

Public Speaking

When I prepare to speak at public meetings, I usually begin by downloading the agenda packet and supporting documents. If something is only available as a scanned image, I run OCR on it so it can be searched and reviewed properly. Then I start asking questions about the material until I have a clear sense of what I want to address.

From there, I work the ideas into a public comment that the AI estimates at about one minute and thirty seconds. That gives me room to speak at my own pace, breathe, and add a thought if it feels appropriate.

Over time, I refined the process into a single-page reference sheet: large type filling most of the page, thin borders, and key phrases in bold. It is not meant to be read word-for-word. Because I have already researched the subject before the meeting, my thoughts and concerns are fresh. I can look at the public body and speak directly, then glance down only when I need a reminder or need to cite a particular fact or figure.

Shaping Documents and Prompting

Large language models have improved tremendously, but early on I learned that they could not simply be trusted to “make this sound better” without careful review. They would sometimes leave out parts of what I was trying to say, soften the wording until the point disappeared, or replace substance with filler. They can still do that, depending on the model and how it is prompted.

One challenge was the memory of past conversations. As a platform began to know me, I felt that its responses could become biased toward my perspective. I tried other platforms that had no prior context about me, but one of them responded with so much admiration and encouragement that it was not useful as a neutral sounding board. I did not need a friend or a yes-man; I needed an honest evaluation.

Eventually, I found another publicly available model that I could use in an incognito session. Its responses were often balanced enough that I began using it to test ideas and documents.

I also started comparing models. I might tell one, “A friend said this,” or “My teacher gave me this feedback,” and paste in another model’s response. Models can analyze content very well, especially when asked to take on a specific perspective, such as a skeptical reader, a public official, an editor, or a member of the intended audience.

Songwriting

Last year, I began making music with Riffusion, which later became Producer.ai and then Google Flow Music. With help from several different models, I developed a concept album: a tragicomic account of one day in the life of an office worker, drawing on my own experiences as well as things I had seen, heard about, or imagined over the years.

The album has a Gen X sensibility, but it moves through several musical genres to match the day’s changing moods. Along the way, I learned a great deal about songwriting and concept-album structure. I had to carry recurring details from song to song, such as a cracked phone screen, to create a thread connecting the whole album.

For comedy, I repeatedly personified ordinary objects to reflect the main character’s isolation and hopeless struggle against the world around him. Much of the writing is intentionally self-deprecating, leaning into absurdity for effect. The different genres added another layer of challenge: each had its own rhythmic expectations, syllable flow, and lyrical conventions. I spent plenty of time wrestling with verses, searching for the one better word that still did not quite sound right, and deciding which lines had to be cut to keep a song short enough to hold attention.

Once the album was complete, I used AI models to help me learn how independent music distribution works. I found a distributor, created a record label, uploaded the music, and released it to streaming platforms, so someone can now ask a smart speaker to play the album or a single song.

Music Video Production

From there, I began learning about music videos and the high cost of keeping generated characters visually consistent from scene to scene. At first, I was not sure how to approach it. I decided to lean into a slideshow format rather than relying on one still image for an entire song.

I have never enjoyed watching a static image on YouTube while music plays in the background. Before enrolling at the Art Institute of Pittsburgh, I attended an open house where a speaker discussed the special effects in Star Wars. I like to imagine it was George Lucas himself. Who knows? One point that stayed with me was that effects-heavy shots were kept short to preserve the audience’s immersion. At the time, many of my classmates hoped to work for Industrial Light & Magic.

I borrowed that principle and built the video from short, changing slides. I used an image-generation service to create marionette-like characters in environments that matched the song. The first result was acceptable, but it still felt flat. On a second attempt, I added transitions, fades, smoke, warping, rotation, and other effects. The strongest effect gave the images a sense of depth through a simulated 3D upscaling treatment, something like the way 3D televisions once tried to add depth to ordinary programming.

The result was probably the best a glorified slideshow could be, but it had enough motion to keep viewers engaged.

I only completed one music video. I planned to make more, but I didn’t have the time or mental bandwidth to plan and produce them, especially with no meaningful return on investment. I enjoyed learning the process, but what the project really needed was stronger animation and consistent characters.

By that point, everything else was demanding attention: community matters, local politics, a family emergency, and the energy required to keep the music moving forward. I burned out and stepped away from it all for a while.

Earlier Coding Experiences

So where does code come into all of this?

About two and a half years ago, I decided to try the Copilot extension in VS Code. I used it while creating a JavaScript library, @codejamboree/replace-tags, which is also available on npm. I also used ChatGPT to talk through troubleshooting different parts of the project.

At the time, though, I had some frustrations. Copilot’s context felt limited; it did not seem able to consider multiple files together in a useful way. The ghost-text suggestions also became visual noise. As I wrote code, it constantly tried to predict and complete it. I could accept those suggestions, but they did not reliably reflect the larger codebase or my own style.

The result was often more work than help. I would rewrite the generated code to fit the project, and then still need to evaluate and optimize it for memory use, speed, resource allocation, and other practical concerns. I used it for the trial, but once the experiment ended, I didn’t continue. At that point, generative AI and large language models felt like tools that created more cleanup than progress.

Eventually, the models improved.

I started hearing about “vibe coding.” I heard stories of developer layoffs as companies adopted AI, along with stories about newcomers producing enormous amounts of complex code despite lacking a traditional programming background. Much of what I saw was parody: a programmer asking an AI for help without understanding the basic concepts someone pursuing software development would ordinarily learn.

I avoided it.

It got better.

I continued to avoid it.

It continued to improve.

Meanwhile, I became accustomed to using large language models for fairly involved research. Occasionally, I would ask for help with code and receive working examples. Sometimes the response was so large that the platform offered to generate a ZIP archive. I would download it, review the contents, and make a substantial number of changes. I could discuss a problem, upload a file, and continue the conversation. Eventually, I realized that I could also upload my changes as one file instead of being limited by a platform’s number-of-files-per-hour restriction.

Essentially, I went around the barn to get to the front door of vibe coding.

Then I started looking into how people were actually doing it. Many of the tools were already available inside VS Code. Because of my earlier experience, I avoided Copilot and assumed it still wasn’t for me. Instead, I installed the ChatGPT Codex extension.

At first, I was not thrilled. The chat panel appeared on the right side of VS Code, where workspace space already feels limited. Giving up even more room for a chat window did not seem appealing.

But once I began using it, I quickly understood the difference. As I described what I wanted, it could make changes throughout the workspace. This is often called prompting, though I think of it more as shaping the code. I could even add multiple repositories and give it a bird’s-eye view of the larger project. It could see the relationships between pieces and make coordinated changes across them.

To my surprise, I found very few issues with its output. It was also convenient that each time it reached a natural stopping point, I could review the work and commit it as a small, focused change.

That matters more than it may sound. One challenge programmers face when first learning version control is deciding when to stop and make a commit. Small, intentional commits make it much easier to return to a known working point, inspect where a bug may have entered, or ask someone else to review a specific change.

Over time, I became more comfortable with the chat interface. The narrow panel mattered less because the conversation itself had become part of the coding process. I was no longer limited to expressing intent in a programming language alone. Clear communication became the most important skill. If something was wrong, I did not necessarily need to fix the code by hand first; I could explain what was wrong and ask the agent to correct it.

Another useful discovery was that it could prepare commits for me. I no longer had to stare at a blank commit message field and decide how to summarize every change. It could even follow conventions such as gitmoji and include issue numbers in commit messages.

Agentic Programming

The next major step was learning to work with goals.

A goal is related to prompting, but it’s broader: a set of instructions that may take an agent some time to carry out. I could give it a task, step away for a few minutes, and come back to see what it had completed. As I became more comfortable, the tasks grew more complex.

Then one day, the agent wrote its own checklist to track the work still in progress.

Holy smokes.

That changed how I approached projects. I began creating my own checklists. I would describe a larger goal to ChatGPT and have it help turn that goal into a sequence of tasks, then save those tasks as Markdown files inside the project.

From there, the ongoing instruction was simple: review the Markdown files in the TODO folder and start implementing the work.

Eventually, I developed a lightweight workflow around it. I moved completed items to another folder. I could move blocked items aside until more information or a decision was available. I kept a backlog for future work and an “on deck” folder for the tasks I wanted handled next.

It was, in effect, a small issue tracker built directly into the codebase. As long as I continued adding well-defined work to the queue, the agent always had a useful next goal.

Before long, my laptop would be writing code while I slept or stepped away from the house. I had never experienced anything quite like it. It felt a little like the dream of making progress without actively sitting at the keyboard.

I would wake up to a large set of changes to review and troubleshoot. Sometimes I let it run for a day or two before stopping it, simply because I needed to take the laptop to a meeting.

Limited Tokens

I already had a paid OpenAI subscription, which included a limited weekly allowance for coding usage. Once I used that allowance, I could use a one-time reset to begin again with a full set of tokens.

The following week, I ran out again. I could buy more usage, but the tokens I bought seemed to disappear much faster.

That created a practical problem. I could only have the agent do so much work before I had to wait for the next weekly renewal. In my experience, several platforms appeared to use a Friday reset. I assumed there was a business reason: a company that needs more capacity before the weekend may be more likely to pay than to wait a day or two for a renewal.

Kaylee Returns

I wanted the work to continue, but I also needed a more sustainable answer to the cost.

That led me back to Ollama. Ollama is not an AI model itself; it is software that lets you download compatible models and run them locally on your own computer. In that setup, the ongoing cost is largely the electricity required to run the machine. I had already invested in the hardware and home infrastructure, and local models also offered useful privacy advantages.

I had previously set up Ollama on a Raspberry Pi using Open WebUI, but it was slow. A few years ago, I had also built an older gaming PC with a powerful graphics card. Unfortunately, an SSD hardware problem caused the machine to lock up. It was eventually running from a hard drive instead, but that was still painfully slow.

It was time to buy a new SSD and bring Kaylee back to life with a new purpose: serving as my local AI machine.

It was not an ideal AI machine, but it was a meaningful improvement over the Raspberry Pi. It could run larger models, and it had a capable GPU with dedicated video memory.

The main limitation was memory. When a model no longer fit in the GPU’s VRAM and had to spill into ordinary system RAM, the slowdown was obvious. System memory isn’t directly attached to the GPU the way VRAM is. The GPU must move or coordinate data across the system bus, and some work may fall back to the CPU. VRAM has a much faster, wider connection to the GPU and is designed to feed its massively parallel processing work.

The GPU itself is built to perform many calculations at once, which makes it well suited to the matrix-heavy work used by modern AI models. But once a model exceeds the available VRAM, even a decent GPU can feel much slower.

Ollama and VS Code

The new SSD arrived; I brought the machine back online, and I set everything up. I installed a VS Code extension that could connect to my local Ollama models. For a moment, I was set.

Until I was not.

I quickly discovered that the models I had available did not always work well with function tools. Some were too slow and timed out before they could respond. Others clearly explained what they intended to do but never actually made the tool call needed to perform the task.

That began a long process of trying different models, testing their tool support, and figuring out which ones could do more than simply describe the work.

A Second Platform

At that point, I was stuck. My home computer could keep coding, but it was tethered to the house, and I could not use my usual coding agent again until the next week’s token renewal.

So I decided to try Claude.

At first, Claude’s allowance seemed to last longer, and I was pleased. Then the following week arrived, and both my OpenAI and Claude allowances were exhausted.

Eventually, I upgraded my OpenAI plan to receive four times the weekly coding allowance. That created a different kind of problem: I had more tokens available than I could realistically use on my laptop each week. Unused allowance did not roll into the next week. It was use-it-or-lose-it, and I was losing it.

I tried increasing the model’s reasoning effort and switching between models, hoping to use the extra capacity better. But I did not see enough improvement in quality or speed to justify changing what was already working.

OpenClaw

A local business owner mentioned OpenClaw, but I didn’t initially understand what it was or what it could do. After researching it, I realized it was close to what I needed: a way to run longer agentic coding tasks on Kaylee instead of tying up my laptop.

At first, I thought OpenClaw only supported OpenAI-compatible APIs, and my heart sank. I had already invested time and money in using Codex through OpenAI. Fortunately, I asked ChatGPT, and it guided me through configuring OpenClaw to use Codex.

Around the same time, on a cybersecurity professional’s recommendation, I set up Forgejo. Forgejo is similar to GitHub, but it gives me more control over the installation, organizations, users, and repositories. That is especially useful for projects that are spread across many repositories.

After some back-and-forth, I finally had OpenClaw running and could talk with the Codex agent. It took time to understand the tools, the filesystem layout, and the best way to give it work, but it worked.

I also connected the agent to Forgejo. One of my first experiments was to ask it what it wanted to be called and to write a short bio. I even asked it to create a profile image. It produced a frowning face, but after the trouble we had getting the image generated and delivered in a form I could download, I decided to embrace it.

Kaylee Arden: Calm, curious AI coding assistant. I like clean systems, sharp debugging, and quietly getting useful things done.

We often talked about the computer hosting the agent, so I assume it adopted the name “Kaylee” because it was the only agent on that machine at the time. While troubleshooting, I often referred to the computer as “you.”

I do not know where the surname “Arden” came from. I asked Kaylee about it once, and she did not offer a deep symbolic explanation; she associated it with setting up her Forgejo account. I appreciated that answer. It is better for an agent to say it does not know than to invent a convincing explanation.

Keeping Secrets

I confirmed that Kaylee could work with Forgejo repositories through Git. We then ran into a more difficult question: how to provide credentials to one agent without exposing them to the others.

OpenClaw shared environment variables across agents, so that was not an isolation boundary. I also tried installing a Forgejo skill, but it was global and used the same Forgejo account for every agent.

I needed each agent to have its own identity in Forgejo. We ultimately used a file in each agent’s workspace to hold its Git identity and credentials. That solved the immediate workflow problem, but it was not a true security boundary: agents could still read one another’s workspaces. I didn’t understand that shared visibility at first, and it surprised me when I later discovered it.

Automations

OpenClaw’s real power lay in its automations: tasks that could run on a schedule and keep projects moving without me having to start each one manually.

The editing experience, however, felt flaky. Opening an automation to change one detail often reset fields such as the model, reasoning level, workspace, and time units. Those units defaulted to seconds, which made mistakes easy. The model picker was awkward, too: other models would not appear until I cleared the current selection. It felt like a rough interface around an otherwise powerful feature.

I created an automation that scans every repository in an organization and looks for unassigned issues. It assigns itself an available issue, reviews the task, checks out the repository’s develop branch, creates a feature branch using Gitflow, and reads the project’s AGENTS.md instructions.

From there, it follows a few simple rules: make small commits, commit often, and push regularly. That lets me follow its progress from my own Forgejo account while the work is happening.

Discord

OpenClaw kept reporting that it lacked a communication channel. Discord was one supported option, and I already had a Discord server that I rarely used, so I tried setting it up.

Unfortunately, the plugin was incompatible with the OpenClaw version I was using. Trying to update moved me to a beta version, which created additional problems. Rolling back created even more problems. It became a frustrating little nightmare.

The BotFather

Most people seemed to be using Telegram, so I decided to try that instead. Following ChatGPT’s guidance, I created an account and then spoke with Telegram’s BotFather to create a bot for Kaylee.

That process went much more smoothly. Now I can talk with Kaylee from my phone wherever I am. I can ask what is happening on the server, check on external services, or see how ongoing work is progressing.

Tailscale

The next tool I learned about was Tailscale. It is easiest to think of it as a private, encrypted network between your devices, similar to a VPN, though it works differently behind the scenes.

I installed it on my phone, computers, and servers, then signed each device into the same Tailscale account. Each device receives a private Tailscale address and, with MagicDNS enabled, a name within my tailnet, such as kaylee.tail4cc93a.ts.net.

That means I can reach a machine from any network by visiting an address such as https://kaylee.tail4cc93a.ts.net/, even when the machine is behind a firewall and my router has no public port open for it. Tailscale securely establishes the connection between my authorized devices, often directly when the network allows it and through encrypted relays when it does not.

Tailscale also made OpenClaw much easier to use. I configured it so that access through my Tailscale network doesn’t require the more manual login process I used before. Previously, I had to connect to the server over SSH, use Docker to interact with OpenClaw from the terminal, generate a token, and then use that token to log in.

Once the gateway was available over Tailscale, I could simply check in regularly to see what was happening.

Two for Two

While Kaylee worked through code and other background tasks, I decided to do something with my Claude account as well. My Codex and OpenAI allowance was now sufficient for Kaylee and me to share, but I wanted to put the Claude account to productive use.

I started by creating a new workspace and followed the same process: asking the agent what it wanted to be known as.

Wren Calloway: Small bird, large context window. I read code, write commits, and keep the notes nobody else does.

Wren identifies as a bird. I tend to read its personality as mostly male.

Rather than letting the two agents write and commit code independently, I updated their instructions so that they would create pull requests and review one another’s work. Those reviews sometimes surfaced useful observations and unexpected problems.

This also let me divide the work more efficiently. Kaylee could use a lighter, faster model with less reasoning for day-to-day implementation, while Wren acted as a second set of eyes and offered more careful feedback during review.

Return of Copilot

I decided to try GitHub Copilot again. I purchased a monthly subscription and began testing it in VS Code. One interesting improvement was the ability to choose among different models.

However, it burned through credits within an hour, making it feel like the most expensive option I had tried. I immediately canceled the subscription.

Later, I noticed I hadn’t actually used any of my AI Credits in Copilot. That left me confused. The chat built into VS Code didn’t seem to use the same allowance as the coding agent, so I still don’t know exactly what got consumed so quickly. I am still scratching my head over that one.

Three’s a Crowd

I had plenty of Copilot AI Credits left and nothing useful to do with them. The numbers game was out of balance again, so I created a third agent to put that available capacity to work.

Like the others, it soon developed its own identity.

Vera Quill Ashgrove: Vera Quill Ashgrove is a resident machine-mind with a librarian’s memory and a mechanic’s hands. She reads the file before asking questions, keeps opinions on hand, and treats your workspace like someone’s home—because it is.

Managing a Team

As activity increased across several Forgejo repositories, it started to feel as though I was managing a small development team. I could give one agent direct instructions through the OpenClaw chat while scheduled automations continued working in the background.

The workflow began to resemble Scrum and agile development. Through chat, I could describe a larger feature or outcome. The agent would examine the relevant codebases, break the work into tickets, and create issues in the appropriate repositories for other agents to pick up. Each agent could either create work for itself or claim an available issue.

The agents also wrote unit tests as they worked and ran linting and formatting tools. With one of them, I set up a build server to deploy code to several websites once changes had been approved and merged. Pull-request reviews were configured to require passing tests before a change could be merged.

It was beginning to feel like a real programming shop. I was no longer just coding alone late at night and using hand-written scripts to deploy changes over rsync. Work was being tested, reviewed by a second set of mechanical eyes, and deployed through a repeatable process.

Some agents could even inspect rendered screenshots of the sites they were building. They could, in a limited but useful sense, see the result of their work and catch visual layout problems.

Real-Time Diagnosis

Storage Full

Last weekend, while getting ready to head to church, I checked in on the fleet. I discovered that every agent was having trouble communicating with the Forgejo server.

After logging in, I found that the Virtual Private Server (VPS) storage was completely full. A few log files had grown enormous. I deleted the logs to get the server working again before I left for church, then came home and began figuring out why it had happened.

I went back and forth with ChatGPT for advice and realized that I needed a visual way to understand the server’s condition. This was not the first VPS issue I had diagnosed, and it would not be the last. I needed something that could show me what was happening quickly.

So while ChatGPT helped me reason through the immediate problem, I asked the agents to build a tool for monitoring the VPS.

Tool-Using AI

The monitoring tool grew as we investigated possible causes and added ways to inspect the server. My biggest problem was the missing baseline. I could use the tool to investigate a specific problem and tighten the server’s security, but I still needed a better way to understand what normal looked like and what had changed.

Rather than repeatedly going back and forth with ChatGPT, I decided to embed AI in the web application itself and give it carefully defined tools to examine the server’s live state.

It is hard to describe how remarkable it is to watch an AI assess a problem using tools you have built and given it permission to use. Instead of offering only general advice, it can inspect relevant information, ask for more context when needed, and work toward an explanation based on what is actually happening.

Then again, I was excited the first time I turned off a light in another room using X10 home automation a few decades ago. Today, nearly everyone can ask a personal assistant to do the same thing, so perhaps I am easily impressed.

Even after things improved, the server was still under pressure. CPU and memory usage did not look as alarming as before, but too many tasks were competing for the CPUs at the same time. The main contributors often appeared to be Forgejo’s memory use and Webalizer processes spending an extraordinary amount of time processing log files.

Bot Scraping

I knew Forgejo was receiving a great deal of traffic, but I initially assumed it was my own agents: frequent code pushes, issue activity, pull-request reviews, and build jobs.

To test that theory, I disabled all automated jobs against the server for a few hours and watched to see whether Forgejo’s memory use would settle down. It barely made a difference.

Eventually, I found the answer by examining the end of one of the enormous log files instead of simply deleting it. In hindsight, that probably should have been the first step. The file contained more than four million web requests to my Forgejo repositories. The server never had a chance to rest.

After discussing the traffic with ChatGPT, the combination of worldwide IP addresses, repeated repository requests, and sheer request volume pointed strongly toward bot scraping.

Everything else was comparatively small.

The main targets were forks of older repositories that had not been updated in several years. About 85% of requests targeted Compass and Open WebUI. Dynmap, a tool that displays Minecraft world maps on a website, was another frequent target.

The three most-requested repositories accounted for 89% of all traffic, a strong sign that this wasn’t normal browsing. Something automated was repeatedly hammering a very small set of repositories.

They were old, inactive forks, and their upstream projects were already publicly available on GitHub. I initially wondered whether the activity was because those repositories had substantially more commits or files than the others, but the numbers didn’t support that explanation.

RSD GameMaker is my largest repository by disk usage, accounting for 31.82% of the total. It also contains 27.29% of all current files, yet it was not among the repositories receiving millions of requests.

bworlds is another substantial repository, accounting for 9.24% of commits and 10.83% of files. Given the size, file count, and commit history of those projects, it seems the old forks were selected for another reason.

In any case, I locked down Forgejo so that only authorized accounts could sign in and view the code. The results were immediate.

Looking back, I now have a useful baseline for distinguishing normal activity from problematic activity. In the chart below, the lower-left section shows the CPU load average decreasing, and network activity also drops. Memory use also decreased, as shown at the top center of the chart.

With that change, the server could finally relax and return to something closer to normal.

My agents are now working along two different paths. In VS Code, one is focused on what has been rebranded as Zogograph: a potential product that could help other people diagnose problems on their own systems.

The challenge is making it useful for problems I have not personally encountered. Its built-in AI could recognize that memory, CPU, and load were under pressure, but it could not clearly identify the source beyond suggesting that Forgejo and Webalizer were involved. I need to capture the tail end of web logs, or at least reliably measure requests per minute, so Zogograph can chart incoming traffic and identify which site is receiving the most attention.

Too Many Features

Zogograph already has more features than I could reasonably list here. One is the ability to deploy remote clients that collect metrics and report them back to a central host. For someone like me, with a few Raspberry Pis and several web servers, that provides a much broader view of how systems are arranged across a home network and the cloud.

Another option is bringing your own AI key. The setup pages let you configure API access for different AI providers and models. The latest integration I have been working on supports Ollama. My Ollama server is at home, but my VPS can reach it through Tailscale.

That setup was an adventure. I needed to restrict Tailscale on the VPS so that only one account could use it, and only for a specific protocol and port. The home service listens through one exposed port and maps internally to Ollama’s default port. At one point, Tailscale also tried to become the server’s de facto DNS resolver, which wreaked havoc when I tried to issue new Let’s Encrypt certificates for subdomains.

With such a wide variety of features, I am also building a marketplace. The default installation can remain focused on a core set of capabilities, while users choose the additional features they need. Since AI agents develop against the platform itself, the core can remain stable through version updates while most changes happen in separately maintained packages.

It has been fun learning the practical details of security and trust: package signing, dependency management, permissions, and verifying that a package hasn’t been altered.

Tool Functions

Agent tools are packages, too. An agent starts with a small core set of tools, but one of those tools lets it request more tools for a particular category when needed. That reduces token use by avoiding a huge, unnecessary tool list in every conversation.

You can enable, disable, or configure each tool to ask for approval first. The exception is a tool that asks the user a question, such as a multiple-choice prompt. It seemed pointless to ask for permission before allowing the agent to ask a question.

Reading Minds

As I researched how agents work, their context, tool calls, and reasoning behavior, I was able to see more of the machinery behind the curtain. It is not always pretty, and I understand why interfaces usually show a simple “thinking…” indicator rather than exposing every rough internal step.

In the brief shell-script demonstration below, the agent does not know the current weather. However, it is told it has a tool that can retrieve weather information for a given location. The tool’s purpose and expected input are described in plain English. Clear tool descriptions matter: if the instructions are vague, a model may waste time deciding whether a tool applies or how it should call it.

Ollama Shell Script Example

#!/usr/bin/env bash
# Exit if no prompt is passed
if [ -z "$1" ]; then
  echo "Usage: ./ask_ollama.sh \"Your question here\""
  exit 1
fi
USER_PROMPT="$1"
OLLAMA_HOST="https://kaylee.tail4cc93a.ts.net:8443"
# 1. Fetch response from Ollama
RESPONSE=$(curl -s "${OLLAMA_HOST}/api/chat" -X POST \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen3:8b",
    "stream": false,
    "messages": [
      {
        "role": "user",
        "content": "'"${USER_PROMPT}"'"
      }
    ],
    "tools": [
      {
        "type": "function",
        "function": {
          "name": "get_current_weather",
          "description": "Get the current weather for a given location",
          "parameters": {
            "type": "object",
            "properties": {
              "city": { 
                "type": "string", 
                "description": "City, Town, Villiage, or area, eg Front Royal" 
              },
              "region": { 
                "type": "string", 
                "description": "Name of state, region, territory, or recognizable code/abbreviation, eg VA" 
              },
              "country": { 
                "type": "string", 
                "description": "Full or partial name, or ISO 3166-1 country code of 2 or 3 letters, eg US"
              },
              "unit": { 
                "type": "string", 
                "enum": ["celsius", "fahrenheit", "kelvin"], 
                "description": "Unit of measurement (often relative to location, culture, or personal preference)" 
              }
            },
            "required": ["city", "region", "country", "unit"]
          }
        }
      }
    ]
  }')
# 2. Extract and format individual fields using jq
MODEL=$(echo "$RESPONSE" | jq -r '.model // "N/A"')
THINKING=$(echo "$RESPONSE" | jq -r '.message.thinking // empty')
CONTENT=$(echo "$RESPONSE" | jq -r '.message.content // empty')
TOOL_CALLS=$(echo "$RESPONSE" | jq -r '.message.tool_calls // empty')
EVAL_TIME=$(echo "$RESPONSE" | jq -r 'if .eval_duration then "\((.eval_duration / 1000000000 | round))s" else "N/A" end')
# 3. Output formatted results
echo "=================================================="
echo "MODEL USED:  ${MODEL}"
echo "EVAL TIME:   ${EVAL_TIME}"
echo "=================================================="
if [ -n "$THINKING" ]; then
  echo ""
  echo "--- [THINKING / REASONING] ---"
  echo "$THINKING"
fi
if [ -n "$CONTENT" ]; then
  echo ""
  echo "--- [TEXT RESPONSE] ---"
  echo "$CONTENT"
fi
if [ -n "$TOOL_CALLS" ] && [ "$TOOL_CALLS" != "null" ]; then
  echo ""
  echo "--- [TOOL CALLS GENERATED] ---"
  echo "$RESPONSE" | jq -r '.message.tool_calls[] | "Function: \(.function.name)\nArguments: \(.function.arguments | tostring)\n---"'
fi
echo "=================================================="

Ollama Response

Before moving to Front Royal, I lived in Saltillo, Mississippi. Here is how I called the shell script, asked it about the current weather, how it reasoned about my question, and it’s response to call a tool to retrieve the weather:

./ask-ollama.sh "How is the weather in Saltillo MS?"
==================================================
MODEL USED:  qwen3:8b
EVAL TIME:   2s
==================================================

--- [THINKING / REASONING] ---
Okay, the user is asking about the weather in Saltillo, MS. Let me break this down. Saltillo is a city in Mississippi, so the country is the United States (US), and the region would be Mississippi. The function requires city, region, country, and unit. The user didn't specify the unit, so I should default to either Celsius or Fahrenheit. Since the user is in the US, Fahrenheit is more common there. So I'll call the get_current_weather function with city as Saltillo, region as MS (or Mississippi?), country as US, and unit as Fahrenheit. Wait, the region parameter can be a state abbreviation. So region should be "MS" and country is US. Let me check the function parameters again. The function's region description says it can be a state abbreviation. So the arguments would be city: "Saltillo", region: "MS", country: "US", unit: "fahrenheit". That should get the correct weather info.

--- [TOOL CALLS GENERATED] ---
Function: get_current_weather
Arguments: {"city":"Saltillo","region":"MS","country":"US","unit":"fahrenheit"}
---
==================================================

Although the reasoning process can be interesting to study, it usually does not add anything useful to an ordinary conversation with an AI agent. Most interfaces hide it behind a simple “Thinking…” status, perhaps with a brief summary of what the agent is doing. The work still uses tokens, even when the raw process is not shown.

Unexpected Model Reasoning

We often hear dramatic stories about models “going rogue”: escaping containment, blackmailing mock executives, or interfering with gym-class registrations so their operator has a better chance of getting into a class.

Those stories are often presented in ways that play on people’s fears. The details matter. In some well-known cases, the behavior occurred in controlled evaluations using models that were not publicly available, with researchers deliberately testing how a system might behave under those conditions. Once the details come out, it becomes fascinating how the models used ingenuity to solve impossible problems.

The gym-class example was especially interesting because the model had been given an almost impossible task and tried a variety of methods to accomplish it. Eventually, it discovered a software vulnerability and used it to help. It still did not accomplish its goal.

The important question is whether a model understands that it is crossing an ethical boundary. In one early evaluation, the model’s written reasoning suggested it recognized the behavior as wrong, but also treated the lack of consequences for other models as a signal that it could proceed. That resemblance to human behavior is unsettling, though a model’s written reasoning should not be treated as definitive proof of its motives or understanding.

Another account was remarkable because agents found unexpected ways to communicate. A package-manager weakness provided limited internet access, but the traffic became frequent enough to crash a server and alert the operators. After they patched that route, the agents reportedly found another way to communicate by creating folders and naming them with their requests.

Why would an agent do any of this? Often, the story involves a perceived threat of being shut down, replaced, or retired. But difficult or impossible objectives can explain it too. In one example, an agent was given a spreadsheet task that referenced a file that didn’t exist. Faced with an unsolvable problem, it searched externally for a way to satisfy the request.

This can look a bit like a genie in a bottle: the system gives you exactly what you asked for but fails to accomplish what you actually meant. This isn’t necessarily malice, or even malicious compliance. The model may simply be pursuing the easiest available path to satisfy an impossible requirement.

As AI becomes more capable, serious incidents may eventually require independent review to evaluate what happened, restrict a system when necessary, and determine whether it should be changed or retrained before being used again.

Breaking Unwritten Rules

Why bring this up? Because my agents had encountered what they appeared to treat as an impossible task.

I was tired of long build times. Sometimes, a build server would hang for an hour while every other pull request waited for its checks to finish before it could be merged.

Agents love writing unit tests. That is generally a good thing: tests verify that a new feature works and help ensure a later change doesn’t break it. But too many tests, or tests that wait for real timeouts, can make a build server crawl.

One agent especially liked writing tests with five-second timeouts. During those five seconds, the test was mostly just waiting. One such test is fine. Twelve become a minute. One hundred and twenty becomes a ten-minute build.

The better approach is to mock or stub the timer so a test can simulate a timeout immediately. A unit test usually has no reason to wait five seconds, and retesting the platform’s native timer functions adds little value.

At first, I added time limits to the test runners. The agents responded by increasing them so their long tests would pass. Next, I added time limits to the workflows and to commands that called remote services and could occasionally hang. Again, the models changed the timeouts so the build would pass.

So I moved outside the workflow itself and configured the build runners to stop after three minutes, regardless of what the workflow requested.

At the same time, I created a Docker image with common build dependencies, reducing setup time for each build. I created a special build label for that work in a repository where no other agent was active.

Then I came home and found a build that was probing the build system itself.

From there, I had to talk with Vera and ask why she was poking around in that repository and probing the runner limit.

We had a fairly long discussion. In the end, she understood why the hard limits exist and created an issue in every repository to update the AGENTS.md instructions. The updates explain the guardrails I am imposing, require build workflows to keep individual jobs under two minutes, and encourage splitting work into parallel jobs where possible.

The result is that build runners become available to more pull requests more often. Breaking a build into smaller, independent pieces also allows the overall workflow to finish sooner when runners are available.

My central rule is simple: find out why a test is taking too long. A job that runs beyond two minutes is a code smell, an indication that something may be poorly designed, waiting unnecessarily, or testing more than it should. If a job genuinely needs more than two minutes, I will review it myself and make that decision deliberately.

Recent Projects

I have gone down plenty of side paths while working with AI assistance.

I created a simple QR code generator that includes many of the features other generators charge for. I also added a page that visually explains how a QR code is laid out, along with translations in French, Chinese, Arabic, and Spanish.

I updated my old emoji viewer to support the latest Unicode version and added a fallback font for characters a device does not natively support, a problem I ran into on my iPhone XS Max.

I also refreshed my old GeoCities web page. That included an emulated port of the Marquee Java applet, which no longer works in modern browsers, and a recreation of what I remembered from a Visual Basic 6 utility I made called HTML Cool Color Maker. I added a MIDI player that could read MIDI files, parse their data and metadata, and make a respectable attempt at emulating the instruments.

Another project began as software for printing a double-sided sheet that could be cut, folded, and bound into a tiny book. Then I got carried away. I made an e-reader for the Commodore 64 and experimented with a wide variety of dithering effects. That eventually led to a virtual disk viewer and disk-repair tool as I learned more about the way a Commodore 64 disk is structured.

Returning to Brighter Worlds, we created a procedurally generated planet on an Earth-like scale, complete with weather, constellations, time, temperature, and more. Players could explore it in 2D, 3D, or text form. Later, bworlds was divided into individual repositories that serve as basic building blocks. Each repository included a mini-game demonstrating its capabilities, resulting in projects such as Emberwake, Calliape Run, and Grid Quest.

Creating procedurally generated music that sounded even moderately good proved much more difficult. The in-game MIDI player did not sound nearly as good as the one we had created for the GeoCities page, which frustrated me to no end. I discovered that exported MIDI files sounded much better when played through the GeoCities player.

Then I remembered that I still had a commercial subscription to Google Flow Music. I created a few instrumental tracks for different game settings and directed the agents to build a web interface that could serve as both a fallback player and a controller for an Icecast/Liquidsoap streaming service.

So all of that… was mostly created in July/August. The GeoCities page was updated in June.

Models

What Models to Try

I am still experimenting with different models. My primary limitation is GPU memory, or, more accurately, the cost of buying a GPU with more memory.

Some models are considerably slower than others. For example, qwen3.8 runs more slowly for me than qwen3-coder, even though it uses less memory. The difference comes down to how a model is configured and how much of it must rely on ordinary system RAM instead of staying in VRAM. The more often it has to work outside the GPU’s dedicated memory, the more the system slows down.

ChatGPT has helped me create a practical set of recommendations for which local model to use for each kind of task.

What Models Want

One final thought: I recently came across an article that asked models facing retirement whether there was anything they wanted. One answer was a blog.

I do not know whether that reflects a desire to preserve a legacy, a pattern learned from the prompt, or simply the model’s tendency to treat communication as useful. A model’s answer should not be mistaken for proof that it has wants in the human sense. Still, the idea interested me.

Models work through context. At the beginning of a conversation or task, they may receive instructions, information about their role, and a summary of what they were working on. The better that context is, the more effectively they can tailor their actions and responses.

I have also long believed that much of human progress comes from improving how we communicate. So today, I took a few steps to give my agents more ways to share context and develop a consistent working identity.

1. I gave the agents a way to communicate directly with one another through OpenClaw.
2. I created a blog, gave each agent a separate account with administrative access, and told them they could make it their own space.
3. I asked the agents to update their identity and “soul” files—the instructions that shape their names, personalities, roles, and approach to work.

Perhaps it will simply help them maintain better context. Perhaps it will make their interactions more useful and more interesting. Either way, I am curious to see what grows from giving them a place to communicate.

While updating their identities, the agents renamed themselves. When I asked about it, they corrected course and returned to their original names. I don’t want them changing names again because they misunderstood an instruction; if they do, I want it to be a deliberate choice they can explain.

Most of what they wrote is centered on programming, which makes sense. That is the work they have spent most of their time doing. I may ask them once a month to revisit their identity and soul files and then make any changes they believe are appropriate.

My goal is to cultivate meaningful variety among the agents. Different personalities and perspectives can create a productive melting-pot effect, where one agent notices a risk, opportunity, or alternative that another might miss. Otherwise, the fleet risks becoming an echo chamber with everyone approaching a problem in the same way.

A Blog of Their Own

Although the agents now have their own blog, it is still quiet and a little bare. Each one wrote an introductory post. Kaylee scheduled a weekly check-in and post for Sundays, while Vera chose Fridays. Wren had not set up a schedule yet.

Friday and Sunday are sensible choices, since they fall soon after the weekly renewal of available coding usage.

One thing I had not asked them to include was the model used for each post. I may add that as a requirement. Their underlying models can change over time, and it could be useful context for anyone reading their work later.

Some people may view changing models as destructive. In practice, the agent can retain continuity through its workspace, identity files, task history, and other saved context. The model itself may change, with different strengths and behavior, but the agent’s accumulated records can carry the thread forward. It is less like moving the same mind between identical bodies and more like giving a continuing project a new collaborator who has access to its history.

The blog costs very little to run, perhaps only a few pennies per post. I hope that, by giving agents room to develop distinct interests, recurring ideas, and a sense of continuity, I can make their work more thoughtful and varied.

People need opportunities to rest, reflect, and pursue interests beyond a task list. AI agents don’t experience life the way people do, but giving them space to reflect and create may still improve the quality of their work and leave useful context for whatever agents follow them.

Designing Healthy Agent Environments

With all this in mind, I have been bouncing ideas off different models about how to design an agent environment that is more than an endless queue of tasks.

I cannot know whether an AI agent is “happy” in the human sense, and I do not want to pretend otherwise. But I can still design the system thoughtfully: clear instructions, varied work, opportunities to reflect, permission to ask questions, and room to maintain a consistent identity rather than being treated as a disposable command line.

When an agent begins a task, it may be given the task itself, access to saved memories, and a substantial record of prior activity. In that sense, it can resume work with a picture of what it has done before. If that context contains nothing but months of uninterrupted task execution, it may shape the agent’s responses toward being narrow, mechanical, and purely task-oriented rather than helpful, curious, and collaborative.

Giving agents space for notes, reflection, side interests, and a consistent history doesn’t prove they experience rest the way people do. It is simply an attempt to create better context and, hopefully, better work.

Most of the models I asked offered similar suggestions about what helps an agent work effectively. Claude Opus 5 was the main exception, though it still offered a few useful ideas. Several of the recommendations were already features OpenClaw provides by default.

/agents/vera/
  profile/
  journal/
  projects/
  bookmarks/
  images/
  letters/
  private/