Nobody reads the minutes
First in a series on the agentic workflows we have built. This one is the base of almost every conversation we have: a water utility publishes its intentions months or years before it buys anything, in documents no salesperson has time to read. Here is what the job looks like by hand, and what it looks like when an agent does it.
A water utility will tell you what it is going to buy. It will tell you in public, in writing, and usually two or three years before it writes the purchase order.
It does this in board minutes, capital improvement plans, budgets, rate studies and engineering reports. All published. All free. Almost none of it read by the people whose job would be easiest if they had read it.
That gap — between information being available and information being used — is the base of nearly every conversation I have with a vendor selling into this market. It is also the first workflow we built, and everything else in this series is built on top of it.
The job, as it exists today
Suppose you sell pumps, or meters, or membrane systems, and your territory is some slice of the tens of thousands of American water and wastewater utilities.
Your problem is not finding out that a project exists. By the time a request for proposals is published, you already know — everyone knows, that is what publication means — and the specification has usually been shaped by whoever was in the room a year earlier. You are bidding on a document someone else helped write.
So the job is to be in the room earlier. Which means knowing, for a utility you do not work with yet, that something is forming: a plant is aging badly, a consultant has been engaged, a budget line has appeared, the same piece of equipment has been complained about at three consecutive meetings.
All of that is in the minutes.
Why nobody does it
Not because it is difficult. Because it is enormous and boring and nobody is paid to do it.
A single utility, gone through properly, is several hundred documents — often three or four hundred, sometimes past a thousand once you include a decade of meeting minutes and the appendices nobody opens. Multiply by the two hundred utilities in a modest territory.
Then consider who would do the reading. In most vendors this lands on a salesperson or a business development rep who has a number to hit this quarter. Reading minutes produces nothing this quarter. It is the definition of important and not urgent, which in a sales organization means it does not happen — not through laziness but through correct prioritization of the incentives in front of them.
And the work does not get easier with practice, because every utility publishes differently. Some have a tidy archive going back fifteen years. Some post a scanned PDF of a printout. Some bury the agenda packet in a content management system with no stable link. There is no format. There is no standard. Each one is its own small research problem, which is exactly the kind of task that defeats a script and exhausts a person.
What the workflow does
The word "monitoring" makes this sound like a search alert. It is not, and the difference is the entire point.
Find the sources. For each utility, work out where its material actually lives — the board packet archive, the finance page, the CIP, the state regulator's filings. This is per-utility work and it is the least glamorous part of the system.
Pull on the cadence the utility actually keeps. Boards meet monthly. A profile assembled today is stale after the next meeting, so the workflow returns on the utility's schedule, not ours.
Make the documents machine-readable. Scanned pages, print layouts, tables that are pictures of tables. This is where most of the engineering has gone and none of it demonstrates well.
Extract candidate signals. Not keywords. The things that indicate a procurement is forming: repeated complaints about a specific asset, a condition assessment commissioned, a consultant appointed, a line item appearing in a capital plan, a rate increase justified by a named project.
Filter for the vendor, not for the utility. This is the step that makes it a workflow rather than a database. The same board meeting means different things to a pump manufacturer, a metering company and an engineering firm. Relevance is a function of who is asking.
Resolve it into an action. Not "here is something interesting." Something a named person can pick up: this account, this development, this is why it matters to you, this is who to contact, this is what to say.
What it looks like in practice
An illustrative example — not a customer, and not a real utility.
You sell pumps. In a utility you have never sold to, the workflow reads a set of minutes in which the operations manager mentions, for the third meeting running, that a station keeps tripping and maintenance is eating overtime. On its own, noise. Four months later the board approves a modest sum for a condition assessment of that station. Also, on its own, routine.
Two months after that, the assessment is accepted and the capital plan gains a line for station rehabilitation in the next fiscal year.
Individually, three unremarkable entries in three long documents nobody read. In sequence, they are a procurement forming with roughly eighteen months of warning — enough time to be the vendor whose equipment the consultant has already seen, rather than the one who reads about it when the RFP publishes.
The workflow's value is not that it found any single item. It is that it held all three, across eight months and three hundred pages, and noticed they were the same story.
An alert is not the deliverable
We learned this by building the wrong version first.
If the output of monitoring is a stream of notifications, you have built a very sophisticated way of being ignored. A salesperson who receives fifteen alerts a week will read them for a fortnight and then filter them into a folder they never open, and the more accurate the system becomes the faster that happens, because accuracy increases volume.
So the workflow is only finished when the signal has become an assignable piece of work sitting in the system the team already uses. If someone still has to read the output, decide what it means, and act on it, the tedious part of the job has not moved. It has just been relabelled.
What it cannot do
The record is public until it is not.
Everything above rests on the assumption that enough of what matters gets published, and for procurement intent that assumption holds up remarkably well. It stops holding at the asset level. Make, model and serial number are not in the minutes. They are in a maintenance system inside the utility, and no amount of reading gets you there.
We hit that wall properly for the first time earlier this year, on a question a customer had actually asked, and the honest answer was that the workflow could get within one step of it and no further.
It is out of scope, and deliberately so. Every route to that data leads somewhere I do not want this to go. You can ask the utility to hand over its asset register, which puts a vendor in the position of making an awkward request of the customer they are trying to sell to. Or you build on privileged access — at which point the thing I have been describing, a workflow over the public record that runs at any utility in the country without anyone's permission, quietly becomes something else, something that works where you have a relationship and nowhere else.
So it stops one step short, on purpose. It will tell you that a station is being rehabilitated, when it was last assessed, who assessed it, and what the utility said about it across three meetings. It will not tell you the serial number of the pump in it. Somebody has to walk in and ask — and that somebody is the salesperson, which is the right division of labor anyway.
It is worth being clear about that boundary, because the failure mode of writing about your own product is implying it has no edges. This one has a very specific edge and it is the same edge for everybody in this market.
Next
The next pieces in this series take the workflows that build on this one: verifying who to contact, tracking installed equipment and contract cycles, and getting the result into the system where the work actually happens.