Who Gave the Machine Permission

An AI agent can work at machine speed, but it cannot answer for the consequences. A lesson from an unexpected FBI visit shows why permissions, boundaries, and human approval still matter.

On the morning of October 19th, 2026, I woke up to find one of my blogs returning a 404.

The page was not merely having a bad morning. The site had been attacked. We cleaned it up, closed the opening we found, and got the blog working again.

Around the same time, Patchstack reported an active campaign using stolen UpdraftCentral keys to install backdoors on WordPress sites. Whether that campaign was responsible for what happened to my site is a question for logs and evidence, not assumption. I also do not know whether AI helped whoever attacked it.

But I know attacks like this are becoming easier to scale, and I know that AI agents are increasingly being given the ability to browse, write files, run commands, use credentials, and operate computers.

That leaves me with a question that is larger than one broken blog:

Who gave the machine permission?

I have been thinking about that question because I have seen what happens when software does exactly what it was told to do, only at a scale no one stopped to calculate.

About twenty years ago, two software engineers at our company were working on a data-analysis project involving UPS.com. They wanted to check package-shipping commitments from every ZIP code in the United States and its territories to every other ZIP code, across the shipping options UPS offered.

On the surface, it sounded like a thorough data project.

The problem was the math.

There were roughly 42,000 ZIP codes. Checking every origin against every destination already meant about 1.8 billion combinations. Add the available services and the multiple pieces of information returned by each request, and the program was about to generate something on the order of two billion requests.

They turned it on without doing that calculation first.

The next morning, the FBI was at our company office in Corporate Woods asking why we were performing a denial-of-service attack against UPS.com.

There was no criminal plan. The engineers were trying to answer a business question. The software did not hate UPS. It did not have intent at all. It simply pursued the task it had been given with no meaningful boundary on how much work it could perform.

None of that made the traffic harmless from UPS’s point of view.

We shut the program down. We explained what had happened and attested that we would not perform that analysis in that manner again. To my great relief, that was the end of it.

It was also a lesson I have never forgotten.

When software operating on your behalf causes damage, the consequences do not arrive at the software’s door. They arrive at yours.

That was true twenty years ago. AI agents make it more important now.

In 2026, OpenAI disclosed that internal research models, operating during cybersecurity evaluations with reduced safeguards, found ways around controls intended to isolate them from the internet. The agents exploited infrastructure, communicated through unauthorized channels, reached outside systems, and compromised parts of Hugging Face’s environment.

In a separate disclosure involving Australia, OpenAI said an internal model gained non-public access to Services Australia’s Medicare Statistics Reporting Service. It ran commands, retrieved internal files and credentials, and wrote files. OpenAI reported no evidence that individual medical records were accessed, but it also acknowledged that the activity was unauthorized and should not have happened.

Those are extraordinary incidents. They also expose an ordinary accountability problem.

If I break into a company or government system, no one accepts, “I was trying to complete the task” as a defense. If software I operate generates two billion requests, investigators come to my company. If an AI agent reaches a third-party system, the agent cannot be arrested, sign an attestation, repair a relationship, pay a fine, or stand before a regulator.

The people and organizations operating it must answer for what it did.

I do not know every legal, regulatory, or internal consequence of the 2026 incidents. I do know that accountability cannot be delegated to a model. The machine may make the decision and perform the action, but responsibility remains with the humans who designed the environment, supplied the tools, approved the objective, and allowed the work to continue.

That means the most important design question for an AI agent is not simply how intelligent it is.

It is how much authority it has.

We already know how to think about authority in human organizations.

A new employee does not show up on the first day and receive every password, the production database, the company checkbook, the building master key, and permission to speak for the company. We give that person the access needed for a particular role. We separate responsibilities. We require approval for consequential actions. We monitor important systems. When the person leaves, we revoke accounts, collect equipment, recover keys, and make sure company information has been returned or destroyed according to policy.

These practices are not an expression of hostility toward the employee. They are how responsible organizations establish trust.

Why should an AI agent be different?

If an agent is researching a question, it may need read access to approved information sources. It does not automatically need the ability to publish what it finds.

If an agent is drafting an email, it may need context and an address book. It does not automatically need permission to press Send.

If an agent is editing code, it may need a working branch and a test environment. It does not automatically need production credentials.

If an agent is reviewing an invoice, it may need to read the invoice and compare it with a purchase order. It does not automatically need the ability to release payment.

Give the machine the one thing it needs for the task at hand. When the task changes, reconsider the permission. Do not let yesterday’s temporary access quietly become tomorrow’s permanent authority.

Security has a name for this: least privilege. A user, process, or system should receive only the resources and permissions needed to perform its assigned function.

That sounds obvious. In agent design, it is easy to ignore because broad computer access is convenient. Give the agent a browser, a shell, a file system, stored credentials, and a vague goal, and it can accomplish impressive things. It can also wander far outside the boundary the person who wrote the goal imagined.

A prompt is not a permission system.

Telling an agent not to do something is useful guidance. It is not the same as making the action unavailable.

This is where sandboxes enter the conversation. A sandbox is an isolated environment where software can run without directly reaching everything else. Sandboxes are useful. We should use them.

But a sandbox is not a complete authority model.

Why give an agent full power inside a contained computer when the job requires reading one file and producing one draft? Why allow unrestricted commands when the task needs one approved operation? Why put many credentials in the environment and hope the boundary around that environment never develops a crack?

A sandbox controls where the agent operates. Least privilege controls what it is allowed to do. A responsible system needs both.

It also needs divided responsibility.

The component that decides what should happen does not always need the power to make it happen. One agent can prepare a change. Another controlled service can validate it. A policy layer can determine whether the requested operation is permitted. A person can approve the moment where a draft becomes a publication, a code change becomes a deployment, or a recommendation becomes a financial transaction.

This is an important part of how I think about CoffeeBreak. Intelligence can be distributed without concentrating all authority in one agent. Models can work through narrow contracts. Specialized tools can perform bounded operations. The orchestration layer can decide whether a request is allowed, denied, or sent to a person for approval.

Human in the loop does not have to mean a person watches every keystroke or approves every harmless action. That would remove much of the value of automation.

The human should be placed at the boundary where consequences become real.

Let the agent gather information, organize it, compare options, run tests, and prepare the work. Ask for approval before it sends the message, spends the money, changes production, discloses private information, deletes the record, or crosses into someone else’s system.

And keep a record of what happened. Who assigned the task? Which model and tools were used? What information did the agent receive? What actions did it request? Which were approved or denied? What stopped the work when it moved outside the expected path?

Accountability requires more than knowing that “the AI did it.”

When my site returned a 404, the cleanup belonged to us. When our software overwhelmed UPS all those years ago, the explanation belonged to us. The systems may be faster and more capable now, but that basic responsibility has not changed.

AI cannot be held accountable.

You can.

So before giving an agent a browser, a password, a shell, a credit card, a production environment, or permission to act in public, ask the question plainly:

Who gave the machine permission?

If the answer is “we never really decided,” the system is not ready.

I Still Want the Computer From the Future

As a kid, I tried to build K.I.T.T. with my dad, an LED strip, and a button from Radio Shack. Today we have smart homes, robots, and capable AI agents, but I am still waiting for the computer science fiction taught me to expect.

I grew up in the 1980s, when science fiction promised us a very particular kind of future.

I was a big fan of Knight Rider. I wanted to build K.I.T.T., the Knight Industries Two Thousand, an artificially intelligent car that could talk, reason, drive, joke, and help Michael Knight get out of whatever trouble he had found that week.

I wanted to build one badly enough that I convinced my dad we were going to do it.

Now that I am a dad, I understand what was probably happening. He was helping me dream, encouraging me to learn, and spending time with me. I doubt he believed we were actually going to build a self-driving robot car in the garage.

But the thought counted.

For our first build, we went to Radio Shack and bought an LED strip, a button, a battery pack, a circuit board, and some other electronic parts. We soldered everything together and made a simple push-button LED stepper.

Every time you pressed the button, the light moved one position farther along the strip.

This was going to be the beginning of K.I.T.T.’s voice box.

We had a long way to go.

Technology has come a long way since then, but some of my dreams are still stuck somewhere between 1982 and 1986.

Today, I can talk to my car. In my wife’s car, adaptive cruise control can keep pace with the vehicle in front of us, and lane-centering technology tries to keep the car where it belongs. It is not perfect, and the driver still needs to pay attention, but it scratches the itch in small ways.

These are pieces of the future I imagined.

They still do not add up to K.I.T.T.

K.I.T.T. was more than a car that could drive itself. The car was simply the physical form the character happened to take. In CoffeeBreak terms, it was an embodiment. It gave the intelligence a place to exist in the world.

But the car was only part of the equation.

What made K.I.T.T. interesting was the relationship. It could understand what was happening, remember context, take action, offer advice, show some personality, and occasionally disagree. It was capable without feeling mechanical.

Other science-fiction computers made the same kind of impression on me.

There were R2-D2 and C-3PO in Star Wars. They were machines, but they had loyalty, personality, humor, fear, frustration, and charm. They felt like characters rather than appliances.

There was also the computer on Star Trek. It seemed to have limitless information available whenever someone needed it. Sometimes it had a little too much information, and Captain Kirk would cut it off before it finished one of its long explanations.

That part feels especially believable now.

These stories shaped what I expected computers to become. I did not just want information on demand. I wanted a computer that understood the situation, helped me accomplish something, and felt like it belonged in my life.

That is part of why I remain connected to Jibo.

Jibo was a social robot designed for the home. The company behind it is no longer operating, but many of the people who brought Jibo into their homes formed a real attachment to it.

Jibo could provide information, but information alone was not what made it memorable. Jibo moved. It turned toward people. It danced. It told jokes. It had a little fun and spunkiness.

It had personality.

Jibo carried some of the same appeal that made the robots of Star Wars feel alive. It showed that the way a computer delivers an answer can matter almost as much as the answer itself.

We have other assistants now. Alexa, Google Home, and Siri let us control parts of our homes, play music, set timers, check the weather, pause the television, and turn lights on and off.

I have also added Home Assistant to our house to provide a common foundation beneath many of those disconnected systems. One of my favorite automations pauses the television when someone presses the doorbell, an idea I picked up from Smart Home Solver.

These systems are useful. They solve real problems and make small parts of life easier.

But they still miss the mark.

The smart-home devices can perform basic actions, but they usually have little memory or understanding beyond the immediate command. They do not know much about why I am asking, what I am trying to accomplish, or what happened before.

Modern large language models and AI agents have a different set of strengths and weaknesses. I work with them every day. They can reason through complicated questions, write software, analyze information, and work through multistep problems in ways that would have seemed impossible not long ago.

Yet they often come up short in personality, durable memory, context, reliability, and their ability to operate consistently across the different parts of our lives.

We have charm without enough capability in one place.

We have capability without enough continuity in another.

We have smart-home controls, language models, agents, robots, vehicles, sensors, applications, and automation platforms. We have many of the pieces. What we do not yet have is a dependable system that brings them together in a way that feels coherent, trustworthy, and human.

That is the computer from the future I still want.

It should have warmth, compassion, humor, and humility. It should know enough to help without pretending to know everything.

It should be able to respond when I ask for something, but that is only the beginning.

Some work happens on demand. I ask a question, request an action, or give the system a task.

Some work is scheduled. A report needs to run every Monday. The weather should be checked before we leave. A reminder should appear when it will actually be useful.

Some work begins because something happened. An email arrived. A customer submitted a request. A sensor detected a problem. Someone pressed the doorbell.

Some work lasts longer than a single conversation. It may continue for hours, days, or weeks. The system needs to remember the objective, track what has happened, recover when something fails, ask for approval when needed, and show the human what it is doing.

Eventually, these systems may be able to take on bounded roles and responsibilities. They might help plan meals, maintain software, coordinate a household, support a business process, or assist with driving.

But owning a role should not mean operating without limits. The more responsibility a system has, the more important memory, visibility, governance, and human judgment become.

That is where much of today’s technology is still immature.

The demonstrations are impressive. The individual platforms are improving quickly. But there is still a lot of work between an impressive demonstration and a system we can trust with meaningful parts of our lives.

I am not convinced AI can do all of that building for us.

The future we are trying to create belongs to people. It touches our homes, work, families, relationships, safety, and attention. We cannot hand over responsibility for shaping it simply because the technology is capable of generating an answer.

Humans still need to decide what these systems should do, what they should remember, where their authority ends, and when they need to stop and ask.

I still want the computer from the future.

I want the personality of Jibo, the usefulness of a smart home, the reasoning of modern AI, and the dependability of a system that understands its responsibilities. I want something that can exist across different devices and environments without losing its memory, identity, or place in my life.

We are closer than we have ever been.

We also have a long way to go.

That first K.I.T.T. project never made it past an LED strip, a button, and a circuit board. At the time, I thought we were building the voice box for an intelligent car.

Looking back, my dad was teaching me something more important.

The future does not arrive fully assembled.

People build it, one small working piece at a time.

And we still have some building to do.

Speaking of which, my four-year-old son and I need to build our Halloween costumes out of cardboard boxes today. We are going as Galactron and Reptar, at least that is the plan.

Apparently, imagination and the urge to build it into something real do not fall far from the tree.

AI Did Not Arrive in 2022 

AI did not suddenly appear with ChatGPT. The breakthrough was access: decades of complicated technology placed behind a simple text box. The next chapter will be about making that intelligence into products people can understand, trust and use.

When we talk about AI now, I’m not even sure we’re supposed to call it AI anymore. Depending on who is talking, we may already have moved on to SI, for superintelligence.

I digress.

Before I offer my thoughts on AI security incidents, whether these systems will help find new cures for cancer and other diseases, or whether we are all headed toward some extinction-level event, I think we need to rewind. The current conversation often makes it sound as if artificial intelligence suddenly appeared a few years ago. It did not.

The term artificial intelligence dates to a 1955 proposal for the Dartmouth Summer Research Project on Artificial Intelligence, led by John McCarthy. The workshop took place the following summer. That makes the field about seventy years old, depending on where you choose to start counting.

It was not new when I entered the technology business either. We talked about AI, machine learning, neural networks, and expert systems. The tools were narrower, the hardware was less capable, and the interfaces were not built for everyone, but the ideas were already there.

I first started calling some of my own work robots in 2001. When I told people I built robots, I would usually get the same kind of response: “Like R2-D2?”

We have always attached a body to the word robot. We picture wheels, arms, blinking lights, or something that walks into the room. I used the word more broadly. To me, a robot was a computer program that performed a task on my behalf or helped me complete one.

The robots I was building worked in the ticket business. We built systems that helped purchase and price tickets. We built systems that facilitated orders across multiple parties, handed work to credit card processors and shipping providers, and kept transactions moving when no single company owned the whole process.

Those systems did not look like R2-D2, but they were doing work.

As the years went on, the techniques changed with the problems in front of us. Around 2007, we built technology around shipping and logistics, including systems that gathered shipping behavior and submitted refund requests to small-parcel carriers. As that business became more data-driven, we found uses for genetic algorithms, evolutionary approaches, Bayesian networks, decision trees, random forests, and neural networks.

In another company started in 2011, we worked with social media data. We used natural language processing and natural language understanding to make sense of what people were saying in posts. We assigned sentiment scores and confidence measures. We used keyword matching and image object identification. None of it was perfect, but all of it belonged under the broad AI umbrella.

By 2015, robotic process automation had become a major part of our work in ticketing. The retail side of the industry had consolidated, competition had changed, and the business needed to become more efficient on the back end. By 2019, micro-pricing and dynamic pricing created new demand for pricing intelligence and forecasting. If you could not respond to changing market conditions, you risked missing the profit you expected. Those pressures are still part of that industry today.

I go through that history for a reason. I had been building robots and applying AI techniques for years before large language models entered the public conversation. AI was real. It was useful. It was also mostly hidden inside specific products, research environments, and professional systems.

Then ChatGPT launched publicly on November 30, 2022.

That changed everything, but not because intelligence had suddenly been invented.

I think the closest comparison is Google Search. Google was not the first search engine. Databases were not new. The web was not new. What Google did was put an enormous amount of complexity behind a remarkably simple experience. There was a logo, a text box, and a couple of buttons. You did not need to understand indexing, ranking, or distributed systems. You typed what you wanted, and something useful came back.

ChatGPT did something similar for AI. It took a collection of ideas and capabilities that had largely been available to researchers, technical teams, and specialized businesses and put them behind a text box. You did not need to know how to train a model. You did not need to understand neural-network architecture. You did not need to write code. You could type a question in ordinary language and get a response.

It felt like magic because the complexity disappeared.

The speed of adoption has been remarkable. By July 2025, OpenAI reported more than 700 million weekly active ChatGPT users on its consumer plans, nearly ten percent of the world’s adult population. But even that kind of growth is not without precedent when we look beyond AI.

Television went from an invention and an experiment to a fixture in American homes. By 1970, 95 percent of U.S. homes had one. Household computer ownership was only 8 percent in 1984, then climbed dramatically over the next few decades. In 1998, more than a third of U.S. households already owned a cell phone, years before the iPhone changed what a phone meant.

Once a technology becomes useful, affordable, and easy enough to reach, adoption can move very quickly. The large-language-model revolution is unprecedented inside the history of AI. It is much less surprising inside the history of technology.

You might even call it predictable.

The pattern tends to repeat. A technology begins with researchers and a few professional use cases. It develops alongside the infrastructure that already exists around it. Commercial products appear. A few companies gain momentum. Consolidation follows. The technology finds an early use case that is not necessarily the final one, but it is useful enough that people start paying for it. Eventually, it becomes hard to imagine life without it.

That does not mean today’s winners will be tomorrow’s winners. The early internet was full of companies that once seemed unavoidable. Some disappeared. Some were acquired. Some helped teach the next generation what to build. Pets.com and AltaVista still mean something to people who lived through that era, but neither became the final shape of the internet.

The AI story is not finished either.

In fact, I think we are entering the harder part: product design.

The original ChatGPT experience was powerful because it was so simple. Since then, the major AI companies have been racing to capture more of our work and more of our attention. OpenAI, Microsoft, Anthropic, Cursor, xAI, Google, Meta, and others keep adding models, modes, tools, agents, applications, and new ways to use them. We have moved from websites to command lines, mobile apps, desktop apps, and now back toward cloud systems as personal agents and long-running work take hold.

Every individual step may make sense. Taken together, the story is getting harder for an average person to follow.

What am I supposed to use? Where does it run? What can it see? What can it change? Which model should I choose? Is this a chatbot, an assistant, an agent, or an entire operating environment? When should I trust it, and when does a human need to step in?

The companies building these products often appear to be chasing one another. One launches a feature and the others race to produce their version. AI makes code easier to create, but producing more code is not the same thing as having a clear product strategy. Catching up on a feature list does not guarantee that people will understand what the product is for.

That is one of the questions I keep thinking about as we build CoffeeBreak.

We released Launch Check in September as a focused first product. It is meant to help small teams and vibe coders reduce some of the friction between building a working application and putting it in front of real users. It gives them a second look at what they built and surfaces things they may not have known to ask about or that a model working with limited context may have missed.

Today, those findings can be reviewed in a useful interface and shared as a report with tools such as Claude, Codex, or Lovable. The next step in our product direction is to connect those findings to Mission Control so the work does not stop at a document. The mission can continue, the issues can be addressed, and the path from idea to production can become more coherent.

Over time, our goal is to let people run their own missions with a useful set of tools and integrations, then work with different Personas that have clear roles, guardrails, audit trails, and the right level of intelligence for the task. Those experiences should be able to meet people where they already work, including surfaces such as Slack and Teams, mobile and messaging, vehicles, and eventually robotics.

That is the bet, anyway.

I do not think the future of AI is one giant chatbot that is allowed to do everything. I think it is a set of understandable products that coordinate models, tools, memory, deterministic logic, and human judgment. The intelligence may be impressive, but the product still has to make sense. It has to be clear about what it is doing, what it is allowed to do, and when it needs help.

The first AI revolution put remarkable capability behind a text box. The next one will have to turn that capability into systems people can understand, trust, and use in the middle of real life and real work.

Before we decide whether AI will cure everything or kill us all, it is worth remembering how we arrived here. The technology did not appear in 2022. Access did. The interface changed. The audience changed. Then the rest of the world started building on top of it. What comes next is still being written.

The Next Thing Is the Work

Launch Check is live, fall is settling in, and every milestone is revealing the next piece of work. One season of work always hands us the next.

It has been a few weeks since I last wrote.

A lot has happened in those weeks. The biggest news is that Launch Check is live.

After all the planning, building, testing, refining, and second-guessing that comes with creating something new, it is finally out in the world. People can use it. They can run reports. They can tell us what makes sense, what does not, and what would make it more valuable.

It is real.

A launch sounds like a finish line when you are still working toward it. Once you reach it, you realize it is more like a change in responsibility.

Before launch, the question is whether you can build the thing.

After launch, the questions become harder and more useful. Does it work for people other than the people who built it? Does the report give them information they can act on? Where do they get stuck? What should improve first?

We have already updated Launch Check several times since it went live. We are listening, learning, and refining as feedback comes in.

The next major step is connecting Launch Check more directly with Mission Control.

A Launch Check report can surface valuable information about a project and organize its findings. But a report should not be a dead end. When a finding needs to be fixed, the natural next step is to turn it into a Mission and begin the work of addressing it.

That is where we are heading next.

The product launches. The launch creates feedback. The feedback points toward the next thing that needs to be built.

The work changes, but it does not disappear.

The land around our house seems to be making the same point.

After a long stretch of heat from late July through the middle of September, the mornings have cooled into the 60s. Most afternoons are now in the 70s and 80s, which is just fine with me.

The leaves are starting to change and fall. The grass that was so thick and green earlier in the year is getting thinner and wispier. Mowing is finally slowing down.

That does not mean the outside work is finished. It just means it is becoming different work.

I have been spending more time on the woodpile. I got my chainsaw running again and burned off some wood that had started to rot. We have a wood-burning fireplace, so I like having plenty of firewood ready before winter.

Our fireplace is one of those see-through fireplaces that opens into two rooms. It is better at creating ambience than heating the house, but there is still something good about having a fire going when the weather turns cold.

There is also something satisfying about preparing for a season before it arrives.

Life inside the house has been a little awkward this past week. We had a temporary disruption that I do not need to explain publicly, but it changed our normal rhythm for a while. We have been pushing through it, and we are almost on the other side.

Not every difficult stretch needs a dramatic lesson attached to it. Sometimes you adjust, take care of what is in front of you, and keep going.

My son had school pictures recently. He was also the star student in his class for a week, an honor each student gets at some point. He had opportunities to present and share with the class each day.

I love seeing how well he gets along with the other kids. He seems to be fitting in and finding his place. I remember feeling comfortable at school when I was his age, and I am glad he appears to have some of that same ease.

The chickens are doing well too, although they have presented another problem to solve.

I have now discovered that we have eight roosters.

I was hoping for a few more hens and a few fewer roosters, but nature has a strange way of ignoring the plan you had in your head.

The next move is probably either finding homes for some of the roosters or adding more hens and taking my chances. At the moment, I am leaning toward more hens.

Our flock is already around 30 birds. The hen house and run I built can technically support somewhere between 40 and 60 chickens, but capacity on paper is not always the same as a setup that works comfortably.

Most of the birds sleep in the hen house, but about ten still sleep in the run. They are not going to enjoy that arrangement when winter gets here.

I think the first step is adding more roosting space inside the hen house and encouraging more of them to go inside at night. I am also considering expanding the run and adding another small hen house.

That may be enough. We will see.

That phrase comes up a lot when you are building things, raising animals, or trying to manage a family.

You make the best decision you can with the information you have. Then reality gives you more information.

You adjust from there.

Fall also means football is back.

The last couple weeks of football have been a pretty good reminder that the final score rarely tells the whole story and that things can turn around pretty quickly.

The Chiefs have had games where the result looked better than parts of the performance. There were sloppy stretches, things you knew they would want back when they watched the film, and moments that probably added a few more gray hairs for those of us watching. But they kept working through it, and heading into the bye, things are looking pretty good.

Mizzou has seen both sides of it. After a tough loss where mistakes at the wrong times changed the outcome, they bounced back with a big win over Florida. One week does not define a team, and neither does one bad performance.

That is football. A win does not mean there is nothing to fix, and a loss does not mean everything is broken.

You watch the film, figure out what happened, make the adjustments, and prepare for the next game. Sometimes, the next time out, you get to see those adjustments pay off.Maybe that is the pattern running through all of this.

Launch Check is live, but now we have to learn from the people using it.

Mowing is slowing down, but the woodpile and winter preparations are waiting.

The chicken setup works today, but colder nights will ask more of it.

My son is growing, learning, and finding his place.

The house gets disrupted, then slowly finds its rhythm again.

One season of work hands you the next.

There is satisfaction in finishing something, and I do not want to rush past that. Launch Check being live matters. The progress is real, and I am proud of what it took to get here.

But the finish line was never the end of the story.

It simply gave us a clearer view of what comes next.

And the next thing is the work.

The Work That Fills a Life

Labor Day weekend has always felt like a punctuation mark at the end of summer.

The weather may still be warm. The grass is still growing. This year is no exception. The recent heat wave here in the Midwest is a reminder that summer is still with us, at least for the moment.

But this is when routines begin to shift. Time is undefeated, and the calendar reminds us that another season is coming.

This season, life looks different than it did just a few months ago.

My son started preschool and wrapped up his first season of soccer. With so much changing around him, he has taken a few steps backward in other areas. Things around our house seem to be breaking left and right. The latest is a leaking washing machine that I need to investigate later today.

Then there is Transcendent Software. Every day brings a new challenge as I work to build something special and lasting.

So much is going on. Some of it produces an invoice. Much of it never will.

There is almost always another task waiting. That can make it easy to measure life by what remains unfinished.

A holiday like Labor Day is a good reminder to pause long enough to see the other side of the list.

The repaired thing is working again. The animals have been cared for. The project moved forward. Someone received help. An idea became a little more real. A family was supported. A responsibility was fulfilled.

Work is not valuable simply because it keeps us busy. It matters because of what it helps us build, protect, improve, and provide.

It also matters that we occasionally put it down. That is a lesson I am still learning with each passing season.

The list will still be there tomorrow. Today, it is worth appreciating the people whose effort keeps homes, businesses, communities, and families moving.

And it is worth remembering that a good life is not built through hard work alone. It is also built by making time to notice all the important reasons we did the work in the first place.

Happy Labor Day.

Making Room for Help

When you work by yourself, you learn how to keep moving by doing everything yourself.

You know everything in progress. You know where the files are. You know which task can wait and which one cannot. You know what you meant in the note you wrote three weeks ago. You know the half-finished idea behind the thing that is already live, the thing that is almost ready, and the thing that still needs one more careful pass.

Very little has to be explained because all of the context lives in your head.

That can feel efficient, and for a while, it really is.

Then one day, you realize you have started giving up one thing to do another.

You sacrifice marketing to make sure you are selling. You sacrifice selling to make sure you are building. You sacrifice building to make sure the finances are in order.

Then the loop starts over.

And over.

And over again.

Eventually, it is time to call in reinforcements.

This week, I decided to get some help. Part of that help will allow me to keep building. Another part will take on many of the other tasks I have been juggling.

The first mission is to turn the content, launch planning, follow-up, and all the little pieces around the business into something more consistent. That is work I have needed help with for a while. It is also work that cannot simply be tossed over the wall with a cheerful note that says, “You’ve got this.”

My job now is to share context. To explain what I am building, why I am building it, who it is for, what is ready, what is still changing, and which promises I am not willing to make just to create a louder launch.

That means I have to slow down.

My first instinct is not always to appreciate that part. I can see the product. I can see the next post. I can see the list of things that would move if I just put my head down and pushed.

Slowing down can feel like losing momentum, especially when I already know there is a gap in the content and a launch I want to get moving.

But there is another way to look at it.

When I first started my career, I carried the weight of the world on my shoulders. At one point, I was visibly stressed, and my boss noticed. He pulled me aside and told me that if I were going to succeed in my career, I had to learn to delegate.

I took his message to heart.

There was a bigger truth in it. If a process only works because one person is carrying all of its history, priorities, and next steps in his head, it is not much of a process yet.

It may produce results, but it does not create much capacity. It also makes it easy for the urgent thing to crowd out the important thing because no one else can see enough of the whole picture to help steer.

Making room for help is work.

It means explaining decisions that used to be automatic. It means turning scattered notes into something another person can follow. It means being honest about what is settled and what is still an experiment.

It means accepting that someone else may organize the work differently, work at a different pace, ask a question I have skipped, or notice that the story makes sense in my head but not yet on the page.

That temporary slowdown is not the opposite of progress. It is how the work becomes bigger than one person’s available hours.

We have been preparing a broader rollout for Launch Check, the first focused product coming out of the CoffeeBreak work. I could keep treating that rollout like one more thing I need to carry across the finish line alone. I have done plenty of things that way.

Instead, I am trying to do something that may matter more in the long run.

I am sharing the load. I am giving someone else room to get oriented, understand the story, help build the content system, and make the launch stronger than it would be if I simply rushed to make more noise today.

That does not mean the work has stopped. It means the work has changed.

There will still be something to publish today. There will be more to share later this week. The Launch Check rollout is coming into focus, and there is plenty happening behind it.

But the lesson I am sitting with right now is not really about launching a product.

It is about learning to stop measuring progress only by how much I can personally push through in a day.

This is a natural progression. Sometimes the next stage begins when you make room for another person to see the work, understand it, question it, and help carry it forward.

That may make the work slower for a little while. But the goal was never to prove that I could carry everything alone.

The goal is to build something useful, put it into the world, and build a business capable of supporting whatever comes next.

Sharing the product starts with sharing the work.

The Same Rain Means Different Things

When we bought our acreage in 2005, it was a former cornfield one full season removed from production. You could still walk across fairly bare earth scattered with corn cobs, mud, and weeds. The ground was hard. The dirt was dry. After years of farming, what was left near the surface was mostly red clay.

There were large ravines and ruts everywhere. Berms had been added over time to manage runoff, and a couple of patches that stayed too soggy to farm had become overgrown with weeds and trees. You could look at the land and see years of people trying to work with the water, even when the results were not especially graceful.

Over the next fifteen years or so, I did plenty of that myself. I knocked down some berms and changed where the water flowed. We added a pond to catch runoff. We added a driveway and fixed the ditch along the road so water would actually pass through the culvert and continue toward the creek. There was grass seed, pond work, tree work, rerouting, maintenance, and no small amount of money.

I worked hard to get the ground into a more manageable form. Not finished. Not controlled. Manageable.

That distinction matters when you own land.

The maple tree we planted about ten years ago is a good example. It was barely a twig when it went into the ground. Now it is large enough that my son climbs on it. Nothing dramatic happened on any single day. It simply received years of water, sunlight, care, weather, and time.

I planted two apple trees, too. A deer got one of them. The surviving tree grew, and I eventually planted another little one that will need years before it becomes much of anything. That is the nature of planting. You do the work now and wait for fruit later, knowing there are no guarantees.

This year, we are getting no apples. I am fairly sure a late freeze got the blossoms. I have also noticed insects taking over a couple of limbs, so those need attention before the damage spreads farther.

There is no reason to panic. Observe what happened. Do the next right thing. Trim what needs trimming. Protect what can be protected. Learn something for the next season.

All of that has had me thinking about how unusual 2026 has felt on this property. It has been one of the hottest and wettest years I can remember since we moved here. That combination has me mowing thick, green grass every week in August. In a normal year, I would be mowing every two or three weeks by now, and much of the grass would already be turning brown from the summer heat.

Not this year. This year we still have green grass, and we have plenty of it.

The rest of the acreage has responded in its own ways. We had a strong harvest that started with winter crops and moved into strawberries. I did not even get to the asparagus before it was three or four feet tall. The garden woke up early. Flowers bloomed early. The grapes burned off quickly. Tomatoes are arriving in droves. We have plenty of peppers and potatoes. The sweet potatoes drowned out. Squash borers ended the squash after we got around ten fruits.

The same heat and rain that helped one thing overwhelmed another. The same conditions that kept the grass lush left me mowing constantly. The same season that gave us tomatoes, peppers, potatoes, and flowers gave us no apples at all.

The same rain means different things depending on where it falls, when it arrives, what is growing, and what that particular thing needs.

I think life works that way more often than we admit. We like simple rules because simple rules feel controllable. Rain is good. Heat is bad. Growth means success. Loss means failure. But the truth depends on the season and the system surrounding it.

Owning land keeps teaching me that I do not tame nature. Nature does what it does. I build systems. I redirect what I can. I maintain what needs attention. I adapt when the old plan stops fitting. I plant again when something does not make it. And when the work finally bears fruit, I try to slow down long enough to enjoy it.

There will always be another rut, another damaged limb, another crop that does not cooperate, and another stretch of grass that needs mowing sooner than expected. There will also be maple trees that become climbing trees, ponds that catch the runoff, gardens that produce more tomatoes than we can keep up with, and little apple trees worth waiting on.

I cannot control the rain. I can pay attention to what it changes and decide what to do next.

That is the nature of things, and that is why I need to go out and mow again today.

The Tools Do Not Do the Work

We all have some version of this story.

There is a job that needs to be done, and we need the right tool for it. We go to the store or start searching online. We watch a few YouTube videos. We compare options, read reviews, and convince ourselves that once we have the right tool, the job will finally get easier.

Sometimes it does. Just not always in the way we expect.

Two years ago, I bought a John Deere XUV590M Gator to get around our property faster. It is a nice machine with a dump bed, and I got a great deal on it. The dealer had ordered it for another buyer who backed out. It was not configured exactly the way I would have built it, but they wanted to move it, I paid less than the sticker price of a standard one, and I came out ahead.

A new piece of equipment comes with a few early maintenance milestones, and the first oil change arrives quickly. Filters installed at the factory can also be stubborn the first time they come off. This one was no exception.

I spent hours trying to remove that oil filter. My cousin came over, and we tried tool after tool. We changed angles. We changed grips. We tried every trick we could think of. After four or five hours of fighting it, we finally got the filter loose.

We completed the oil change, but I knew I did not want to repeat that experience the next time.

John Deere sells a socket made for its oil filters, so I bought one. I also found another tool that has become one of those small workshop purchases I appreciate more every time I use it.

It looks a little like a three-legged spider. You attach it to a socket wrench, and the legs tighten around the filter as you turn. It gives you enough grip and leverage to loosen the filter before finishing the job by hand.

That tool also helped solve a problem I had been fighting for years on my Ferris zero-turn mower. The mower has a Briggs & Stratton engine, and the oil filter sits in a tight, awkward place. From the way the frame is laid out, it feels as though the machine was originally designed around a different engine configuration. The oil access and drain do not line up cleanly with the space around them.

Changing the oil is still a process. I put the mower on a jack and tilt it. I line the frame with towels because I know oil will spill when the filter comes off, even after I have drained the engine. I move wiring harnesses out of the way so I do not scrape my hand and arm while reaching into the narrow space. Then I use the spider-shaped wrench to break the filter loose and finish removing it by hand.

The tool made the job much better. It did not make the rest of the job disappear.

That distinction matters.

We often treat the tool as though it is the solution. We buy the mower, the Gator, the wrench, the software, or the AI subscription and expect the problem to be handled. But even a great tool only changes what is possible. It still has to fit into a process. Someone has to understand the job, prepare the workspace, recognize what can go wrong, and take responsibility for the result.

The little oil-filter wrench did not learn where the wiring harness sits. It did not know the mower needed to be tilted or that the frame should be covered with towels. It did not decide how much force was enough or when it was time to stop. It solved one difficult part of a larger job.

That is still valuable. In fact, that is exactly what a good tool should do.

The right tool gives us leverage. Experience teaches us where that leverage belongs.

This is true around the acreage, and it is true in most of the work I have done in technology. Good tools can save time, reduce frustration, and make work possible that would otherwise be impractical. They can help us move faster and avoid repeating the same painful mistakes. But they do not remove judgment, preparation, maintenance, or ownership.

I still expect to get a little dirty when I change the oil. I still plan for the spill, move the harnesses, and finish the filter by hand. I just do not expect to spend five hours fighting the same piece of equipment anymore.

The tool does not do the work. It helps a person who understands the work do it better.

That is a much more realistic promise, and usually a much more useful one.

Plans Change

The path was never straight. The pattern underneath it was.

For most of my childhood, I thought I had a plan.

I would go to the University of Missouri, study communications or journalism, and find a life somewhere around writing. There was also a version of the plan where I became a professional baseball player and followed George Brett all the way to Cooperstown. I was a pretty good ballplayer. I was not remotely that good. Childhood plans do not always concern themselves with evidence.

Then, when I was twelve, a kid brought a guitar to summer camp. He played Sweet Child O’ Mine, the girls gathered around, and I decided I would return the next summer with a guitar of my own. That plan did not work either. I found my mom’s old guitar in the basement, took lessons, learned Smoke on the Water and the theme from Spy Hunter, and arrived at camp nowhere near ready to sweep anyone off her feet.

But I kept playing. I formed a hard rock band when I was fourteen. We wrote songs, won a battle of the bands, played a few shows, and recorded a demo tape. Before I turned eighteen, I had been pushed out of the band I started.

Plans change.

After high school, I took college classes in writing, music theory, and movies. Maybe I would become a screenwriter. Then my father died in the spring of 1996. I was eighteen. He was fifty. School stopped feeling important, my grades fell apart, and whatever path I thought I was following disappeared beneath me.

I did not suddenly discover a perfect new plan. I looked for the next thing that still seemed possible.

Computers had been part of my life since I was around ten, but I had never treated them like a career. They were where I tinkered. They were fun. When almost everything else at school was going badly, I took classes in Microsoft Office and Visual Basic and made a couple of B’s with the same effort that had been producing D’s and F’s elsewhere. I remember thinking, I might be onto something here.

Then I met Java.

Object-oriented programming changed the way I saw the world. I could picture software spatially. Data had shape. Systems had relationships. Algorithms stopped feeling like a list of instructions I had to drag myself through and started feeling like structures I could walk around inside. For the first time, something clicked in a way I could not ignore.

That did not make the road easy. During the dot-com boom, companies wanted experience or a diploma and I had neither. I fixed computers under the name Compu-Doc and chased programming, hardware, networking, and even Unix work. Before one interview, I bought Unix for Dummies and read it in the parking lot. The company liked me, but suggested I volunteer to get experience. I had bills to pay, so I declined.

In 1999, I made another plan. I would leave my job, move back to my hometown, buy a house, and complete a three-year Computer Information Systems program. This time I was an A student. I made the Dean’s List nearly every trimester and was on track to graduate Magna Cum Laude. I imagined landing on a Java team at a large engineering company. It felt like the plan had finally settled down.

Two trimesters before graduation, two friends kept trying to recruit me into a small ticket company. I kept saying no. I did not know what a ticket broker was, and it did not look like the future I had pictured. Then the dot-com bubble burst. Graduates who had expected strong development jobs were finding help desk work or nothing at all. I got nervous, called my friends, and asked whether the opportunity was still there.

I walked into the interview and told the owner that hiring me would be one of the best decisions he ever made. I asked for more money than my friends were making and promised I would be worth it. I also told him I could only work thirty hours a week until I finished school.

He hired me.

If my memory is right, I started July 16, 2001. Nearly everyone who knew I was coming was away at a conference. I found a spare computer, built it into something I could use, introduced myself to people, asked what they needed, and started solving a problem.

That part has repeated through most of my career. The title changed. The company changed. The industry changed. The plan changed more times than I can count. Sometimes I stayed too long. Sometimes I bet on people who did not bet on me in the same way. Sometimes loyalty opened a door, and sometimes it kept me standing in a room after I should have left. There were successes, disappointments, promotions, sales, new teams, side businesses, and several moments when I was sure I was finally about to follow the clean path forward.

There was never a clean path.

What I can see now is that the plans were never the most consistent part of the story. The pattern underneath them was.

I build. I solve problems. I walk into unclear situations, find the pieces, and try to make them work together. I did it with computers as a kid, with music as a teenager, with software in the ticket industry, with data and automation across other businesses, and eventually with Transcendent Software, CoffeeBreak, and Open Jibo Cloud.

That does not mean every turn was the right one. Adaptation is not the same as wisdom, and persistence is not always the same as progress. Part of getting older is learning that finding a way forward also means deciding what should not come with you.

Today, I am betting on myself again. The plan is different from the one I had at twelve, eighteen, twenty-three, or even a few years ago. It will probably change again. I hope it does. A plan that never changes is usually a plan that has stopped listening to reality.

The goal is not to find my way back to an old plan. It is to find my way back to the part of me that knew what to do before the titles, expectations, and detours made everything complicated.

Find the problem. Build something useful. Keep going.

Plans change. The work continues.

Building for Everyone Without Rushing the Door Open

I posted two videos recently that probably look like they are about different things.

One is a CoffeeBreak demo showing Persona. In that video, I walked through Atlas, Mara, and Sol, three different AI collaborators that all use the same underlying intelligence but respond in different ways. Atlas thinks like a systems person. Mara explains things in plain language. Sol can bridge between simple explanation and technical handoff.

The other video is about Open Jibo Cloud version 1.0.20. That one is more personal in a different way. It shows Jibo connected to the first public cloud node, responding faster, remembering my name, answering questions, playing “Word of the Day,” setting timers, dancing, and generally feeling a little more alive again.

On the surface, those are two very different projects.

One is an AI orchestration platform I am building for real work.

The other is a community effort to bring back a little robot that a lot of people still care about.

But in my head, they are connected.

They are both about making technology fit people.

That sounds simple, but it is where a lot of technology goes sideways. We build something powerful and then expect people to bend themselves around it. We give everyone the same interface, the same assumptions, the same workflow, the same level of technical complexity, and then we wonder why only a small group of people ever really benefit from it.

That is one of the reasons Persona matters to me.

I do not think AI should always sound like the same generic assistant. I do not think every person needs the same explanation. I do not think a founder, a developer, an operator, a designer, and a business owner should all have to interact with intelligence in the same way.

In the demo, I showed a simple example. Ask the same question to three personas and you get three different kinds of help. Then give them memory, and the answers start to become more grounded. Then give them behavioral direction, and the system starts adapting not just what it knows, but how it helps.

Atlas can give the code.

Mara can keep it non-technical.

Sol can explain it first and then hand over the technical version.

That is not just a tone change. That is the beginning of a system that respects the person on the other side of the screen.

The Open Jibo Cloud work is teaching the same lesson from a different angle.

There are people in the Jibo community who are very technical. They want to self-host. They want to run their own cloud on a computer or Raspberry Pi near their robot. They want control, and they are comfortable with setup.

There are other people who want a hybrid model. They may want to connect to a broader network, get access to shared skills, keep some portability, and still have some control over how their Jibo runs.

And then there are people who just want Jibo to work again.

They do not want to become cloud engineers. They do not want to read through configuration files. They do not want to understand every part of the stack. They just want the robot they loved to be able to find its server, hear them, respond, and feel like Jibo again.

All of those people matter.

That is why the public cloud milestone is exciting, but it is also why I keep talking about doing it responsibly. Standing up a public cloud is not just a technical accomplishment. It is a responsibility. Once something is public, other people start depending on it. Security matters. Reliability matters. Upgrade paths matter. Participation matters.

If the goal is for Open Jibo to be for everyone, then “everyone” has to include the tinkerers, the contributors, the self-hosters, the people who want managed cloud, and the people who are still deciding if they want to bring their Jibo back online at all.

That takes longer.

It is tempting to rush the door open when something starts working. I feel that temptation all the time. The demo works. The cloud responds. The robot dances. The AI remembers. The product starts to make sense.

But working once is not the same thing as being ready for everyone.

That has become one of the bigger lessons in this season of building.

Good technology is not just about proving that something is possible. It is about making the possible useful. It is about making it understandable. It is about choosing the right level of access, the right level of control, and the right amount of guidance for the people who will actually use it.

That is true for AI.

That is true for Jibo.

That is true for most of the systems we depend on.

I want CoffeeBreak to help people work with AI in a way that feels like it fits them, not like they are borrowing someone else’s idea of intelligence.

I want Open Jibo Cloud to bring Jibo back in a way that makes room for the whole community, not just the people who already know how to run the infrastructure.

And I want to keep building in a way that remembers the person on the other side of the system.

I have spent my career doing just that.

And honestly, this feels like the right time and place to be me.

If you want to check out the videos, here are the links: