Hands Off the Wheel?

Picture two meetings in the same building on the same afternoon.

In the first, an engineering lead is reviewing a pull request. The author described what he wanted in a paragraph, let the model generate the implementation, skimmed the result, and shipped it. It works, mostly. The lead calls this vibe coding, and she doesn't mean it kindly. High-level intent, loose constraints, minimal oversight, fix it when it breaks. We have spent two years telling developers that this is not a strategy.

In the second meeting, three floors up, a vendor is presenting to the executive team. The slide says: define the goal, set the guardrails, and let the agent handle it. Nobody in the room calls this vibe coding. They call it the future of work, and they are reaching for a purchase order.

I build these systems. I run several of them in my own shop every day, and I think the progress is real. But I have started to notice that the thing we scold a junior for on Tuesday is the thing we sell to the CEO on Thursday, and the only difference is the vocabulary. The language changed. The behavior did not.

Three words I use every day

I spent the first part of my career in live event production, and that trade is ruthless about vocabulary. A cue is not a trigger. A hold is not a pause. When the show is running and forty people are listening to the same channel, a word that means two things gets somebody hurt. Software has never had that discipline, and the current conversation about agents is paying for it.

So here is how the words actually get used in my shop, as opposed to how they get used on a slide. The image at the top of this post is the version of this I'd draw for a passenger: three dashboards, three generations of driver assistance, and one question mark.

A chatbot answers. I ask Mason, the assistant on my site, a question about a case study, and it gives a good answer or a bad one, and that's the whole transaction. It's a reasonably complicated RAG (retrieval augmented generation) tool with lots of precisely structured information behind it, but it's still reactive. Success is a good reply, not a completed outcome somewhere else in the world, with good meaning the answer is relevant to the question and can be directly attributed to my own case studies or design documents in the corpus. And then Mason is done. Nothing happens after the conversation ends, unless I ask another question. That's the turn-by-turn nav at work. Tell it where you want to go, it figures out where you are and shows you how to get there, one instruction at a time, and your hands never leave the wheel.

An automation runs. Every month a job pulls together the material for my workday-AI guide so I can refresh it. It is triggered by a calendar, it follows a sequence I wrote, it produces a nicely interactive deliverable, and I decide what done looks like before it starts. There is a model in the loop now, which makes it more forgiving than a cron job from 2015, but the procedure is mine and the variation is bounded. I do not call it an agent, because nothing about it is pursuing anything. Even though I hope and believe the output to be valuable and useful, it is not doing anything one might call "learning"... it is simply executing. That's the cruise control and lane assist responding to the environment in very specific ways without any objective or decision-making beyond what I've set. One hand on the wheel, eyes still on the road.

An agent is more than the sum of the above. In the sense the market now means it, is handed a goal and some constraints and left to pursue the goal across many steps and cycles: observe, act, adjust, repeat, with tools, and with the explicit promise that I can stop watching. That last clause is the product. Nobody is paying a premium for multi-step tool use; they are paying to stop monitoring. No hands required... that's the promise of self-driving. If I'm buying that tool, I don't want to have to sit alert with my eyes on the road and my hands hovering over the wheel, ready to jump in at a moment's notice.

In practice these three bleed into each other, and the honest version of the taxonomy is that most of what is sold as an agent today is an automation with a language model making some of the decisions a script used to hard-code. That is a real improvement. It is not the thing that was presented to you in the pitch deck. The thing they showed on the slide, sustained goal pursuit with genuine revision of strategy over time, exists, but it is rarer, more expensive, and more fragile than the pitch admits.

I recently had a client ask for an agentic workflow to connect two tools which, it turns out, already offered an API driven integration and automation process that required no LLM. Maybe some analysis and inference could be added at the end, but the core request was really just a fancy script. They seemed a bit disappointed to not to be discussing an "agentic solution" but I framed it as a win... simple, manageable, proven. Still, the question remains... at what point does a chatbot with some workflow automation become an agent? I'll come back to that, because there is a distinction and it's worth exploring.

What the words are doing

The vocabulary problem isn't only the three nouns. It's the adjectives and verbs that get wrapped around them, because every one of them borrows from how we describe a person with a job.

Take "continuous." When a vendor says the agent continuously monitors your pipeline, what is running is a loop that wakes on a schedule or an event, does its work, and goes back to sleep. I have built that loop more times than I can count. It is periodic execution with a short period. Calling it continuous isn't a lie, exactly, but it invites you to imagine attention, and there is no attention. There is a timer.

Take "persistent goal ownership." In my systems that phrase decomposes into two very ordinary things: a success criterion that is stored somewhere durable, and some state that survives between runs so the next cycle knows what the last one did. A predicate and a row in a table. Useful, and I would not want to build without them, but ownership is a word we use for people who can be held responsible, and nothing in the loop can be.

Take "the agent decides." This is the one that does the most work in a sales meeting and the least work in the code. The model samples a next action from a distribution, shaped by the constraints and the tools you gave it. It is a very good sampler. But every decision it makes is downstream of a decision you made about what it was allowed to see and do, and when it decides wrong, the question of who set up those constraints is going to come back to you. Anyone who has followed the arguments over who is at fault when a car on autopilot hits something has watched that question get litigated in public. Notice that the answer has never once been "the car."

I notice this most sharply in Arch, my adversarial build engine, where one model builds and another is tasked with breaking the result. It is tempting to narrate that as a debate between two colleagues. What is actually happening is two sampling processes under two different prompts, bounded by a contract I wrote, running until a budget or a pass condition stops them. The metaphor of the argument is helpful for explaining it. It is harmful for trusting it. The mechanism is a discrete system optimizing toward a predicate until budget, policy, or failure stops it, and that is what it was yesterday, and what it will be when the next release doubles the context window.

The same move, aimed higher

Here is the part that has been bothering me.

When a developer vibe codes, we can name every step of the failure. He states his intent at a high level. He supplies loose constraints, maybe a few examples, maybe not. He generates and hopes. He supervises lightly, if at all, because the point was to not have to. And when it fails, he fixes it, which is to say he finally does the engineering he skipped at the front, except now under pressure and in production. Or, alternately, he just scraps it, adjusts the prompt and tries again. I have written before about why this is a bad trade, and I was not gentle about it. I have also done it myself, late at night, and paid for it the next morning.

Now read the agent pitch again with that list in your hand. State the goal at a high level. Supply guardrails, which is the word we use for loose constraints when the buyer isn't an engineer. Launch and hope. Supervise lightly, because the point was to not have to. And when it fails, escalate or restart, which is to say a human finally does the judgment work that was skipped at the front, except now under pressure, in production, and after the customer (or the stock market) noticed.

It is the same cognitive move. The only thing that changed is who is making it and what we call it when they do. When a junior coder does it we call it a problem and schedule a conversation. When a CEO does it we call it strategic leverage and schedule a panel discussion.

What makes this worse than a mere inconsistency is where the cost lands. The vibe coder at least owns his mess; the fix comes out of his own evening. The executive who buys the agent pitch does not inherit a mess so much as a role. She has become the oversight layer for a system she was promised would not need one, and she does not have the vocabulary to do that job, because the vocabulary she was sold was designed to make the job disappear. The monitoring did not go away. It moved to the most expensive and least prepared person in the building.

I think that's the honest description of the "set it and forget it" promise. It isn't false. It's a transfer. Someone always sets it, and someone always ends up having to do the "not forgetting". The car industry already knows this. It is why the manual for every vehicle sold with a self-driving feature tells you to keep your hands on the wheel and your eyes on the road, which is a strange instruction to find in the box of a product whose entire pitch was that you wouldn't have to.

What I call mine

I should be clear that I am not writing this from the sidelines. Auth/Technic runs on this stuff. So let me do the exercise on my own tools and see whether the words hold.

Tanzaku is my system of record for project operations. I built it from scratch to replace Trello, and it has models in the loop: they draft scopes, assess health, flag cards that need attention, and tell me what is drifting toward a billing problem. It would be easy to call it an agent on the website. It isn't one. It is a well-instrumented automation with good judgment at a few specific joints, and every one of those joints has a place where I look at what it concluded before anything leaves the building. The strategy is fixed. The judgment is allowed to vary inside it. I am accountable for all of it.

Arch is closer to the line. Two models, two prompts, one builds and one attacks, running in cycles until the contract is satisfied or the budget is spent. There is observation, there is adjustment, and there is a goal that persists across iterations. If I were selling it I could use every word on the vendor's slide and none of them would be false. And yet the thing that makes Arch worth running is not its autonomy. It is the contract I wrote before it started and the review I do after it stops. Take those away and what remains is an expensive way to generate confident code I haven't read. Which is really just vibe coding with extra steps.

The scheduled jobs are the easiest case. They run, they produce, I check. I have taken to calling them scheduled agentic jobs internally, which is an ugly phrase, but I prefer an ugly phrase that tells the truth to a handsome one that doesn't.

One of those jobs, a tool I wrote that is meant to identify public domain AI tools and determine if they are ready to download and archive, stopped working because it believed the system it runs on was out of storage space. As it turns out, the model had mistakenly started calculating free space from its own source directory which is on the boot drive, rather than from the dedicated and much larger storage drive. So for at least a week when I didn't look at it, it dutifully woke up, researched the current state of the art, documented all the exciting new tools that were ready to download, and then silently did nothing about it.

When I line these up, the pattern is consistent. The more I trust a system, the more deliberately I have bounded what it is allowed to vary, and the more I have budgeted my own time to look at what it did. The systems I would describe with the most autonomous language are the ones I watch most closely. That is not a paradox. It is the whole lesson.

Where the progress is real

None of this is an argument that the technology is a disappointment. If you had shown me Arch in 2023 I would not have understood it, much less believed what it can do would be possible two years later. Tool use is reliable now in a way it simply wasn't; a model can call a dozen functions in sequence, read the results, and recover from a malformed response without a human noticing. Planning within a single run is good. A model handed a messy, multi-step task will decompose it sensibly most of the time, and when it goes wrong it goes wrong in ways you can read in the trace. Short-term adaptation, the ability to try a second approach when the first one fails inside the same job, is the thing that makes these systems feel alive, and it works.

Put those together and you get bounded agentic workflows that beat anything we used to call RPA (robotic process automation) by a wide margin. The route planning I built for Ablitt's this year using Claude and Google's OR-Tools would have been a brittle mess of rules three years ago; today the hard parts are handled by a model that reads the situation, inside a structure that doesn't let it wander. That is the right shape for most of what businesses actually need, and it is worth real money.

What it is not is open-ended, durable revision of strategy with true autonomy. The system that notices its own goal was wrong, reframes the problem, and pursues the new frame for weeks without a person in the loop is not what anyone is shipping to small businesses in 2026. It exists in demos and in a handful of very expensive deployments with very large monitoring budgets, which is exactly the budget the pitch tells you not to plan for.

Conflating the two is where the damage happens. The buyer hears the second and receives the first, and then concludes that the technology failed, when what actually failed was the sentence that sold it. I have watched good tools get thrown out for not being the thing they were never going to be. That is the cost of the vocabulary, and it is paid by the people who were telling the truth about what they built.

The question that matters

So what am I actually suggesting here? Definitely not a moratorium on the word agent; that ship has sailed and I am not going to stand on the dock shaking my fist at it. I briefly fought against the word "Android" to define a telephone and I still mostly refuse to call LLMs "AI" but the refrain of "language changes" is destroying that line of effort. Rather than policing what words mean, what I really want is for the people on both sides of the table to ask a better question than "what does agent mean and is this an agent?"

The better question is: how much of the strategy this tool will apply is fixed, how much is allowed to vary, and who is accountable when it drifts? Ask that and the vocabulary stops mattering, because the answer tells you what you're buying. If the strategy is fixed and the judgment varies inside it, you have an adaptive workflow, and you should budget for someone to review its output. If the strategy itself is allowed to move, you have something closer to what I would call a true agent, and you should budget for a lot more oversight, because you have just hired a very fast-moving employee with little memory of yesterday and zero stake in tomorrow.

For the engineers and architects: I will try to hold you to a higher standard, as I do myself, and ask you to name the thing you built. If it is a scheduled job with a model in it, say so. If it is a tool-using control loop with a fixed strategy, say that. The precise phrase costs you nothing in the room and saves you the conversation in six months where the client explains what they thought they were getting. Unless, of course, what you're selling is "AI" in whatever shape, form or price range people will pay... in which case, you do you.

For the people who sign the checks: treat the "agentic" tooling you are being shown as a powerful, supervised automation until someone proves otherwise, and put the supervision in the budget on day one. The part of the pitch that sounds cheapest, the forgetting, is the part that will cost you the most, because it isn't a feature. It is a hole in the org chart that you will fill with whoever is standing closest when it breaks. And if you're a founder or the owner of a small business, that will be you. Ready to start vibe coding your operations? Strap in.

To be fair, though, the capability is real and it is getting better every quarter. The problem is that the vocabulary is running well ahead of the reliability, and a long way ahead of the accountability. I plan to keep building these systems and keep making them more adaptive. The difference is that my products won't carry a deliberately misleading "fully self-driving" label.

The last word, for now

We spent years telling engineers that "just tell the AI what you want and fix it later" was not a strategy. It is a little odd to watch the same advice get packaged for the people who sign the checks and called the next platform shift. Same pattern. Different audience. The audience deserves the same honesty.