Delegating to AI: What to Hand Off and What to Keep

Delegation used to be a manager's skill. Now anyone with an AI assistant or a coding agent delegates dozens of times a day, usually without thinking about it. Some of those handoffs save an afternoon. Others produce something that looks finished, takes an hour to check and then gets redone by hand.

The difference is rarely the model. It is which task was handed off, and how. This post gives a simple matrix for the first question and a handoff template for the second.

Why is delegation the core skill of AI-first work?

Because the work that reaches AI is increasingly whole tasks rather than single questions, and someone has to decide which tasks and how they are described. Anthropic's September 2025 Economic Index report found that 77% of API transcripts showed automation patterns, against 12% showing augmentation. When businesses build AI into their systems, they mostly hand work over rather than collaborate on it step by step.

Microsoft's 2025 Work Trend Index describes the person this creates as an "agent boss": someone who "builds, delegates to, and manages agents to amplify their impact." The report quotes a Microsoft researcher on what that feels like: working with agents "is like onboarding a new team member": you don't micromanage, "but you need informed trust."

Informed trust is the useful phrase. You cannot get it from enthusiasm or from suspicion. You get it from knowing which tasks the AI does well, which ones you can check cheaply, and which ones should never leave your hands.

The delegation matrix: risk against repeatability

The matrix has two axes. Risk asks what happens if the output is wrong and nobody notices. Repeatability asks whether you will do this task once or many times. Together they put any task in one of four quadrants, each with a different way of working.

Two things make this more than a sorting exercise. First, risk is about consequences, not difficulty: an easy task can be high risk if a wrong answer reaches a customer. Second, repetition is what pays for checks. Writing a test or an approval step for a task you do once is rarely worth it; for a task you do every week, it is the whole game.

How do you judge the risk of a task?

Ask four questions, and if any answer is bad, treat the task as high risk.

• Can it be undone? A draft can be deleted; a sent email, a dropped table or a payment cannot.
• Who sees it? Output that stays with you is lower risk than output that reaches a client, a customer or production.
• Can it be checked cheaply? If a test, a diff or a two-minute read confirms it, risk drops. If checking takes as long as doing, it does not.
• Is it inside what AI does well? The research I covered in what the top 1% of AI users do differently shows AI helping on tasks inside its "jagged frontier" and hurting on tasks outside it. On the task outside the frontier, Harvard's write-up of the study reports consultants using AI got up to 24 percentage points fewer correct answers than those without it.

The last question matters most and is hardest to answer in advance. On client projects I find the honest answer often comes from one trial run: delegate a small version of the task, check it carefully, and let that result decide the quadrant.

Researchers are building the same map at the scale of whole occupations. The study Future of Work with AI Agents collected preferences from 1,500 workers on more than 844 tasks across 104 occupations, and sorted tasks into four zones by weighing what workers want automated against what AI can actually do: a green light zone, a red light zone, an R&D opportunity zone and a low priority zone. Your personal matrix is a small version of the same exercise.

What should you keep for yourself?

Keep the decisions you are accountable for, and the work where your judgement is the product. That usually means:

• Choices with long tails. Architecture, data models, vendor selection and pricing are cheap to get AI input on and expensive to get wrong.
• Anything said in your name. Client emails, proposals and commitments can be drafted by AI, but the final words and the promise are yours.
• Security and permission decisions. Which system an agent may touch, which keys it holds, what it may delete.
• Deciding what done means. The definition of done is the one part of a delegated task the AI cannot write for you, because it encodes what you actually want.

Keeping a task does not mean doing it without AI. In the keep quadrant, I still use a model to research options, list trade-offs and attack my reasoning. The difference is that the decision and the final output stay with me.

How do you write a handoff the AI can't misread?

Write it like a ticket for a capable contractor who has never seen your project and cannot ask questions halfway through. Most failed delegations I see are not bad models; they are handoffs where the important constraint lived only in someone's head. My handoff has eight parts:

• Goal: one sentence on the outcome, not the activity. "Customers can export invoices as CSV" rather than "add an export button".
• Context: where the relevant files, documents or data are, and anything unusual about them.
• Inputs: the exact material to work from, attached or linked.
• Constraints: conventions, libraries, tone or formats to follow.
• Out of scope: what not to touch. This line prevents more damage than any other.
• Done means: the observable result that counts as finished.
• Check: how the AI should verify its own work before returning it, and what evidence to include.
• Stop and ask: the situations where it should pause and come back rather than guess, such as a missing permission or two conflicting requirements.

For code, the longer version of this is a spec, which I covered in spec-driven development. For a twenty-minute task, the eight lines above are enough, and most take one short sentence each.

The handoff also sets up the review. When the AI returns work against a stated goal, done condition and check, reviewing it means comparing the result to those three lines. The triage I use for that is in how I review AI-written code, and it applies to non-code work with little change.

How do tasks move between quadrants over time?

The matrix is not fixed, and moving tasks across it is where most of the long-term gain is. A high-risk task you do often starts in the keep quadrant. Once you add a check that catches the failures you care about, such as a test suite, a dry run, a reconciliation or a human approval step, it moves to delegate with checks. When the check has held for long enough and the stakes are understood, parts of it can move to automate.

This is also how I approach automation work for clients. The first conversation is rarely "what can AI do?" It is "which of your repeated tasks are low risk today, and which could be made low risk with a check?" The answers to the second question are usually where the real value is, and my AI automation audit is the structured version of that conversation.

Movement goes the other way too. If an automated task starts producing errors, or its stakes rise because it now reaches customers, it moves back up the risk axis and gets a check or a human again. Running several agents at once, as in running parallel AI agents on one codebase, only works when each task in flight has been placed honestly first.

Work with me

I help teams decide which of their repeated tasks to hand to AI, then build the automations and agents with the checks that make that safe. See workflow automation and AI agent development, or browse my work and book a scoping call.