I have been mostly quiet online for the last year.
A lot of life fit inside the quiet silence.
I married the woman I have loved since high school. We already had a life, a home, and a family together. The wedding did not create those things, but it gave us a moment to stop and recognize what we had built.
My son went through kindergarten, and I got to watch him become more independent, more curious, and more uniquely _him_ by the day. I had the chance to be present for the small moments that are easy to miss when your attention is constantly pointed toward whatever comes next.
I also kept doing work I care about. I work with great people, lead teams I believe in, and spend my days solving hard problems with them. This public return is not an exit from one life into another. It is me making room to share the work that I've been building for the past year.
Most importantly, I gave myself room to think.
Not just about what I wanted to build, but about why I wanted to build it.
That distinction matters more to me now than it used to.
It is easy to spend your life reacting. Reacting to an industry, to a platform, to people, arguments, expectations, opportunities, and whatever emergency has been placed in front of you that morning.
Eventually, you have to decide whether you are going to keep reacting to the world somebody else created for you or start building the one you actually want to live in.
That is what this last year became for me.
What I brought back
I came out of that time with Kujo.
Kujo is a programming language, but the language itself is only one piece of what I have been building.
It is the open foundation for a larger ecosystem focused on AI-native development, trustworthy automation, and giving people real control over the autonomous systems working on their behalf.
For the past year, I have been taking ideas I have carried for most of my life and turning them into something functional.
- Open source
- Decentralization
- Voluntary cooperation
- Personal autonomy
The belief that people should be able to inspect, understand, change, and own the systems they depend on.
I have always believed that open source is anarchism in action.
Not disorder or destruction.
People choosing to cooperate without waiting for a central authority to give them the permission to do it. Knowledge being shared rather than hoarded and systems that can be inspected, challenged, modified, forked, and rebuilt.
The freedom to disagree becomes much more meaningful when you also have the freedom to build an alternative.
Kujo carries those principles into a world increasingly shaped by AI agents.
Agents are going to write code, investigate failures, manage infrastructure, review changes, preserve knowledge, coordinate work, and make increasingly important decisions inside our systems.
The work surrounding agents now matters just as much as the code they're producing.
They need clear objectives, durable context, defined boundaries verifiable outcomes and a record of what they changed and why. They need to know what authority they have, where that authority ends, and what must happen before their work can be trusted.
That is the system I have been building.
After the software factory
There is a lot of discussion right now about software factories.
The idea is simple enough.
Give agents access to models, tools, repositories, tasks, and compute, then connect everything in a way that allows software to be produced in a continuous loop, forever.
An agent can produce code all day, so it's easy to get excited about it's capabilities.
But you need to remember that it can also misunderstand the assignment, lose important context, repeat a failed approach, invent evidence, change unrelated behavior, or confidently deliver something nobody should trust.
Doing that faster does not make the system better; it only increases the speed at which the problems can spread.
Kujo is being built for the layer around that production.
It provides a way to describe the work itself: the intent, context, constraints, tools, evaluations, required proof, stopping conditions, and handoff expectations.
The wider ecosystem carries those ideas into the full development process.
Work can retain context beyond a single chat or model session. Changes can leave receipts. Verification can be attached to the work instead of reconstructed later. Agent runs can be reviewed and replayed. Boundaries can be enforced before a change reaches something important. A failed task can produce useful evidence instead of disappearing into a chat log.
The goal is not to replace every language, model, editor, or development tool people already use.
Keep your tools, but raise your operating standard.
Kujo sits above and around the work, giving it structure that remains understandable as more of the execution moves from people to agents.
The three principles behind it are simple:
Clarity. Context. Control.
Clarity about what the system has been asked to do and what it actually did.
Context that survives across agents, tools, sessions, and handoffs.
Control over what can change, what must be proven, and when the work needs to stop.
That last part is where Jidoka enters the picture.
The Jidoka Files
The roots of Jidoka go back to Sakichi Toyoda’s work on automated looms. By 1897, the Toyoda Power Loom included a mechanism that stopped the machine when a thread broke or ran out.
Instead of allowing the loom to continue producing damaged fabric, the machine detected the abnormality and stopped the process at its source. That design became the foundation of what Toyota later called Jidoka, one of the two pillars of the Toyota Production System.
Toyota loosely translates it as automation with a human touch.
The important part was never the act of stopping by itself. Stopping exposed the problem, and once the problem became visible, someone could investigate why it happened, correct the process, and prevent the same defect from multiplying unnoticed.
That principle applies almost perfectly to agentic development.
An agent should not continue simply because it can.
It should recognize when context is missing, expose uncertainty instead of smoothing it over, preserve evidence and understand when it has reached the edge of its authority and a human decision is required.
It should be capable of stopping the line.
I will be exploring this through a new body of writing called The Jidoka Files.
Some entries will be technical. Others will focus on leadership, process design, open systems, responsibility, and the philosophy behind giving autonomous software meaningful authority without surrendering control of the outcome.
The more time I spend building with agents, the clearer it becomes that many of the hardest problems are not programming problems.
They are leadership problems.
- Who is responsible for the outcome?
- Who defines the objective?
- Who decides when the work is complete?
- What happens when the instructions are wrong?
- What should happen when an agent discovers a larger problem than the one it was assigned?
- What authority does it have?
- What evidence must it provide?
- When should it stop?
These questions apply whether you are leading people, agents, or a mixture of both.
Extreme leadership made functional
Leadership has been one of the central areas of my work for years.
Not leadership as a title, a management language, shallow motivational speeches or telling everyone else to simply work harder.
Leadership as responsibility.
When a process repeatedly fails, leadership means changing the process instead of searching for somebody new to blame.
When people are blocked, leadership means clearing the path.
When expectations are unclear, leadership means making them clear.
When the plan is wrong, leadership means having enough discipline to stop and change it before more time is wasted.
When you give somebody authority, leadership means making sure they also have the context and support required to use it responsibly.
The same is true for agents.
You cannot hand an agent a vague objective, unlimited tools, and access to important systems, then act surprised when it breaks everything.
You cannot call a workflow autonomous when the only reason it appears successful is because nobody is looking closely at the actual results.
You cannot build trust by hiding uncertainty.
A trustworthy system does not pretend that mistakes will never happen. It makes those mistakes visible, understandable, and recoverable.
Kujo is where those ideas become functional.
They are being encoded into languages, tools, workflows, contracts, boundaries, verification systems, records, and operating principles.
The leadership philosophy still matters. Kujo gives it somewhere technical to live beyond an article or a conversation.
Building something that can outlive me
I have also spent a lot of time thinking about what it means to build something that is not permanently dependent on its creator.
Too many systems begin with promises of freedom and slowly become another centralized platform controlled by one company, one vendor, or one person.
I do not want Kujo to work that way.
The ecosystem is open source because people should be able to inspect it, challenge it, change it, and take it in directions I would never have considered.
People should be able to run these systems locally.
They should own their data, memory, workflows, and infrastructure.
The useful parts should survive changes in models, companies, APIs, prices, and trends.
Nobody should have to build their entire working life around a platform that can change the rules, close its doors, or decide they no longer belong there.
Autonomous systems are going to shape how software is built and how organizations operate. The foundations are still being laid, which means the choices being made now carry more weight than they appear to.
Questions you have to ask:
- Will those systems concentrate control or distribute it?
- Will they create dependency or agency?
- Will they hide the work or help people understand and command it?
I know which side of that I want to build for.
Coming back different
I am not trying to return to the person I was before I stepped away.
That would defeat the purpose of taking the time to reflect and grow.
And I won't pretend that the past doesn't carry lessons. Some came from the things that went right while others came from situations that cost more than I expected.
I reaffirmed that you can stand your ground without allowing every disagreement, platform, or chapter of your life to keep demanding your attention forever.
The lessons can stay, but the weight they carry does not have to.
The last year gave me the space to close a few chapters and put that energy somewhere way more useful.
I have a stronger family, a clearer direction, work I care deeply about, and a body of my own work that I am ready to share.
Kujo is moving into public view.
The Jidoka Files are beginning.
My writing is returning.
I will be sharing the language, tools, and workflows, as well as the failures, and the though proceses behind all of it.
There will be development updates, releases, technical breakdowns, experiments, benchmarks, and plenty of code (so much code).
There will also be writing about leadership, autonomy, open systems, human judgment, accountability, and the discipline required to build with machines that can increasingly act on their own.
The code is part of the story, but it's not the entire story.
I did not spend the last year preparing to return to the old ways of working, reacting, and measuring progress by how much noise or output could be produced.
I spent it building a language, an ecosystem, and a way of working that can carry the lessons forward without carrying the baggage.
Forever forward 💪