9 min read

The Year the Tools Started Doing Things

Cinematic cover illustration for the essay "The Year the Tools Started Doing Things" by Craig Teich

For thirty years software waited for me to click. This year, for the first time, it stopped waiting.

I noticed it on an ordinary afternoon. I had asked a model to reconcile two spreadsheets — the dull, eye-glazing work of matching invoice numbers across systems that were never meant to talk to each other. I expected what I had always gotten: a wall of instructions telling me which columns to compare, which formula to paste, where I was likely to trip. That is what software has always handed me. A recipe. The cooking was still mine.

Instead it opened the files. It read them. It found the mismatches, flagged the three rows that didn't add up, and asked whether I wanted it to write the corrections back. I sat there for a second longer than I'd like to admit. Something in the relationship had changed, and it took me a moment to name what.

The calculator and the contractor

For my whole working life, the tools have been calculators. A calculator is a marvelous thing. You give it a problem, it gives you the number, and the number is correct in a way your own arithmetic never quite is. But a calculator does not pour concrete. It will tell you, instantly and without complaint, that your wall needs four hundred and twelve bricks. Then it sits there. The four hundred and twelve bricks are your problem. The mortar is your problem. The standing in the sun for two days is very much your problem.

A contractor is a different kind of relationship. You don't hand a contractor a formula; you hand him an outcome. I want a wall here, about so high, done by Friday. And then he goes away and does things — buys materials, swings a hammer, makes a hundred small decisions you never see — and the wall appears. You traded precision of instruction for delegation of action. You stopped specifying steps and started specifying ends.

What happened this year is that our tools crossed from the first category into the second. Not all of them, not all the way, and not always well. But the direction is unmistakable. For decades the entire art of using a computer was learning to translate what you wanted into the exact sequence of clicks the machine required. We called the people who were best at this "power users," and we were a little in awe of them. The agentic shift — the move from tools that answer to tools that act — quietly retires that whole skill. You no longer narrate the steps. You name the wall.

What "doing things" actually means

I want to be precise here, because "AI that acts" is the kind of phrase that means everything and therefore nothing. Let me ground it.

In the last stretch of the year the pieces arrived in a rush, and most people outside the field didn't notice because they arrived as features rather than fireworks. A model could now be handed a set of tools and decide, on its own, which to reach for. It could be pointed at a screen and click through it the way a person would, fumbling and recovering. A new connective standard appeared — a way of plugging models into the actual systems where work lives, your files and your calendar and your databases, so the model wasn't reasoning about your work in the abstract but reaching into it. And alongside all of this, a different sort of model: one that pauses to reason in steps before it acts, rather than blurting the first fluent thing that comes to mind.

Read those four developments together and a shape emerges. The first gives the tool hands. The second gives it eyes. The third gives it a way into the building. The fourth gives it the discipline to think before it grabs. Hands, eyes, a door, and a moment of forethought. That is most of what you need to stop being a calculator and start being a contractor.

None of this is finished. The model that reconciled my spreadsheets also, a week later, confidently "corrected" a column that didn't need correcting and would have happily written its mistake back to the source if I hadn't been watching. The contractor showed up, and the contractor was an apprentice. But you don't dismiss an apprentice because he's green. You supervise him, because you can see what he'll be.

The question changes underneath you

Here is the part that I think most of the conversation is missing, and it's the reason I wanted to write this down.

For two years the question we asked about these systems was a question about capability. Can it write a decent email? Can it pass the bar exam? Can it produce code that compiles? It was a fair question, and the answers kept getting more impressive, and we kept moving the goalposts because impressive is cheap and useful is dear. The whole debate lived in the realm of what can it produce — and a thing that merely produces is, in the end, just a very fast calculator. You read its output and you decide what to do. The judgment, and the liability, stayed with you.

The moment a tool can act, that entire framing collapses. The question is no longer what it can write. The question is what it should be allowed to do.

These are not the same question wearing different clothes. They are different in kind. A model that drafts a refund email is producing a thing I will read and send. A model that issues the refund has done something in the world, with my money, on my authority, while I was getting coffee. The first is an answer. The second is an act. We have spent the entire history of software not having to make this distinction, because software didn't act. It is dawning on us, late and all at once, that the interesting problems were never on the capability side. They were always going to be here, on the side of permission.

Permission is the new interface

I run a company that builds these systems — agent architectures meant to be installed not at the level of the corporation but at the level of the individual person who actually does the work. And the thing I find myself thinking about most is not the model. The models are extraordinary and getting more so on a schedule that no longer surprises anyone. The thing I think about is the fence.

When you hire a contractor, the contract is mostly about scope. You don't write down how to lay a brick. You write down where the wall goes, what you'll pay, what counts as done, and — crucially — what he may not do without asking you first. Don't touch the load-bearing wall. Don't spend over this number without a call. The whole document is a structure of permission. We never thought of it that way because the permissions were carried by social trust and a lifetime of human norms. With software, none of that exists. Software has no instinct that says I should probably check before I wire money to a stranger. It has whatever fence you build, and nothing else.

So the work that matters now — the engineering work, but also the management and the legal and the plain moral work — is the work of drawing those fences well. What may this agent do on its own? What must it pause and ask about? Where is the line between a step it can take and a step it must surface for a human to approve? Get the fence too tight and you've built another calculator that pesters you for permission to add. Get it too loose and you've handed your credentials to an enthusiastic apprentice and gone to lunch. The art is in the fence, and almost nobody has built one of these before, which means almost everyone is about to.

I suspect — and I'll mark this as a suspicion, because anyone who tells you they know how this lands in three years is selling something — that the org chart reorganizes around this question faster than around any technical one. The companies that win the next stretch won't be the ones with access to the smartest model; access to intelligence is becoming a commodity, priced by the token. They'll be the ones who figured out, earlier and more carefully than their competitors, what to let the machine do and where to keep a human hand on the lever. That is a question about trust and accountability dressed up as a question about technology. It usually is.

The skill nobody listed on the job posting

There's a quiet consequence in all this for the people who do the work, and it's the part I find genuinely hopeful.

For thirty years, getting a computer to do your bidding required you to think like a computer — to break your intent into the literal, unforgiving steps a machine could follow. That favored a particular kind of mind. The agentic shift inverts it. The valuable skill is no longer translating yourself into the machine's terms. It's the older, more human skill of delegation: stating an outcome clearly, setting the boundaries that matter, knowing which decisions you can hand off and which you must keep, and catching the plausible-looking mistake before it costs you. That is what good managers do with people. It is what good editors do with writers. It turns out to be what we now do with software.

I spent a lot of years being told I was bad at the click-the-right-sequence kind of work — too restless for it, always wandering off to the more interesting thing. It pleases me, a little, that the part I was good at, the naming of the wall and the trusting of the right people to build it, is the part the new tools reward. Though I'd be lying if I said the apprentice never makes me nervous.

The calculators aren't going away. We'll keep them for the same reason we keep calculators: for the days we want the number and the cooking is ours. But the contractor has arrived, hammer in hand, asking what to build. The thirty years of clicking are over.

What he builds is up to us — and so, entirely, is what we let him touch.