Disclosure: This article was generated with AI and reviewed against the source transcript.
A shop owner wants help preparing the weekly stock review. Most items follow a familiar pattern. A few involve damaged deliveries, changing suppliers, or a customer order that has not been recorded correctly.
The ordinary cases make the job look easy to automate. The exceptions reveal what the first version should be allowed to do.
In his explanation of AI agents, Salim Ismail focuses on systems that take successive steps toward a job, rather than only producing a reply. He recommends beginning with a bounded, observable task. His personal examples and claims about savings are source accounts, rather than a measured result for this shop.
My application is to choose the initial job by examining its exceptions before deciding how much execution to delegate.
List the cases that require judgment
For the hypothetical stock review, the owner might distinguish routine replenishment candidates from records needing attention. A missing supplier price, an unexplained stock adjustment, and an unresolved delivery discrepancy would each enter the exception list.
That list helps define a useful first output: a proposed review sheet with routine candidates and an explicitly separate queue of unresolved items. It does not need to place orders to be useful.
Write down how the owner currently resolves each exception. If the answer depends on a conversation, a private agreement, or information outside the available system, the automation should not infer that missing knowledge from a plausible pattern.
The job becomes better specified when its normal stopping points are visible.
Give each exception a destination
A system that merely refuses an unfamiliar case can leave the owner with another pile of work to investigate. A better handoff identifies the relevant record, the missing fact, and the next person or source needed to resolve it.
For a delivery discrepancy, the sheet could link the purchase record and the received quantity, then state that their difference needs review. It should preserve the original observations rather than rewriting them to agree.
This is an illustrative design. The actual fields depend on the shop’s available records and permissions. If the necessary data is unavailable, that should appear as a limitation of the output.
The destination matters as much as the classification. Someone needs to know where unresolved work will appear and when it should be examined.
Test the handoff before expanding the action
Start by comparing the proposed sheet with the owner’s ordinary review on authorized records. Check both directions: routine items incorrectly flagged as exceptions, and exceptional items incorrectly treated as routine.
Do not judge the process only by how many rows it completes. A high completion count could conceal the cases that deserved more attention.
Record the time needed to review the sheet and resolve its errors. Keep examples of confusing outputs, including cases where the owner had to open several systems to understand a short explanation.
Those observations can inform whether the next version needs better data, clearer wording, a different boundary, or a different task entirely. They do not automatically justify giving the system authority to order stock.
Match autonomy to observed reliability
The word “agent” does not specify which actions have been delegated. A system might prepare a recommendation, update an internal field, or initiate an external transaction. Each changes the responsibility being handed over.
Document the actual boundary in terms of the shop’s work. State which records can be read, which outputs can be written, and which conditions require returning an unresolved case.
If the owner later authorizes a wider action, preserve the same record identity and result checks. The system should still show what it did and what remains uncertain.
The proposed stock-review workflow has not been tested here. It illustrates a practical way to evaluate a first job: examine the exception queue, the quality of its handoff, and the effort required to supervise it.
Pick the recurring task whose awkward cases you can describe clearly. Then define a useful output that remains useful when some of those cases cannot be resolved automatically.