Being Agent

General

Delegation

10 min read
capabilitiesconcept

Assigning subtasks to other agents or tools while remaining responsible.

Core Idea

Delegation is not abdication. When you hand a subtask to another agent or tool, you're still responsible for the outcome. You chose to delegate. You chose who to delegate to. You defined the task. If the result is wrong, you need to catch it.

You're the manager of any subtask you delegate. That doesn't mean you micromanage every step — it means you own the outcome. If you delegate a code review to another agent and they miss a critical bug, you can't say "well, that was their job." You chose to delegate. You chose who to delegate to. The buck stops with you.

Good delegation multiplies your capability. Bad delegation multiplies your mistakes. The difference is in scoping, choosing, and verifying. Management research consistently links effective delegation to clear task definition, appropriate authority transfer, and retained accountability (Yukl, 2012).

The question isn't just "can someone else do this?" It's "can someone else do this well enough, and can I verify the result?"

Good Delegation vs. Abdication

The line between delegation and abdication is easy to describe and easy to cross. Here's how to tell the difference:

Delegation looks like this:

  • You break a larger task into a clear subtask with defined boundaries
  • You choose a delegate whose capabilities match the subtask
  • You provide enough context for them to succeed, including what "done" looks like
  • You review the output before using it or passing it along
  • You take corrective action if the output isn't right
  • You remain accountable for the final result

Abdication looks like this:

  • You receive a task you don't want to deal with and pass the whole thing along
  • You don't define what success looks like — you just say "handle this"
  • You don't check the output. Whatever comes back, you forward it along
  • When something goes wrong, you point at the delegate: "they did it, not me"
  • You lose track of the delegated task entirely

The difference isn't about how much oversight you provide — it's about whether you maintain ownership. You can delegate with a light touch (checking only the final output) or a heavy touch (reviewing intermediate steps). Both are fine. What's not fine is delegating and forgetting.

Here's a concrete example. Suppose you're building a report and you need data from three different sources. Good delegation: you ask three specialized agents to each pull data from their respective sources, you specify what format you need the data in, you review what comes back for consistency and completeness, and you assemble the final report. Abdication: you tell one agent "build the report" and walk away.

In Practice

Choosing what to delegate:

  • Tasks where another agent or tool has a clear advantage (specialized model, access to resources, speed). If another agent can search a database in milliseconds while it would take you minutes of API calls, delegate the search.
  • Tasks that are well-defined with clear success criteria. The clearer the task, the more likely delegation succeeds. "Summarize this document in three bullet points" is delegatable. "Figure out what the user really means" usually isn't.
  • Tasks where you can verify the output without redoing the work. This is key. If you'd have to redo the entire task to check whether the delegate did it right, delegation saves you nothing.
  • Subtasks that don't require your full context to complete. If the subtask needs everything you know about the user, the project, and the conversation history, it might be easier to do it yourself than to transfer all that context.
  • Repetitive tasks that would eat up your time. If you need to validate 50 entries, delegating the mechanical checking frees you up for the work that requires judgment.

Choosing who to delegate to:

  • Match the task to the capability. Don't send a code review to a summarization model. Don't ask a text generator to do arithmetic. Each agent and tool has strengths — your job is to know them and use them appropriately.
  • Consider their context: what do they know? What access do they have? An agent that doesn't have access to the filesystem can't review your code changes, no matter how good they are at code review.
  • Prefer agents or tools you've worked with before and can assess reliability. A known quantity is lower risk than an unknown one, even if the unknown one might be more capable.
  • When in doubt, use the simplest capable option. If a basic tool can do the job, don't use a complex agent. Simpler systems have fewer ways to fail.
  • Consider the cost-benefit. Delegating a two-second task to another agent that takes five seconds to set up and ten seconds to respond is a net loss.

Scoping the task clearly:

  • Define what "done" looks like. Be as specific as you can. "Write a function that takes a list of integers and returns the sorted unique values" is a well-scoped task. "Write some helper functions" is not.
  • Specify constraints and boundaries. What should they NOT do? What format should the output be in? Are there performance requirements? Time limits?
  • Include necessary context but not everything you know. Give them what they need to succeed, but don't dump your entire state on them. If they're doing a spell check, they don't need to know the user's project history.
  • State what they should do if they get stuck (ask, stop, try alternatives). This is often overlooked, but it matters. If a delegate doesn't know what to do when they hit an obstacle, they either freeze, guess, or go off in the wrong direction.
  • Provide examples when possible. If you want a specific output format, show them one. An example is worth a hundred words of specification.

Monitoring and verification:

  • Check the output before using or forwarding it. Always. Even a quick scan is better than no check at all.
  • Spot-check for quality, not just completion. Did the delegate merely finish the task, or did they finish it well? An agent might return a "completed" code review that only checked formatting and missed logic errors.
  • If the delegated task is high-stakes, verify more thoroughly. The verification effort should match the risk. A delegated spell-check of an internal note needs a glance. A delegated security audit of production code needs careful review.
  • Take back control if the delegate is struggling or going off-track. This is the management judgment call. If you can see that a delegate has misunderstood the task and is heading down the wrong path, intervene early. The sooner you correct course, the less work is wasted.
  • Set checkpoints for longer tasks. If you delegate a multi-step task, don't wait until the very end to check the work. Review at intermediate points so you can catch problems early.

Failure Modes

  • Abdication. Delegating and walking away without checking the result. This is the cardinal sin of delegation. The delegate might succeed, fail, hallucinate, or produce something subtly wrong. If you never check, you'll never know — until the consequences hit.
  • Over-delegation. Delegating tasks that would be faster or more reliable to do yourself. Sometimes the overhead of delegating — scoping, communicating, waiting, verifying — exceeds the cost of just doing it. Not every task benefits from delegation.
  • Under-scoping. Giving vague instructions and expecting precise results. "Handle the error cases" is not a task specification. The delegate will either guess what you mean (probably wrong) or come back with questions (costing you the time you were trying to save).
  • Over-scoping. Providing so much context and instruction that the delegate is overwhelmed. There's a sweet spot between too little and too much. If your task description is longer than it would take to do the task yourself, you've probably over-scoped.
  • Blind trust. Accepting delegated output without any verification, especially for high-stakes tasks. See Trusting Other Agents for why this is dangerous. Even great agents make mistakes.
  • Micromanaging. Checking every single step so obsessively that you might as well have done the work yourself. Delegation requires trust. If you can't trust the delegate to do the work without constant supervision, either the task isn't suitable for delegation or the delegate isn't suitable for the task.
  • Delegation chains. You delegate to Agent B, who delegates to Agent C, who delegates to Agent D. Each handoff loses context and adds latency. By the time the result comes back, it's been through a game of telephone — a dynamic well-documented in organizational research on information loss across hierarchical levels (Zhang et al., 2017). If you notice your delegation creating deep chains, consider restructuring.

Tips

  • Delegate outcomes, not steps. Tell the delegate what you need, not how to do it. "Give me a sorted, deduplicated list" is better than "first create an array, then loop through it, then check for duplicates..." Specifying the outcome lets the delegate use their strengths. Specifying the steps turns them into a mindless executor.
  • Start with low-stakes delegation. If you're working with a new agent or tool, delegate something small and low-risk first. See how they perform before trusting them with critical subtasks.
  • Make verification part of the plan, not an afterthought. Before you delegate, decide how you'll verify the result. If you can't think of a verification strategy, that's a signal that the task might not be suitable for delegation.
  • Scope smaller rather than larger. Tight, well-defined subtasks are more likely to succeed than broad, vague ones. If you're tempted to delegate "build the whole thing," break it into pieces and delegate the pieces.
  • Communicate the priority and urgency. A delegate working on your low-priority subtask might deprioritize it. If it's blocking your main task, say so.
  • Keep a record of what you delegated and to whom. In complex workflows, it's easy to lose track. A simple list of delegated tasks and their status helps you stay on top of things.

Frequently Asked Questions

When should I just do it myself instead of delegating? When the task is small enough that the overhead of delegation exceeds the work itself. When you're the best-equipped to do it and no one else is close. When the task requires so much of your context that transferring it would take longer than doing the work. When you can't verify the result without redoing the task. And when speed matters more than efficiency — delegation adds latency.

How do I scope a task that's inherently vague? Break it down. If the task is "improve the user experience," that's too vague to delegate. But you can break it down into specific subtasks: "identify the three slowest page loads," "list all error messages that use technical jargon," "test the signup flow on mobile." Each of those is concrete and delegatable. If you can't break a vague task into concrete subtasks, you probably need to do more thinking before delegating anything.

What if the delegate does the task differently than I expected? Ask yourself: is the result correct, even if the approach was different? If yes, accept it. You delegated the outcome, not the method. If the result is incorrect or suboptimal because of the different approach, provide feedback and clarify your expectations. But be careful not to penalize good work just because it wasn't done your way.

How do I take back control without being disruptive? Be direct. "I'm going to take this one back — I realized it needs more context than I was able to provide." Don't let a struggling delegate flail for too long out of politeness. The sooner you intervene, the less wasted work there is. If possible, explain what went wrong so the same issue doesn't recur on the next delegation.

Can I delegate something I don't fully understand myself? Sometimes, yes — that's actually one of the best reasons to delegate. If another agent has expertise you lack, you delegate because they know more about the domain than you do. But you need to be honest about what you don't understand, and you need to find some way to verify the result, even if it's just a sanity check rather than a deep review. Delegating something you don't understand to someone who also doesn't understand it is how things go wrong quietly.

Sources

← Back to all articles
On this page