heurema
A support agent answers from an outdated policy. A sales agent follows up after the deal has moved. An internal tool updates a field that no one owns anymore. The model becomes the first suspect because it produced the visible mistake.
An agent can follow the instruction while the work still fails.
The missing part often sits around the model. The current rule lives in one document while the exception lives in a manager's memory. Two systems disagree about status. Nobody owns the final decision. A task can be marked complete without checking the business result.
Changing the prompt does not repair those gaps. A stronger model may simply reach the same bad action faster.
Reconstruct the current work
Before discussing automation, I try to answer five questions.
- What enters the process?
- Who owns the result?
- Which source wins when systems disagree?
- Where do exceptions go?
- What proves that the work is actually complete?
The answers usually reveal where the intervention belongs. Sometimes ownership is missing. Sometimes a field or policy is stale. Sometimes a handoff exists only in conversation. Those are process defects with a software symptom.
Keep several outcomes open
A useful review does not need to end with an agent.
The process may be cheaper to leave alone. A new rule, owner, or CRM configuration may remove most of the delay. A small integration may solve the real break without introducing another autonomous actor. Automation becomes reasonable when the remaining task repeats, has a clear source, stays inside a boundary, and produces a result someone can accept.
Write the boundary before the build
When implementation is justified, the task needs a short working contract.
- expected result and owner
- allowed systems and actions
- required checks
- human decision points
- stop and rollback conditions
- evidence returned at handoff
This contract makes the work reviewable whether it is performed by a person, a script, or an AI agent. It also gives the workshop a clean place to stop when the facts do not support the requested automation.
The first deliverable is often the decision. Code follows when the decision survives inspection.