A voice note can be a management brief.

If I have to tell an agent how to do the same job every time, I look for what’s missing from the system. If I tell it what I recommend for a particular guest, that’s a different kind of instruction.

Those two things get bundled together. A request begins with a human, so the workflow is judged to be insufficiently automated. I’m more interested in why the human had to speak. Were they repeating a procedure the system should already know, or contributing judgement the situation needed?

That distinction changes what I build. It also changes what I expect from a short voice note.

The procedure should be there already

I distinguish automated work from delegated work. Automated work can begin with stable triggers, current data, known rules and failure handling that has been tested. The system has enough to recognise the job and follow the agreed procedure within its permissions.

Delegated work begins with a live objective or a situational steer. After that brief, the agent uses established procedures, permitted tools and the relevant records to prepare the work. The brief does not have to contain the whole instruction manual.

If I keep explaining where to find the records or how to calculate a price, I should examine the procedure. That knowledge can be recorded and made available when the work needs it. Repeating it by voice is still repeating it.

A recommendation about what would suit these guests is different. I might judge that an apparently short ride needs a better route, or that a proposal should explain the delivery logistics before it gets into the price. Those are decisions about this situation. They belong with someone who understands the business and the experience.

Voice puts judgement into the work

I often give that direction by voice. It lets me contribute without first sitting down to reconstruct the correspondence and type a polished prompt. The useful input is what I know about the operation and what I recommend doing next.

The agent still has work to do afterwards. It retrieves the relevant records, reconciles the position and prepares the draft. The length of my voice note says how long I spent giving direction. It does not say how long the whole job took.

I then check the external commitment. Human judgement happens at both ends: a recommendation before preparation and an approval before sending. The first makes the work worth doing. The second checks that the result promises what we can actually deliver.

Dictation makes the contribution easier to capture. It doesn’t remove the need to decide which conditions matter, explain a commercial choice or check a promise. Speaking more fluently to a model is useful. Having the right records and procedures behind the conversation is what lets that instruction become useful work.

Keep the useful distinction

There is a tension here with the aim of an increasingly intelligent company. If a routine job depends on me remembering to ask for it, we may be missing a trigger. The manifesto’s ambition to retain and reuse knowledge gives us a reason to find that gap.

A deliberate management brief for a changing situation is a different case. I don’t want to remove it merely to make the workflow look more autonomous. More autonomy is valuable when it improves the operation within reliable boundaries. It is not a prize for needing the fewest human words.

Repeated delegated patterns can still become operating knowledge. I can capture a useful principle, refine the procedure and stop explaining the same part again. Some work may later be suitable for automation as its inputs and boundaries stabilise. Other work should continue to begin with a live recommendation.

The test I’d use in another business is simple: can this job run safely from known rules and current data, or does it need a brief from someone who understands what is happening? That answer tells me where to improve the system and where to make human direction easier. A voice note can be exactly the right place to start.