An unplanned use of what you built: pick one of three ways to handle it
Decide how to treat an unplanned use when it appears in your run log, before anyone asks.
Key points
- The run log shows it before they ask
- Three moves remain while it is unsaid
- Judge on tested inputs, not frequency
- One line out, the same line kept
Contents
An unplanned use shows up in your run log before the request does
A&A perspective
An unplanned use is a job that is not in the estimate or the spec, being done by something you built with AI. Sometimes a different department inside your own company starts it. Sometimes it starts on the customer's side, with a system you delivered.
A&A perspective
The people using it are not in trouble, so nothing reaches you. While nothing reaches you, month after month, the questions and small fixes for that use quietly take your own hours. By the time someone asks, there is no room left to say no.
A&A perspective
The same thing does show up earlier, on your own side, in the record. By run log we mean a record of when a job ran, which entry point it came through, and what kind of input arrived. An entry point is the route by which input reaches the system. How often it ran, the kind of input coming in, the time of day: one of these drifts from what you assumed when you built it.
A&A perspective
This holds both for a system you delivered to a customer and for one you run only inside your own company. A delivered system is passed to another job inside the customer; your own system travels outside the team that built it.
From the sources
Genspark is a company whose AI service turns a single instruction into documents and tables. Anthropic publishes a customer story about it. That page says users invented use cases nobody at Genspark had planned for.
From the sources
The same page gives examples. A New York real estate analyst now produces investor pitch decks in hours, work that used to take weeks of multi-person research. Japanese seafood industry CEOs use it to analyze domestic demand and source new leads.
A&A perspective
Automate & Augment (A&A), who writes this article, reads the story this way. What matters is not that the uses multiplied, but that they multiplied before the builder knew.
From the sources
Gumloop sells tooling for building workflow automation. In February 2026 it published how it runs its own support. It writes that its support team has only two people.
From the sources
According to that post, an agent runs every 30 minutes and picks out the users with the most errors and anomalies. The team can identify bugs and reach out before a user even files a ticket. The same post also describes a workflow that categorizes every support conversation so the team can see trends.
A&A perspective
Both companies ship one product to many users. When you build something for one party instead, a new use arrives by a different route. The number of users does not grow; what you handed over gets passed to another department or another job inside that party.
A&A perspective
In both accounts the subject is finding defects early. Neither says where to draw the line around what you look after. What A&A takes from these two companies is only the order: the record speaks before the other side does.
Hypothetical example
What follows is a hypothetical example, not a record of a real customer. Say you built and handed over a system that produces monthly invoices. In the run log, a job that is not in the estimate runs every week: an export of the last two years in one go. At this point the people using it have said nothing.
There are only three options, and waiting removes two
A&A perspective
There are three moves available for an unplanned use. Take it into what you look after as it is. Bound it out as not covered. Rebuild it as separate work. It is one of these three.
A&A perspective
Taking it in means absorbing the coming questions and fixes inside the current promise. Bounding it out means not answering for that use and leaving it to the other side. Rebuilding means designing that use again as a proper feature. If you delivered it to a customer, the third one is a separate quote.
A&A perspective
Which of the three you can still choose is settled at the moment you notice. While it is only in the record, all three remain.
A&A perspective
By the time the request arrives, the use is already a step in the other side's process. Bounding it out stops their work, and rebuilding makes them carry the cost of the pause. So in practice only taking it in is left.
A&A perspective
This three-way split is A&A's own.
A&A perspective
The opposite view also holds: drawing a line before anyone is in trouble is too early, and judging case by case after the request keeps the relationship calmer. Even then, keep the date the use first appeared in the record. With a date you can later say when the unpaid support began.
Hypothetical example
In the hypothetical example, you decide in the week the two-year export appears in the log. Running weekly, it will be asked about next month.
| Point of comparison | Still only in the record | The request has arrived |
|---|---|---|
| Moves available | Take in, bound out, rebuild | In practice, take in only |
| Who decides | You | The other side's timing |
| If you bound it out | Their work does not change yet | Their work stops |
| Cost of rebuilding | The redesign only | Plus their loss while paused |
| How it reads to them | A heads-up given early | Easily read as a refusal |
Choose on tested scope, not on how often it runs
A&A perspective
When choosing among the three, do not use how often it runs. The more often it runs the more you want to take it in, and the more unpaid work comes with it.
A&A perspective
Use three questions instead.
A&A perspective
First: can you account for the answers this use produces within the range of inputs you tested? If inputs of a shape you never tested are mixed in, taking it in means guaranteeing something you have not checked.
A&A perspective
Second: who notices first when it fails? If it shows in your record, you can take it in. If it is only visible on the other side's floor, bound it out, or make building the detection separate work.
A&A perspective
Third: what part of the original design does a fix touch? If a setting at the entry point is enough, it leans toward taking it in. If the core of the processing has to be rewritten, it is a rebuild.
From the sources
The Gumloop post says an agent alerts a human if, and only if, a finding is actionable. A line is drawn so that not everything in the record goes to a person.
A&A perspective
A&A reads this as the same line being needed both in bespoke delivery and in a system you run yourself. Rather than handling every unplanned use in the record, narrow what you handle with the three questions.
A&A perspective
One caution. An unplanned use is not always good news. If the other side's use has spread into a range whose safety you have not checked, the call to stop comes before the call to take it in.
A&A perspective
This whole order assumes a run log exists in the first place. Deciding what the record holds before delivery is the subject of a separate article.
Hypothetical example
In the hypothetical example, the two-year export could be capped by a setting at the entry point. Failures show in your own record. The range of inputs matched the monthly case you had tested. So it leans toward taking it in.
Put the decision in one line and keep the same line
A&A perspective
Deciding alone changes nothing on the other side. Say nothing and the situation is the same as having decided to take it in.
A&A perspective
One line is enough. Name the use, say which of the three you chose, and give one reason.
A&A perspective
There are three places to put it: the covered-scope field of the maintenance contract, the monthly report, or the next estimate. Any of them works, as long as it goes out before money moves. If you delivered it to a customer, that means before the next invoice or renewal. A line drawn after an invoice reads as notice of a price increase.
A&A perspective
When you bound a use out, write what the other side can do instead on the same line. A line on its own reads as a refusal.
A&A perspective
Keep the decision on your own side too: the name of the use, the date it first appeared in the record, the option you chose, and one line of reasoning. It becomes the precedent you reuse when a similar use turns up.
Hypothetical example
In the hypothetical example you would write: "Exports of past periods are covered by maintenance. The limit is 24 months; anything beyond that is quoted separately."
Summary
A&A perspective
An unplanned use appears in your own run log before the other side asks about it.
A&A perspective
At that moment you can still choose among taking it in, bounding it out, and rebuilding it. After the request arrives, only taking it in is left.
A&A perspective
Choose on whether it falls inside the range of inputs you tested, not on how often it runs.
A&A perspective
Send the decision in one line before money moves, and keep the same line on your own side.
An unplanned use appears in your own run log before the other side asks about it. While it is only in the record, three moves remain: take it in as it is, bound it out as not covered, or rebuild it as separate work. By the time the request arrives the use is already a step in the other side's process, so in practice only taking it in is left. Choose on three questions rather than on how often it runs: whether you can account for it within the inputs you tested, who notices a failure first, and what part of the design a fix touches. Send the decision in one line before money moves, and keep the same line on your own side. An unplanned use is not always good news, though: if it has spread into a range whose safety you have not checked, the call to stop comes first. And the whole order assumes a run log exists.
FAQ
If the other side asks first, is it already too late?
Not too late, but fewer moves are left. Bounding out a use that is already embedded in their work stops that work. In that case take it in for now and set a limit on period or volume on the spot. With a limit in place, you can move it to separate work at the next renewal.
How detailed does the run log have to be?
Only detailed enough to tell uses apart. When a job ran, which entry point it came through, and what kind of input arrived is enough. You do not need a line-by-line trace of the processing. Deciding what the record holds before delivery is the subject of a separate article.
Do I need to build monitoring to find unplanned uses?
Not at first. The Gumloop post describes an agent running every 30 minutes, but that company says its support team has two people and that support-related workflows run more than 500k times a week. Those are the company's own figures, not independently verified. At your scale, start by opening the record of a running system once a month.
Sources & editorial note
Primary pages read for this article. Publication dates below belong to the sources; access dates record our research.
- Genspark's Super Agent orchestrates 150+ tools with Claude
Anthropic · undated customer story page; no publication or update date shown
Accessed 2026-10-23 - Supporting the world's most AI-native companies with a 2-person team
Gumloop · 2026-02-17
Accessed 2026-10-23