We are not a data provider

This spring a large software company with a sales team dedicated to water asked us the question this piece is about. They had just reorganized their sellers by territory and account segment, and each seller needed a list of utilities to work, with a reason for each one that they could defend. They already knew which utilities were big, which had problems, which had money and which were under a consent decree. What they could not do was say why number fifteen on the list was fifteen and not one hundred and eighty-five. Their word for what was missing was fidelity.

They liked the profile, and then they asked: do you give us an API to that data so we build our own views, or do you build the screens and maintain them for us? They had a business-intelligence team that could stand up dashboards quickly. An API would give them a refresh on whatever interval we agreed and, once they trusted it, their own instance with no screen of ours anywhere in it. A couple of weeks earlier a large manufacturer had asked for the same thing in a different form. They wanted to feed it into their internal aggregator and measure which of it the reps clicked into the CRM.

My reflex answer to both was a sentence I have said in almost every conversation for a year, usually in the first five minutes and usually before anyone has asked: We are not a data provider.

I meant it, and I still do. I believe the data is not the product. The sector is full of places to buy rows about utilities, and none of them close the gap between information existing and information being used. Every workflow I have written about makes that argument in some form. And both of these customers were asking for an API. So either that workflow contradicts all the others, or the sentence means something narrower than it sounds. Working out which took me longer than it should have, so I am writing it down.

What the sentence was protecting

My objection to being a data provider was never about pipes. It was about where the work ends up.

A data provider hands over rows, and the customer does the analysis, makes the judgment and takes the action. That model is fine, and this market already has plenty of it. The problem is that it puts every hard part of the job back on the person who did not have time for it in the first place. My whole argument is that the tedious part has to move off their desk. Relabeling it and handing it back does not count.

What that objection does not require is that we own the screen. A person logging into our dashboard is one way to deliver the work, and I have been fairly rude elsewhere about how much people enjoy logging into anything. If the finished work arrives somewhere else, in their system of record, in a document or in their own software, the argument still holds. What matters is that it arrives finished and the customer is not left holding the raw material.

So we are not a data provider, and we can still offer an interface. The two fit together once I admit that my objection was about the division of labor, and the delivery mechanism was never the issue.

The three shapes this takes

None of this is shipped. We are building it, and I am writing about it now because the shape is already decided and the shape is the argument. There is nothing to sign up for yet. Read what follows as a direction with work behind it, which is a weaker claim than a product announcement.

Into another company's product. This is for somebody building software for utilities, or for people who sell to them, who wants utility context inside their own product so their user does not have to open a second thing. What they get is the resolved, structured answer rather than a table dump: this utility, this situation, this evidence, with the provenance intact so their user can check it in their own interface.

Into an agent. This is the one that connects back to the essay that started all of this. If the agent is the user, the most direct form of this product is a set of tools another company's assistant can call while it is doing something else. There is no screen, and no API that a developer spends three sprints wiring up. A rep asks their own assistant about a utility, the assistant reaches for us the same way it reaches for a calendar, and the answer comes back grounded.

I wrote that essay in August, arguing that the agent would be the user. What I had not thought through then was building something that takes that literally.

And the private lens. This is a customer's own material (their installed base, their notes, their commercial context) held against the public record, so the answers are specific to them. It changes the shape of the product the most. Instead of one corpus that everybody queries, it becomes a shared foundation with a private layer for each customer. That means a different security posture and a different set of promises, which is why it cannot be done casually.

So the work leaves our screen in three ways: into someone else's product, into someone else's agent, and up against a customer's own data.

Correct and unreachable

There is a sentence in our own internal planning that I keep coming back to: the intelligence is correct and unreachable.

A rep researching an account opens the utility's website, the agenda portal and their CRM, which are three places we are not. Then, if they remember, they open a fourth place where we are. Every workflow I have described is only valuable if somebody sees its output, and most of them dealt with that by making the output better. This one admits that the remaining problem is not quality. It is location.

I think that is the least glamorous conclusion anyone could reach about agentic workflows, and I believe it is the correct one. The interesting engineering is in reading fifteen years of minutes. Whether any of it matters depends on whether it shows up where somebody was already looking.

What it cannot do

It cannot outsource the boundary. Everything served this way carries the same limits as everything else we build. The public record stops where it stops, coverage is what it is, and a claim without a source does not ship. The temptation with an interface is to let it become a pipe that answers whatever it is asked, because the consuming system will show the answer confidently either way and nobody will see our caveats. If not covered is a real answer in the product, it has to be a real answer in the interface too. That is harder to insist on when the caller is another company's software with its own ideas about error states.

It cannot make us the last mile without making us responsible for it. Once the output is inside somebody else's product, their user experiences our mistakes as theirs. That is a heavier obligation than a dashboard carries, and it is a reason to go slowly in a direction that is commercially attractive to rush.

What these have in common

The workflows I have written about share something smaller than the list suggests. Each one is a job somebody in this sector already does badly, because there is not enough time to do it well. None of them is a job nobody was doing. A utility publishes its intentions, and somebody should read them. The same goes for knowing who wrote a specification, finding the money that exists, and signing the application that has to be filed.

These jobs were always possible. What changed is that reading, assembling and drafting stopped being the expensive part. That moves the scarce thing to judgment, and it makes a set of tasks that were always important and never urgent cheap enough to do.

The limits in every workflow come down to one line. The system works from the public record, which runs out where it runs out. The system assembles and a person decides, and the output stays a draft until somebody owns it. The workflow stops where somebody's judgment, license or relationship begins. Every time I have been tempted to move that line, it has been for commercial reasons, and never because the line was in the wrong place.

Still going

This is where the work has got to, and some of what comes next is already visible. First, going back through completed procurements to learn where they started, so that the claim that the warning is there gets checked instead of asserted. Second, the utility-facing side, which so far has one piece and deserves more. Third, whatever a customer asks for next month that none of this anticipated, which has been the source of about half of what is described above.

So take this as a description of the work as it stands. The monthly build log is where the parts that did not work will show up first. At AquaIntel we are building this now: the same resolved answers, with their sources attached, delivered into your product or your agent rather than onto a screen of ours.