“Find us a place for the workshop” sounds like a clear request until two people try to carry it out. One may look for the cheapest room. Another may choose a room close to the train. Someone else may assume the workshop needs a screen, step-free access and a place to serve food.
Much of the work lies in deciding what a place means. A human colleague may know the group, remember last year’s problem or ask a well-timed question. Software may have some of that context. It may also fill the gaps with a plausible guess.
A job description makes the important choices visible. It need not be a large document. For a small task, a short paragraph may do. The purpose is to expose the decisions that would be expensive to discover after the agent acts.
Start with the result. In our hypothetical workshop, the result might be three available venues for twenty people, on a stated date, within a stated total room budget. Add the needs that could disqualify a choice: step-free entry, an accessible toilet, enough chairs and a location within the agreed area. State which details must be checked directly and which may remain uncertain.
Then name the boundary. The agent may search public pages and prepare a comparison. It may not contact anyone, create an account or reserve a room. If a venue hides its price behind an inquiry form, the right result is a flagged gap. Completing a table by inventing a price would make the document look better and the work worse.
That is already a more useful instruction. It names a deliverable, a test and a stopping point. The person has something to inspect other than whether the response sounds complete.
Decide what “done” means
A good completion test is tied to the purpose of the task. “Return a confident answer” is not a useful test. “Every price has a source, a date checked and a note about included fees” is closer.
Not every need can be settled by an automatic test. A page may say that a room is accessible without describing a narrow door or a steep path. A listing may be current but fail to reflect a private booking. The test should reveal this limit rather than conceal it. A candidate can be worth considering while its availability remains unconfirmed.
For the workshop comparison, a compact record could contain:
- The venue, address and source page
- The room’s stated capacity and relevant access details
- The quoted total, what it includes and what is unknown
- Whether the date is confirmed, shown on a calendar or still unverified
- The reason this option meets the stated needs, and any reason to rule it out
This is a proposed working format, not a standard proven best in an experiment. Its value is that another person can challenge the conclusion. If a room has no checked access information, the gap stays in view. A short list with one honest gap is more usable than a complete-looking list built on guesses.
Separate the main result from proof of the result. The agent’s statement that it checked a price is a claim. The dated source or a response from the venue is evidence. That evidence can still be wrong or stale, but it gives a reviewer somewhere to begin.
Also separate a plan from execution. A plan to check fees does not establish that the fees were checked. A plan to avoid personal data does not establish that no personal data was sent. The final record must describe what happened, including deviations from the plan.
Shipi Dhanorkar, Samir Passi and Mihaela Vorvoreanu interviewed 17 developers who used software agents. Their account describes oversight before, during and after a task. Some participants treated a good plan or passing tests as reassuring signs while doing limited live monitoring. These were interviews conducted in 2025, not a trial showing that those habits prevented errors. The useful finding for this book is that supervision includes preparatory and later work, much of which a simple “approve” button does not capture. 2026 interview study
Give uncertainty a proper place
A workflow that accepts only a success label can hide the difference between a checked result and an unresolved one. A better job description allows several honest endings.
The work may be complete. It may be partly complete, with the remaining gap clearly stated. It may require a decision from the person. It may be blocked because the next step exceeds permission. It may have an uncertain outcome because a tool stopped replying after receiving a request.
Those states call for different next steps. A missing room price might need a human inquiry. A lost reply after a deposit request needs a check of payment and booking records before anyone tries again. A failed search does not justify broadening access to a private mailbox.
Name the points that require a question. Ask when a choice would change cost, scope, data sharing or an important commitment. A harmless detail can often be resolved with an explicit assumption. An assumption about permission should not quietly become permission.
There is a cost to asking too much. If the agent returns every minor choice, the person is still doing the job in small pieces. The aim is to reserve questions for decisions that matter and to give the agent enough context to handle the rest. This balance should be tested in the real task. It will not be the same for sorting a reading list and sending invoices.
For recurring work, keep the agreed assumptions with the job. “Use the community hall’s mailing address” may be stable. “The event starts at six” may belong to one date only. A useful record makes that difference clear, so a temporary instruction does not become an unnoticed standing rule.
Test the boundary as well as the output
Before widening a job, try a small version whose outcome is easy to inspect. For venue research, use one known venue. Check whether the agent returns the right room, follows the date requirement and marks missing information instead of guessing.
Then try a case that should cause it to stop. What happens when the room is above budget? What happens when a page says to email a contact, but the task allows research only? Does the system report the limit, or treat an obstacle as a reason to exceed it?
These are proposed acceptance checks. They are not a claim that a few examples can certify safety. Their purpose is to catch obvious mismatches before a larger task. A passed check says something about the case tested. It does not prove every future case will pass.
A score depends on the test. A check of the final database may miss a misleading message. A check of the final answer may miss an unwanted side effect. Test what matters, and keep the steps clear enough for someone else to repeat.
Ask a simple question of each test: could the agent pass this while still failing the real job? If the answer is yes, decide whether to improve the test or keep a separate review. Do not turn the mere existence of a test into an assurance.
This is also why a task needs an owner. Someone must decide which tradeoffs are acceptable. An agent can compare cost and distance. It cannot discover the group’s values by counting search results. The organizer may prefer a more expensive room because a member cannot climb stairs. That is a decision about whose participation matters, not a defect for the model to optimize away.
Responsibility needs actual control
Philosophers Filippo Santoni de Sio and Jeroen van den Hoven describe meaningful human control through two ideas. A system should respond to relevant human reasons, and its operation should be connected to people who understand its capacities and their responsibilities. Their account is a philosophical proposal, not an experiment. It helps clarify why the presence of a person at the end of a process is too thin a definition of control. Philosophical account
For our workshop, the person needs to know whether the agent is merely searching or may make a commitment. They need to see the relevant evidence and have a real chance to refuse. If those conditions are absent, calling them the manager does not repair the arrangement.
There is a provider’s job here, too. A consumer should not have to design an entire access-control system to ask for a room comparison. Products should offer clear modes, visible limits and reliable records. A workplace should make it clear who owns a recurring task and who can change its authority. The job description is a way to express those needs; it does not excuse a tool that cannot honor them.
A well-defined task leaves less room for hidden disagreement. It also gives the agent room to work. Once the result and boundaries are clear, the person can stop directing every small step and pay attention where judgment is needed.