The agent is the user

For about twenty years, buying software meant buying a tool.

You paid for a thing that helped a person do a job faster. The job stayed theirs. A CRM did not sell anything; it held the record of what your salespeople sold. A legal research product did not write the brief. The value was in making a competent person quicker, and the pricing followed the logic exactly — you paid per person, per month, because what you were buying was leverage on people you already employed.

That arrangement is so familiar it stopped looking like a choice. It was just what software was.

I have spent nine months building in a market where it does not hold, and I want to write down what replaced it, because it took me most of those months to say plainly and I said several wrong versions first.

What the market I sell into actually looks like

My customers sell things to American water utilities — pumps, meters, treatment systems, software, engineering services. There are tens of thousands of utilities, they are wildly different from one another, and almost everything about what they intend to buy is public: board minutes, capital improvement plans, budgets, rate studies. Public and unread, because reading them is punishing work that produces no visible output.

The existing answer to this is a data provider. Several companies will sell you a feed of utility information, or a database of published RFPs. They are useful. They are also, structurally, the same bargain as the CRM: here is the material, now go and do the job.

I described the problem with that on a call in April, before I could have told you it was a thesis:

They're all data providers, because you still have to do all the work. And that was true in the pre-AI world. That was the best you could do. You didn't have to do anything more — you would still get paid.

The reason that bargain survived is that there was no alternative. Nobody could sell you the outcome, because producing the outcome required judgment, and judgment was only available in people. So everyone sold tools and left the work where it was.

The sentence that made me take it seriously

I did not reason my way here. A customer told me.

By the spring I was handing over material people were genuinely pleased with. Deep profiles of utilities they cared about, lists of accounts they should be talking to, the reasoning behind each one. The feedback was good. And then two of them came back and said a version of the same thing:

This is great. I still don't know how to use it.

That sentence should be uncomfortable for anyone selling intelligence. It means the information was not the binding constraint. They now had something true and useful sitting in a document, and between that document and any changed outcome lay a set of unglamorous tasks nobody had time for — read it, decide who to contact, work out what to say, put it into the system, follow it up.

I responded by offering a week of my own time: sit with the sales team, watch how they work, and show them how to get value out of what I had given them. Which is a perfectly reasonable thing to do, and is also the tell. I was manually supplying the missing layer myself, one customer at a time, and calling it onboarding.

What is different now

Here is the distinction, as narrowly as I can put it.

A tool requires a competent user. Its value is capped by the attention that user can spare, which in a sales organization is close to zero — the whole reason the research does not get done is that the person who would do it has a number to hit this quarter.

An agent does not require a user in that sense. It can hold the context, do the reading, make the intermediate decisions and produce the thing at the end. I put it this way to someone in February, and it is still the sharpest version I have:

Their framework is really the SaaS world, in the sense that the user has to consume all that information and then do something with it. You're paying for that data and insight. My platform is going to evolve more into the agentic framework, where the agent or the AI is going to be the user. And then the customer just needs the final output — the final action.

The agent is the user. The customer is the beneficiary. Those were the same person for twenty years and they are not the same person any more.

That sounds like a pricing observation, and it is one, but the deeper consequence is that you can no longer describe your product as a set of capabilities. If you are selling the outcome, what you have to know is the work — every tedious step between a public document and a booked meeting. That knowledge is not architectural. It is not something you can derive at a whiteboard. It sits inside other people's jobs.

The two things I got wrong first

I thought the market might not be ready. In February I talked myself into a staged plan: build the ordinary SaaS product first, integrate with the CRM everyone already has, and move to agents later, once the sector had caught up. My exact worry was that I would build something too far ahead of where the market was.

That was a reasonable fear pointed at the wrong risk. The sector is conservative about interfaces, not about outcomes. Nobody in a water utility sales organization objects to work being done for them. What they will not do is log in to another dashboard — and a staged plan that began with a dashboard would have spent a year proving exactly that.

I thought I could work it out by building. I could not, and the correction was blunt: I stopped using the product and I stopped building it.

That is an uncomfortable thing to admit while calling yourself a software company, and it was the right call. I had a working thing and no confident account of what shape it should be, and no amount of further building was going to supply one — every hour spent developing was an hour spent compounding a guess. So the guessing stopped and I spent the time on calls instead.

The engagement that answered it

In June I took an enterprise engagement to build fifty utility profiles for a single customer.

Commercially it was the largest thing that had happened to the company. That is not why it mattered.

It mattered because doing that volume of work by hand, for one demanding buyer, is the only way I know of to find out what the work is. A single profile teaches you almost nothing — you can do anything once. Fifty of them exposes every step that is repetitive, every step that genuinely requires judgment, and, most usefully, every step you had assumed was one task and which turns out to be five.

What surfaced was not exotic. It was a list of jobs that were tedious, repetitive, dependent on assembling material from many places, and completely resistant to being done well by a person under time pressure. Which is a precise description of what an agent is good at, and a precise description of what nobody had automated, because until recently nobody could.

That is the differentiation. Not the model, which everybody has. Not the data, which is public. The workflows — the specific, boring, sector-shaped sequences of steps that produce an outcome somebody will pay for.

What I am building now

The platform is becoming a set of agentic workflows rather than a place to look things up.

I am aware of how that sentence reads. Every software company on earth has announced something similar this year, and most of them have wrapped a chat box around an existing product. The test I would hold myself to is whether the customer's work actually leaves their desk. If they still have to read the output, decide what it means and act on it, I have built a tool with better manners.

I should say plainly that this is not a thought I own. In March, Sequoia published Services: The New Software, which makes the general argument better than I could: that selling the outcome is more defensible than selling the tool, because every improvement in the model makes the work cheaper for you rather than making your product easier to replace. It draws the same line I had been drawing on calls, between selling a professional a tool and selling the finished work to the person who wanted it done.

I read it about a week after it went up, and my honest reaction was a mix of encouragement and deflation. The dates flatter me slightly — I had been saying "we are not a data provider" since the first week of February, and describing the agent as the user by the third — but arriving somewhere independently and three weeks earlier is not the same as being first, and it is certainly not the same as being right.

What I would say in my own defense is narrower. A general thesis is cheap and the specific workflows are not. Sequoia can tell you that services will eat software. It cannot tell you which eleven steps sit between a board meeting in a mid-sized water utility and a salesperson knowing to pick up the phone.

That part I had to buy with nine months and a hundred conversations.

What comes next

Over the coming weeks I am going to write up the workflows themselves — the specific use cases that came out of those conversations and out of the June engagement. Each one is a job somebody currently does badly, because they do not have time to do it well.

There are fourteen of them, and they run roughly in the order that one depends on another rather than in any order of importance.

The foundation is signal monitoring — reading board minutes, capital plans and budgets on the cadence a utility actually keeps. Everything else assumes it.

Built directly on that: contact intelligence and verification, knowing who to approach and being right about it; installed-base and contract-cycle tracking, what is in the ground, whose it is and when it comes up; bid and RFP capture with relevance routing; and screening, cutting a whole market down to the accounts one vendor should care about.

Then acting on it: outbound drafting and sequencing, CRM write-back — the step that decides whether any of the rest gets used — and scheduled reporting.

Then the ones that produce a document rather than an alert: RFP fit-check and response pre-fill, permit application drafting, and funding application drafting.

And finally the same machinery pointed at a different buyer: M&A and underwriting screens, vendor-ecosystem and consultant identification, and serving utility context through an API into somebody else's product.

If the thesis is right, that series is the more valuable half of it. The argument that agents change what software is has been made by better-resourced people than me. The list of what actually needs doing in one industry, learned by doing it, has not.