Every founder has a list of small administrative jobs that eat a day a week and produce nothing. Sending a signed form to a county office. Chasing a document from a supplier who will not use email. Filing the same notice to the same registry every quarter.
These are the obvious candidates for automation, and they are also where automation quietly goes wrong. The task is cheap, the failure is expensive, and nobody notices for a month.
So the useful question is not which jobs an agent could do. It is which jobs leave behind enough evidence to know whether it did them.
The receipt test
Here is a test you can apply to any task on that list, without knowing anything about how the software works.
If the job is done correctly, what artefact exists afterwards that a stranger could check?
A good artefact names the thing that was sent, where it went, what it cost and what the recipient’s system said about it. A bad one says the attempt was made. The gap between those two sentences is where most automation disappointment lives.
Apply it and the list sorts itself quickly. Paying an invoice through your bank produces a statement line and a reference, so it passes. Posting to a social account produces a public URL, so it passes. Sending a document to an organisation that only accepts fax used to fail, because the evidence stopped at your own outbox.
That one has changed. Fax for Agents is an example of the shape the test asks for. Every job ends with a record carrying the document’s sha256, the destination, the amount captured, the provider’s reference and the outcome. The word delivered is written only when the provider’s evidence for that attempt supports it.
Why per-unit pricing matters more than the total
There is a second, duller reason these jobs are worth moving, and it shows up in the plan before it shows up in operations.
A task done by a person has a cost you can only estimate. Twenty minutes, sometimes an hour, sometimes a morning when the line is engaged. You cannot put that in a model with any confidence, so it tends not to appear in one at all.
A task done through a metered service has a price per unit. Sending a page costs $0.039 in the United States and Canada and receiving one costs $0.019. A number costs $2 a month, as of 28 October 2026. Whether those are the right numbers for you is beside the point. The point is that they are numbers, so the line item becomes forecastable instead of anecdotal.
That is a real planning gain and it is routinely undervalued. A cost you can multiply is a cost you can decide about.
What has to stay with a person
The test cuts the other way too, and this is the part worth being strict about.
Anything irreversible needs a person to approve that specific action, not the general category. Approving “send documents to the registry” is not a decision, it is a shrug. Approving this document, to this number, for this amount, is a decision.
That distinction can be built in, so nobody has to remember it. In the service above an approval covers one document hash, one destination, one sender, one amount and an expiry. Any change to the document invalidates it. Swap a page after approval and the send fails, so nothing goes out quietly. A price behaves the same way: a quote binds the document, the destination and the amount for ten minutes.
The other thing that stays with a person is the budget, and specifically where the budget is written down. If the limit lives in an instruction to the software, it is a preference. If it is checked by the system performing the action, against a policy the software cannot edit, it is a limit. Those two arrangements look identical on a good day.
How to try one without committing to anything
Pick the smallest job on your list, the one that annoys you most and matters least.
Write down what the receipt should contain before you automate anything. If you cannot describe it, the job is not ready. Better to learn that in an afternoon than in a quarter.
Then run it in a sandbox where no money moves. Rehearse the failures: the busy signal, the wrong number, the case where the service does not know yet. A process that only works when everything works is not a process.
What you learn from that one job transfers to all of them. The receipt test is not really about faxes, or about agents. It is about whether delegating a task leaves you able to answer the question of whether it was done.
