How to delegate tasks to an AI agent

To delegate tasks to an AI agent, give it a defined outcome, enough context to make sensible decisions, a spending limit and clear boundaries on what it can do without asking you. Decide which actions require your approval before work begins. Then review those actions as they arise, rather than waiting until the agent delivers its finished work.

This is different from handing a task to a colleague. A colleague can notice that your instructions are missing something, ask what happened in last Tuesday's meeting or recognise that an unusual request needs a phone call. An agent works with the context and permissions it has been given. If you leave out the reason behind a decision, it may follow the written instructions while missing the point. Good delegation starts by putting the missing conversation into the brief.

Choose a task with a visible finish line

Start with work you can describe and inspect. Preparing a competitor research document is easier to delegate than asking an agent to improve your market position. Sorting support requests into proposed categories is easier to inspect than giving an agent responsibility for customer happiness.

The difference is the finish line. You should know what you expect to receive and how you will decide whether it is usable. If you cannot describe the finished work, the agent has to invent its own definition of success.

Take a founder preparing for a supplier negotiation. The founder needs a comparison of three suppliers before Friday. The useful output is a short document containing current prices, contract conditions, unresolved questions and a recommendation for what to ask each supplier. It is not an instruction to negotiate on the founder's behalf.

That distinction gives the agent room to do the research while keeping the commercial decision with the person responsible for it.

Look for tasks with a clear input, a deliverable you can check and a natural place for a person to make the next decision. Once you can describe those elements, you have something suitable to hand over.

Write down the context a colleague would ask for

Most instructions describe the work but leave out the circumstances. A manager says, "Prepare a supplier comparison," because the manager already knows which supplier failed last month, why the cheapest quote was rejected and who will read the comparison.

An agent does not inherit that conversation. It needs the relevant parts written down.

Before sending a brief, imagine a capable new colleague reading it on their first morning. What would they have to ask before starting? Those questions belong in the instructions.

For the supplier comparison, a usable brief would identify the three suppliers, explain the purpose of the negotiation, include the previous quote and state that delivery reliability matters more than the lowest headline price. It would say where to find the source documents, how recent the information must be and who will use the result.

It should also describe the deliverable. Ask for a two-page comparison with a separate section for information that could not be verified. Tell the agent to preserve the original figures and distinguish a supplier's stated terms from its own interpretation.

There is another useful instruction: what to do when something is missing. For example, "If a contract term cannot be found in the provided documents, mark it as unknown. Do not fill the gap with a standard industry assumption."

This saves you from reviewing a polished document whose most important conclusion rests on something nobody established.

Put a number on the resources the agent can use

A colleague might understand that a small research request does not justify buying an expensive subscription. An agent needs a stated limit. Give each delegation a budget before it starts, rather than leaving expenditure as an open question.

The budget should fit the task. For a routine comparison using material already available, the sensible limit may be small. For work that requires several research passes or paid tools, decide what the additional work is worth before authorising it.

In Delagents, each delegation has a brief, budget and result, with a hard budget cap. That makes the resource limit part of the assignment itself, rather than a spending guideline somebody has to remember later.

A cap is useful even when the work has no obvious external purchase. Research can expand indefinitely. A question leads to another source, which suggests another comparison, which opens three more questions. More activity does not automatically produce a more useful answer.

Set a stopping rule alongside the budget. Ask for the strongest available evidence within the authorised scope and require the agent to report gaps it cannot resolve. If the work needs a larger budget, that becomes a new decision for you.

Decide which actions belong to you

Research and preparation happen inside the assignment. Sending the supplier an email changes something outside it. The same distinction applies to publishing a document, issuing a refund or editing a shared record.

Write the boundary before work begins. An agent preparing the supplier comparison can read the authorised materials, organise findings and draft questions. It should not send those questions to suppliers merely because contacting them would resolve an uncertainty.

Think about the approval as a decision over an exact proposed action. You are not approving the vague idea of supplier outreach. You are approving a particular message, to a particular recipient, with particular contents.

For example, the agent might propose sending an email asking Supplier B to confirm a delivery date. At that point, you need to see the recipient and message. You might approve it, change the wording or reject it because negotiations are already happening through another contact.

The timing matters. If you discover the email after it has been sent, your review is an audit. You cannot take back the recipient's first impression.

In the Delagents approvals inbox, actions that affect the world outside the workspace wait as cards showing the exact proposed action, the cost so far and a deadline. A person can approve, change or reject them. Certain actions always require a person, including first contact outside the workspace, moving money, publishing publicly and deleting or overwriting records the agent did not create.

Your brief should still explain the boundaries particular to the task. A system-level approval requirement does not tell an agent that one supplier is under confidential negotiation or that an internal spreadsheet is still being reconciled. Those are business judgements you must supply.

Review the proposed action, not the entire task again

Delegation becomes frustrating when every checkpoint turns into another full review of the assignment. The point of an approval is narrower. You need to decide whether the specific action should happen now, in its proposed form, given what you know.

A practical approval check takes four questions:

1. Is this the correct action? Check the recipient, record, amount or destination rather than relying on the agent's description of its intent.
2. Is the underlying information sound? Inspect the evidence that matters to this decision, particularly figures, commitments and details supplied by outside parties.
3. Is the timing right? An otherwise suitable message may be premature if a colleague is still reviewing the terms.
4. Has the work stayed within the agreed scope and budget? If the agent needs to change the assignment, decide that separately.

You do not need to repeat the agent's entire research process to approve one email. You do need enough evidence to accept responsibility for sending it.

If the proposed action is wrong, change or reject it. Then look at why the agent proposed it. Sometimes the brief contains an ambiguity that will produce the same mistake at the next checkpoint. Correcting that instruction is better than repeatedly fixing individual drafts.

There will also be occasions when a request for approval exposes a decision you had not realised you needed to make. Perhaps the agent has found conflicting contract dates, and there is no responsible way to continue without asking which document governs. That interruption is useful. It moves the unresolved judgement back to the person who owns it.

Inspect the result and use it to write the next brief

When the agent finishes, check the deliverable against the original assignment. Did it answer the question? Can you trace important claims to their supporting material? Are unknowns visible? Did it stay within the requested format and scope?

Keep the review separate from the decision to act on the result. A well-prepared supplier comparison can still lead you to postpone negotiations. The document is useful if it gives you a clear basis for that decision, even when the next business action is to do nothing.

Look at the work history when something seems off. Which tool calls were made? What was approved? Did the scope change along the way? An activity log gives you a way to inspect the sequence rather than reconstructing it from the finished document.

Then revise the brief. If you spent time correcting how the agent treated old pricing, add an instruction about source dates. If the deliverable was too long to use in a meeting, set a page limit next time. If the agent repeatedly sought approval for the same kind of action, decide whether the task description needs a clearer boundary.

Start with one task already sitting on your desk. Write its intended result in one sentence, add the context a new colleague would need, set a hard budget and identify the first action that must come back to you for approval. Do not begin with your whole department's workflow. Begin with the next assignment you can describe clearly enough to check.