The Agent's Ticket

Part three of three in a series that starts with AI Native Is Not a Tool Decision. Before this came DevOps 3.0 and The Documentation Was Never the Problem.

Four Things Have to Be True

The two previous posts were infrastructure. A platform, and a written record of what the company knows. Neither of those is the point. This is the point: deciding where an agent belongs, putting it there, and living with the consequences.

Most companies have some phrase for the bar you have to clear to get hired. Ours is the ticket. So when I needed a name for the tests an agent has to pass before we hand it a job, the name was already sitting there. Four things have to be true, and working out whether they are is most of my week now.

Look at what those four are. Number two is the entire subject of the platform post: whether there is anywhere for an agent's work to actually run. Number three is the entire subject of the post about writing down what the company knows. Number four is a post I wrote in April about why securing agents is a question of perimeters and trust rather than content filtering.

Which is why those came first. Three quarters of this checklist is infrastructure you either have or you do not, and if you do not, no amount of enthusiasm gets an agent through the gate. Most failed AI pilots I hear about failed on two or three, and were diagnosed as the model not being good enough.

That leaves number one, which is the only one that is not an engineering problem.

Why "Should We" Is the One People Skip

You cannot buy it, build it, or delegate it. It requires the company to have an opinion about what it is for. So it gets skipped, and the skipping is invisible until something embarrassing happens.

The useful form of the question is the last one. What breaks if it is wrong?

We sell software to car dealerships, and a good deal of what we do comes down to telling somebody what a car is worth. So: a wrong number in an internal analysis costs a colleague an hour. A wrong number in a valuation a customer relies on costs trust, and trust is not a feature of that product, it is the product. On a process map those two tasks look nearly identical. They are not remotely the same decision, and no amount of tooling will tell you which is which.

Here is roughly where we have landed on what we stop doing and what we lean into.

And one rule about how you are allowed to talk about that table, which I would put on a wall if I were the wall-poster type:

"Mechanical" is about the task. Never about the person doing it.

I have watched that distinction collapse in other companies and it is fatal. The moment "mechanical work" becomes a description of a colleague rather than of an activity, you have lost the room, and you deserve to have lost it. The person doing a repetitive job is usually the person who understands it best, which makes them the most valuable participant in automating it and the easiest to insult while you do.

What It Actually Bought Us

Everyone writes the theory post. Almost nobody writes the before-and-after, so here is ours, from the function where the change is most complete.

Our marketing people used to spend a large share of the week on production. Doing the market analysis. Sitting and crunching the numbers. Assembling each publication and each newsletter by hand. That was the job, and it consumed the job.

They still produce the content, and I want to be exact about that, because the version of this story where the humans stopped writing is both wrong and irritating. They still decide what is worth saying. They still own whether it is any good. They do it with AI now, and the quality is not the thing that gave.

What changed is the balance of the week.

Far less of it goes on producing each artifact, and far more goes on two things. First, working out who we should be talking to, which they always wanted to do properly and never had the hours for. Second, and this is the part that surprised me, building the machinery that gets the work out of the door.

In engineering terms, the question moved from what do we deploy to how do we deploy. Not what to say, but the pipeline the saying travels down: the procedures, the checks, the distribution, where in that chain an agent belongs and where a person has to stay. That is platform work. It is simply pointed at publishing rather than at production systems.

The results have been the best we have had. More published, in more countries, reaching more people than in any comparable period, and none of it at the expense of the work itself. I will leave the numbers there, partly because one good quarter is not a law of nature, and partly because the numbers are not the interesting part.

The interesting part is that this is why the job title go-to-market engineer has appeared in the last couple of years, and why it first sounds like nonsense. It is not nonsense. It is a marketing function discovering that it now needs a platform discipline.

Every Function Is Becoming a Platform Function

Once you see it in one function you see it everywhere. Marketing builds pipelines instead of artifacts. Sales builds repeatable account workflows instead of bespoke decks. Operations builds monitoring instead of reports.

Which is the real reason the platform post was not an engineering post. If every function is doing platform work, then the platform team's customer is the whole company, and the interesting question about your internal tooling is no longer whether developers like it.

And the competence that survives is the same one that survived inside our product teams: the judgment about what to do, in what order, for whom, and being on the hook when it lands. That did not collapse toward the middle. It became almost the entire job.

The Boring List

At a recent company session I put everyone into groups of three or four and asked one question: where would you most like AI to take something off your plate? I said there were no wrong answers and that boring and repetitive was exactly what we were looking for.

Here is what came back.

• Something that keeps our data clean without a person chasing it. The checking, the fixing, the spotting of patterns. The world outside is messy and nobody is to blame for that, but somebody loses a day a week to it.
• Setting up a new customer's account from the request, rather than by hand. Read what they asked for, match their branding, configure it, done.
• Watching the things nobody is watching. The half-finished process, the quiet failure, the performance dip that goes unnoticed until a customer mentions it.
• Pulling product feedback out of customer conversations automatically, and then actually following up on it, instead of it dying in somebody's notes.
• Customer reports at the press of a button, where the agent's numbers and the account manager's numbers agree, because today they sometimes do not.

I added one of my own: sweep every recorded customer conversation for product feedback nobody wrote down. Every company is sitting on that pile and almost nobody reads it.

Notice what is not on that list. Not one person asked for help being creative, or strategic, or with a difficult conversation. Given a free wish, people asked for the machine to take the machine work. They know exactly what they want to keep, and they are right about it.

Three We Are Actually Building

From Private AI to Shared AI

Now the distribution problem, which is bigger than any of the above and which I did not see coming.

Almost everyone here has the tool. Around ten of us account for the overwhelming majority of the usage. That is not a training gap you close with a workshop, and I have run the workshops, so I can tell you.

What changed it was agents moving into shared spaces. Claude in Slack, in the channel, in the thread where the decision was made.

It is not that the agent is cleverer in a channel. It is identical. The difference is that it turns out to be a fantastic way to learn, because instead of sitting down with individuals and teaching them one at a time, we learn from each other's interactions.

You watch a colleague you trust prompt it confidently and without hesitation. You see that it is safe. You see that it produces something real. And the barrier for you doing it next time drops, without anyone having to book a session called now we learn Claude.

Putting agents where everyone can see them does not just communicate. It teaches best practice sideways.

I had assumed this was a training problem, and training problems have training answers: curriculum, sessions, a champion per team, a wiki page nobody opens. All of that is a mechanical transfer model. Someone who knows sits down with someone who does not, and the knowledge moves one person at a time, at enormous cost, losing most of itself in transit. It is the same lossy handoff that made handbooks fail, which I wrote about in the previous post.

What actually works is not transfer at all. It is observation. You are not taught the technique, you watch someone use it on a real problem you also have, and you absorb four things at once that nobody could have written down for you: that it is worth trying here, roughly how much context to give it, what a good result looks like, and that the person who did it did not get in trouble.

That last one does more work than the other three combined. Most of what stops people is not ignorance of the tool. It is a reasonable fear of being the person who broke something in public, or of looking slow in front of colleagues while they fumble with it. Watching a trusted colleague do it casually in a channel dissolves both, and no workshop can.

There is a second-order effect I did not anticipate either. Because it happens in the open, the good patterns propagate and the bad ones get corrected in passing. Someone asks for something badly, gets a mediocre answer, and a colleague reframes the request in the thread. That exchange teaches everyone reading it, permanently, at no cost to anybody. We accidentally built a review culture for prompting without ever proposing one.

Which is why my advice to anyone stuck at low adoption is not to run more training. It is to move the agents to where people can see each other use them, and then get out of the way. Whether someone uses this well should not depend on who happened to work out which button to press.

The Honest Part About Jobs

I am going to say this plainly, because the vague version is worse than useless and everybody can smell it.

We use AI to amplify people, not to replace them. Replacement is not the goal. The goal is to amplify the people we already have.

And yes, inevitably, that means hiring fewer people to do a given job, because fewer people can now do it. Both of those sentences are true at once and anyone who tells you only one of them is selling something.

What I do not think it means is a race to the bottom on employment. If the company grows and the success grows, we will most likely be more people, not fewer. Just on a different curve. We will need people, we will need a lot fewer of them per unit of output, and the ones we hire will spend far less of their week on mechanical repetitive tasks. Our CEO put the ambition as wanting the power of a five-hundred-person company without having to add five hundred people, and I think that is both the honest framing and the achievable one.

Roles get vastly redefined. That part is not a maybe.

Some work processes will disappear. Things people do today will not be part of their work tomorrow. When something goes away, something has to take its place, and here is the uncomfortable clause: you have to want to move towards it. Nobody can do that part for you, and it is the part where I have the least to offer as a manager. I wrote about the emotional weight of that in It Wasn't Wrong, and about the labour-market version, which is worse and quieter, in They Don't Feel It Yet.

How the Week Actually Goes

My job, in four parts, in the order they consume time.

• Make it possible. Access, data, systems, wiring, security. Criteria two and four.
• Orchestrate what we know. Getting what the company knows out of people's heads and into a form an agent can read. Criterion three, and the slowest of the four by a wide margin.
• Teach the practice. Worked examples, and building the first version alongside someone rather than for them.
• Judge criterion one. Which is the actual job, and the one nobody can do from a distance.

The boundary that matters: adoption inside a team belongs to that team, not to me. A central AI function that owns whether everyone else improves is a central AI function that fails, because the person who knows which twenty minutes get wasted every Tuesday is never the person at the centre. My job is to make it possible and to show how. It is not to own the outcome on someone else's behalf.

The Bottleneck Moved

A year ago the interesting question about any given task was can it. That question is mostly settled now and gets more settled every month. An agent could work autonomously for about thirty seconds in 2022, about two hours in 2025, and around fourteen hours in 2026. Nobody is going to win an argument by betting against that curve.

The interesting question is should it, and there is no benchmark for that one. There is no leaderboard, no eval, no vendor with a solution.

Which is why I am not especially proud of the four criteria as intellectual work. Three of the four are checklists, and checklists are what you write down so you stop forgetting things. Only the first one is genuinely hard, because it asks what your company is for and which parts of that you refuse to hand over.

That is the one that will still be hard in five years. Everything else in this series is plumbing, and plumbing is the part you can copy.