A travel agent recommends a steakhouse to someone whose profile says they are vegan. The software is running. The tools respond. The answer still fails the person.
Google uses that kind of example to introduce its new agent-quality system. It is a useful place to begin this week, because it gets past the impressive demo and into the much less glamorous question of whether the work was any good. [1]
Three stories deserve a longer conversation together: Oracle giving AI a specific recruiting assignment, LegalOn deciding how much intelligence each task is worth, and Google building a way to investigate work after it goes wrong.
Read together, they suggest a practical way to think about delegation. You need to know which decision the work serves, what the system needs to do it, and how you will recognize an acceptable result. A better model does not answer those questions for you.
01 / THE ASSIGNMENT
A job with a purpose.
In a case study published by OpenAI, Oracle describes a recruiting tool that starts with a job description, researches comparable roles, benchmarks compensation, and examines the talent pool. Oracle says preparation that previously took two to four days now takes about fifteen to twenty minutes. This is a vendor-published customer account, not an independent audit. [2]
The useful detail is the shape of the assignment. A recruiter is preparing for a conversation with a hiring manager. Research has a recipient and a purpose. There is a moment when somebody can decide whether it helped.
That makes this a better starting point than “use AI in recruiting.” You can inspect the evidence, challenge a comparison, and ask whether the hiring conversation improved. You can also discover that faster preparation leaves the actual bottleneck untouched.
For someone figuring out where AI fits into their own work, that is an approachable place to start. Choose a recurring decision. Work backward to the information and preparation it needs. Then decide which parts are worth delegating.
02 / THE BUDGET
Spend against the task.
LegalOn adds a second piece. Its account describes choosing models according to task complexity, restricting expensive fast-mode use, and setting budgets that reflect whether a business is mature or growing. It reports an approximately 65% reduction in estimated daily costs while maintaining development speed. Those are the company’s reported results. [3]
More revealing is the unfinished work: LegalOn is building a measure that connects the cost of a feature release to customer value. Faster development has not, by itself, settled that question.
Apply that to the recruiting brief. A first pass through public information might justify a small budget. A difficult comparison might deserve more capable reasoning. A person still has to check that the evidence supports the conclusion. Those are different kinds of work, even if they happen inside one interface.
Cheap output can become expensive if somebody has to rebuild it. An expensive run can be worthwhile if it resolves an important uncertainty. The comparison needs to include checking, correction, and the quality of the final decision.
This also makes room for a less comfortable answer: some recurring reports may not deserve to be produced at all. Before spending time making one faster, ask who uses it and what they do differently because it exists.
03 / THE REVIEW
Someone still has to check the work.
A clear assignment and a sensible budget get you started. They do not tell you whether a system remains useful after people begin relying on it.
Google’s AQuA samples live agent sessions, reviews failures, groups recurring problems, and helps diagnose their causes against the deployed code. It operates outside the live request path and does not apply fixes itself. [1]
That distinction matters. Finding a problem creates another piece of work: deciding what caused it, who should fix it, and whether the change helped. An automated reviewer can prepare the evidence. Responsibility still needs an owner.
Imagine the recruiting brief starts using stale compensation information. This is an illustrative scenario, not an incident from the Oracle account. The document might remain polished and arrive on time. A check focused only on completion would miss the reason the brief exists.
A useful review would ask where the figures came from, whether the comparisons are relevant, and what the recruiter had to correct. If the same issue keeps returning, someone needs to change the workflow rather than repair each document forever.
What these examples don’t establish
They do not prove that every AI workflow is economical or reliable. Two are vendor-published customer stories; the third is an engineering release. They give us concrete approaches to test. The results still have to hold up in the work we choose.
04 / PUT IT INTO PRACTICE
Write the assignment before the prompt.
Pick one recurring piece of work this week. Give yourself fifteen minutes to fill in the brief below. If you cannot name the decision it supports, pause there. More detailed instructions will not make an unnecessary task useful.
Then run a small trial. Compare the complete effort, including your review and corrections, with the way you handle it today. Keep a note of what improved and what you still would not trust.
One job. A clear definition of done.
Build: An AI job brief and a small-trial scorecard for one recurring decision.
Look for: The recipient gets a better basis for the decision, after accounting for preparation, review, corrections, and cost.
Bring the result back to the original decision. Did the person who needed the work get something better? That is the question to carry into the next run.