I have never been especially good at leaving a problem alone once I decide there should be a better solution to it.
That has made 2026 a busy year.
Some of what I’ve built came directly from problems my team and I deal with every day. Some came from using existing software and realizing that the part bothering me wasn’t a missing feature, but an assumption the product had made about how people should work. A few ideas had been sitting around much longer, waiting until the technology, the team, or frankly my patience reached the point where building them finally made more sense than continuing to complain about them.
Looking across all of it now, there is more cohesion than I probably would have admitted while I was building each thing.
A lot of my work this year has revolved around control, context, execution, and removing overhead without making people less responsible for what happens. AI has accelerated that considerably. We can automate far more than we could even a couple of years ago, but increased automation doesn’t remove accountability. If anything, it makes deliberate boundaries, institutional knowledge, and operational awareness more important.
That thinking shows up everywhere.
Scylla Workbench
Scylla Workbench is probably the most ambitious solo software prototype I’ve taken on this year.
It started because I wanted to give AI agents meaningful access to my workstation without simply handing over the workstation. That distinction matters when the machine contains client projects, credentials, infrastructure access, intellectual property, and work that I am ultimately responsible for.
Most of the industry conversation around desktop agents focuses on what they can do. My concern became equally focused on where they are allowed to do it, what they can see, what they can change, and who remains accountable afterward.
Scylla became my attempt to encode the way I actually work with AI into an Agentic Workbench and lightweight IDE. It provides agents with useful project context and tools while keeping filesystem access, execution boundaries, credentials, services, and other capabilities explicit. I want agents to be powerful. I just don’t think powerful should mean indiscriminate.
My team is now taking that prototype toward a macOS desktop application, but the underlying idea hasn’t changed: automate aggressively while retaining custody of the machine and responsibility for the work.
The more I worked on Scylla, the more obvious another weakness became. Agents are becoming very good at computational problem solving, but solving the problem directly in front of them is not the same as understanding the project they’re working inside. A codebase may contain years of architectural decisions, failed approaches, naming conventions, client constraints, deployment quirks, and lessons learned somewhere else in the organization. Most of that disappears every time a new conversation begins.
Strata is our attempt to change that.
Strata is a shared knowledge engine that lets agentic workflows accumulate meaningful project knowledge instead of repeatedly reconstructing it. More importantly, it can surface relationships to work from other projects that successfully shipped. If another team already solved a similar authentication problem, infrastructure constraint, migration, or architectural decision, that knowledge should become useful organizational memory rather than something buried in an old repository.
That moves AI beyond simply being good at solving isolated technical problems. It gives it a better chance of understanding how we actually build.
The same line of thinking led naturally into planning and execution.
Good execution begins long before an agent receives a prompt. There are requirements, dependencies, ownership, acceptance criteria, sequencing, client communication, testing, validation, and all the other pieces of software work that don’t disappear simply because implementation gets faster.
Syncora Studio came from thinking about that problem from the opposite direction.
Most task-management platforms were designed for humans coordinating work with other humans. AI is then added later as another integration, assistant, or automation layer. Syncora was designed around the expectation that humans and agents would both participate in execution from the beginning.
It doesn’t try to replace every client’s project-management system. In practice, that would be ridiculous. Clients may already use Linear, Jira, Asana, or something else entirely, and those systems often belong to them.
Instead, Syncora acts as a central execution layer for us while coordinating work outward into the systems other organizations already own. That separation lets us structure work properly for agents without forcing a client to reorganize their company around our tooling.
The structure is the important part. AI doesn’t need to be the star of every product it touches.
Scout, Spore, and the Less Glamorous Problems
Scout started because bug reporting is still strangely primitive.
Screen recordings are useful for showing someone that a problem occurred, but they’re not especially useful for understanding what the browser was actually doing when it happened. So my team built Scout around structured browser session replay rather than video capture.
The extension records the useful forensic pieces surrounding an issue: user actions, browser state, network activity, console output, errors, and other diagnostic material that an engineer can investigate directly. That also gives us a much stronger privacy model because we can be deliberate about what is collected rather than blindly recording everything that happened to be visible on someone’s screen.
Scout is meant for teams, so recordings flow into projects and verified domains rather than becoming another file someone has to upload somewhere. We’re also working toward bounties and other gamification mechanics that let product owners reward users for intentionally hunting through applications and finding problems.
Testing software should be easier to participate in than it currently is.
Spore came from another familiar development problem: you built the database, and now you need enough believable data in it to test the application properly.
Developers solve this constantly with generators, scripts, copied production data, manually maintained seed files, or whatever approach is least painful at the moment. The catch is that database schemas contain meaning. A VARCHAR might represent an email address, person’s name, street, description, category, company, or something that depends on three other fields making sense.
Spore is designed to understand that context and produce synthetic data at different levels of sophistication depending on what the developer actually needs. Sometimes nonsense is enough. Sometimes you want plausible values. Sometimes the test data needs enough internal consistency that the application behaves as though real people are using it.
The job of Spore is to make that boring problem disappear without forcing someone to build a data-generation project before they can test their actual project.
Simple Sound Control belongs in roughly the same corner of my brain, although mostly because it reminded me how quickly an allegedly trivial problem can turn into a small engineering education.
The idea was simple: build a lightweight Chrome and Firefox extension that provides proper volume control for an individual browser tab.
Browsers disagreed with my assessment that this should be simple.
Between foreground and background behavior, media sessions, gain management, different audio sources, session persistence, browser lifecycle quirks, and the variety of ways audio can exist on the web, a tiny extension became a surprisingly deep look into browser audio.
The final product intentionally hides most of that complexity. That was the whole point. Not every piece of software needs to become a platform. Sometimes the correct scope really is to do one thing well and stay out of the way.
Sanctum and Sentinel
Some of the work this year has been less about building new workflows and more about making old operational problems explicit.
Sanctum came from years of managing servers with teams. SSH access tends to accumulate. Someone joins a project. Someone gets a key. Someone needs elevated access. Someone moves to another project. Someone leaves. A server gets cloned. Another environment appears. Eventually the actual access state across the infrastructure becomes dependent on years of commands, keys, accounts, notes, and people remembering what they changed.
I wanted the inverse.
With Sanctum, access is defined centrally. People, teams, keys, servers, projects, environments, and privilege levels become explicit state. Servers can then converge toward that state instead of administrators manually reconstructing it machine by machine.
Sentinel approaches infrastructure from the communication side.
Technical teams produce an enormous amount of operational information. Deployments happen. Services restart. Builds complete. Migrations run. Capacity changes. Failures occur. The problem is rarely that the information doesn’t exist. The problem is that humans either get buried in it or never see it.
Sentinel is our attempt to create a communication layer between operational events and the people who actually need to understand them. It isn’t meant to replace logging, monitoring, metrics, or DevOps tooling. Those systems already do their jobs.
Sentinel answers a different question: what changed, who needs to know, and how should it be explained?
An engineer may need the underlying event. A project manager may need its consequence. A client may only need to know that a deployment completed successfully or that an issue is being addressed. The goal is to reduce repetitive communication without making everyone oblivious to the systems they are responsible for.
That distinction matters to me. Automation should remove overhead, not awareness.
Signal Inter/upt
Signal Inter/upt doesn’t fit neatly beside the rest of this work, which is probably why I’ve enjoyed working on it so much.
The novel is currently around Chapter 9 of a planned 19 chapters. I’ve wanted to write something like it for a long time, but I’m not a professional author and wasn’t particularly interested in cosplaying as one either. ChatGPT changed the practicality of that without changing the part I cared about.
I don’t use AI to invent the story for me. I use it much more like an editor-in-chief sitting beside me while I write.
The characters, setting, events, dialogue, rules, motivations, and narrative direction are mine. AI helps me interrogate them. It tracks continuity, challenges pacing, notices when something contradicts an earlier chapter, catches when I’ve overexplained a mystery, and helps me think through how a reader is likely to experience information as it unfolds.
That has been an incredibly useful creative relationship. It allows me to tell the story in my voice while having access to a kind of continuous editorial feedback I wouldn’t realistically have otherwise.
Signal Inter/upt also exists as what I’ve been calling a CER, or Chat Escape Room.
The game only really works because livestreaming exists. Nobody has a controller. The stream itself is the game board and the people in chat collectively become the player.
They investigate environments, issue commands, manipulate objects, solve riddles, discover rules, and advance the narrative together. That introduces all kinds of unusual design problems because the “player” may consist of ten people working together, fifty people working against each other, or someone who arrived thirty seconds ago and immediately starts pulling on things.
The current CER became an experiment in designing a videogame around collective intelligence rather than individual input. Eventually I want to take what we’ve learned from it and fold it back into a much larger immersive web experience once the novel is complete.
The book tells the story from inside the world. The CER gives the audience a chance to interact with it.
Signal Inter/upt also managed to create one more software project almost by accident.
I needed a reliable way to run the CER continuously, render a browser-based environment, manage its audio, stream it, recover when something failed, and control the experience remotely. OBS could obviously stream it. OBS could also do about nine thousand other things I didn’t need.
Stream CER became my purpose-built alternative.
Instead of adapting a general broadcasting studio around this one strange application, Stream CER treats the application itself as the thing the streaming system exists to run. That gives me tighter control over recovery, automation, audio, browser state, and remote operation while removing a surprising amount of machinery that existed solely because OBS is designed to support almost every kind of broadcast imaginable.
There is probably an unhealthy recurring pattern in my work where I encounter friction and respond by building infrastructure.
I’m okay with it.
Airefall and Invivaria
Airefall and Invivaria are useful departures from the rest of the year because neither began as an infrastructure problem.
Airefall is my team’s first serious attempt at shipping a native mobile game. It combines meditation with challenge modes and intentionally keeps the initial concept small enough that the team can focus on learning what makes mobile interaction feel good rather than building an enormous game before we’ve shipped our first one.
We’re targeting an October release on the Apple App Store and Google Play for roughly a dollar.
The price isn’t really the interesting part. Shipping it is.
Mobile development exposes a different kind of product discipline. Timing matters differently. Touch interaction matters. Sound matters. Tiny pieces of interface feedback that barely register in a desktop application suddenly become central to whether something feels satisfying.
Airefall gives us a contained place to learn all of that by actually releasing something.
Invivaria takes the opposite approach in terms of ambition.
The premise is simple enough: take care of your real houseplants and the application rewards you for doing it.
The design problem underneath that idea is much more interesting. Plants operate slowly. Different plants have different needs. People forget things. Healthy behavior is repetitive, and progress may take weeks before it becomes visible.
That gives us an opportunity to turn useful real-world behavior into a progression system without making the digital game more important than the living thing it is supposed to support.
The challenge is making Invivaria genuinely cute, genuinely useful, and genuinely fun rather than building a reminder application with cartoon leaves pasted onto it.
I think there is something good hiding in that problem.
Open Source and What Carries Forward
Several of the things we’ve built this year are open source, including Sentinel, Simple Sound Control, Strata, and Sanctum.
That is deliberate.
Not every useful idea needs to become a subscription product, and there are categories of software where openness makes the work more useful. Infrastructure and agent tooling especially benefit from being understandable. If software is controlling access, carrying operational knowledge, or mediating how people interact with systems, there is value in allowing others to see how it works.
The projects also feed each other constantly.
Scylla changed how I think about agent permissions. Strata changed how I think about durable project knowledge. Syncora changed how I think about structuring work before an agent ever touches it. Scout has changed how we think about testing and debugging. Sanctum and Sentinel keep reinforcing my belief that automation should increase operational clarity rather than quietly removing humans from the loop.
Signal Inter/upt taught me something different: AI doesn’t only make me faster at work I already know how to do. Used correctly, it can make work I was never formally trained to do much more approachable without taking authorship away from me.
Even Simple Sound Control contributed something. Every project seems to expose a problem that informs the next one.
That’s probably the better description of what 2026 has been for me than a list of releases.
I don’t think most useful innovation arrives as one enormous idea. It compounds through a series of smaller decisions. You build something because you need it. Building it exposes another problem. Solving that problem gives you a tool, lesson, or perspective that suddenly makes something else possible.
Eventually the projects stop looking completely independent.
Some of these will become business components. Some will remain internal tools or open-source projects. Some are experiments. A few may change substantially before they’re finished. Others exist because I wanted them to exist and eventually ran out of reasons not to build them.
All this to day, 2026 has been a busy year, but I’m just getting started.