Before we build the agent, who can cancel the report?
Matías Bonvin· Updated
Pick the report your team most dislikes preparing.
Who can say that next Friday, it will no longer be required?
You may know immediately. You may also discover that several people can ask for it, while nobody is quite sure who can stop it.
That is worth finding out before commissioning the agent.
Consider a fictional manufacturer. Every Thursday, a purchasing coordinator prepares the weekly supplier status. The underlying information becomes a spreadsheet for operations, a presentation for the management meeting and a separate extract for finance.
The coordinator checks delivery dates, copies comments and adjusts the colours that make sense to each audience. Everyone gets their preferred version.
It is reasonable to ask whether a machine could do the copying.
I would also ask what the three recipients actually decide with those versions. The answer could remove a piece of work from Thursday permanently. Or establish why it must stay.
Either outcome is useful before you pay someone to automate it.
Ask for the last decision
“Do you still need this report?” is easy to answer. Yes. Better keep it.
Ask the requester to show the last decision it helped them make.
The operations manager might point to a delayed component and the decision to change the production sequence. That gives you something concrete to preserve: the component, the expected date and when someone must act.
Finance might explain that its extract supports a control at month-end. Now you have a different purpose and a different deadline. The responsible person needs to establish what record and evidence the control requires.
The presentation for the management meeting may turn out to repeat the operations spreadsheet, with fewer rows and more formatting. Or it may expose a risk that nobody can see in the spreadsheet. You need to look.
A file with no obvious operational reader can still be required by a contract or a retention obligation. Keep the required evidence. An employee saying “nobody reads it” does not authorise its deletion.
The point of this conversation is to reach an explicit decision about the deliverable. What remains required, in which form, for whom, and when?
Until that is settled, the coordinator has every reason to keep making all three versions.
The person doing the work cannot always retire it
Imagine asking that coordinator to challenge every report request personally.
They would have to tell a manager that a document was unnecessary, defend the decision in another department and take the blame if someone later needed it. Continuing to copy the cells is the safer working day.
You can have capable employees and still put them in that position.
An improvement project needs someone authorised to change the requirement. That person could be a department head with the right scope. When the report crosses departments, the decision needs the relevant owners in the room. Technical purchasing authority alone may not cover it.
The engineer can make a button disappear. Whether the business will accept the missing output is another matter.
For the manufacturer, a useful decision might be to retire the management presentation from a specified date. The meeting would use the agreed operations view, provided it contains the information needed for those decisions. Finance would retain its required record on its own timetable.
The coordinator needs to receive that decision explicitly. So do the meeting organiser and anyone still requesting the old attachment.
Otherwise, one “Could you send the usual slides?” brings the whole routine back.
Give the remaining work a fair test
There may still be plenty worth automating.
The supplier updates could be buried in emails. People may spend time matching them to purchase orders. A clear rule might handle a simple date comparison; an AI system might help interpret a written explanation. Conflicting evidence needs a defined route to someone who can resolve it.
Those are different jobs. They deserve a design that fits the work left after the requirement has been agreed.
You can start with this one report without redesigning the whole company. Follow its dependencies far enough to know who consumes it and which controls it supports. Keep the scope there unless the evidence shows that the change cannot work within it.
And sometimes the report is already well designed. Everyone uses it. The fields are right. Preparing it is slow because the data sits in separate systems that should exchange it.
Then fix the connection. There is no need to manufacture a management problem to justify consulting work. A reliable integration may be sufficient. If the task requires interpretation, test the proposed AI against representative cases, including the ones that should be escalated.
I want the owner to be able to see precisely what the investment buys, down to the work that ends and the decisions a person still has to make. The system's part should be just as clear.
That makes it easier to approve a useful change without wondering whether you're buying another permanent obligation.
Put the evidence where the decision happens
Suppose the remaining requirement is to warn the planner about a delivery that could stop production. A weekly summary may arrive after the last useful moment to act.
Start with one affected order. Show the supplier's latest commitment beside the required date. Link the original message. If two sources disagree, keep that disagreement visible. Give the planner the permitted next action and a way to record what was decided. The agent can prepare the case; it does not acquire permission to change the production plan merely because it found a problem.
This is a different deliverable from another page of commentary. You can test it on past cases: would the right person have received enough reliable information while an alternative was still available? Then try it on a bounded live scope with human review. Count false alarms too. A system that sends every uncertainty to the planner can consume the afternoon it was supposed to release.
The details belong to this business. One supplier's confirmation may be authoritative; another may require a portal check. Record that rule with its owner and the source supporting it. When the policy changes, update the rule and test affected cases. Otherwise yesterday's workaround can become tomorrow's automated instruction.
If a second site wants the same capability, reuse the useful parts. Reconfirm who may see which supplier data and who can authorise a change there. Shared software can reduce the next implementation's effort while local responsibilities remain different.
Check the Thursday after the change
A successful technical test proves the system produced the expected output. Check the working day as well.
Has the coordinator stopped making the retired presentation? Sit through the management meeting and check whether the retained information supports its decisions. Finance should also confirm that its required evidence is still available.
If someone rebuilt the old version privately, find out why. A genuine need may have been missed. Perhaps the replacement is difficult to use. Or the requester never received the decision. Each cause calls for a different response.
This is how an owner can get a Thursday back without asking employees to refuse their managers. A requirement changes, the people affected agree how they will work, and the remaining information still arrives where it is needed.
The coordinator can spend that afternoon following up the supplier whose delay could hurt next week's production. You can discuss the production decision with current information, without buying a machine to keep an unused presentation alive.
For an industrial group or B2B distributor, select one report that takes too long to assemble. Find the person who can change its requirements. Those are useful starting points for deciding whether a scoped assessment is warranted.