Delegating work

Added · Last updated
Prerequisites

The actor has work that an agent could do and has judged that handing it over is worth more than doing it themselves. That judgement happens before this sequence, and no pattern here makes it. The sources the agent should work from exist, and the actor can point to it. Setting permissions and trying the agent out first are settled elsewhere, if at all.

The actor has work worth handing to an agent, and the sources it should work from are at hand. The run can happen both while the actor watches or they don’t, and several steps differ between the two.

Two other sequences lead here: the encounter, where an open request becomes the prompt, and assistance escalation, where a procedure that keeps recurring whole is handed over to run.

Handing the work over

  1. Write the request — Prompt

    Help the actor turn what they want into a request the agent can act on, in their own words and without special syntax. Ask only for what this run is missing, and leave standing preferences until early use gives the agent a reason to ask. Keep the request so the actor can edit it, reuse it, or make it a template.

  2. Attach the sources to work from — Reference material

    Let the actor attach files, mentions, and connected sources inside the request, so the agent works from their sources rather than from general knowledge. Show what is attached and let the actor remove it. Citations later point back to these sources.

  3. Hand the goal to an agent — Agent

    The actor can state the goal but not the procedure, so an agent decides how to reach it. Decide whether the agent works in a focused view, inline, or in the background, and keep how much it may do on its own easy to find. The work now happens while the actor is not watching, so the agent owes an account of it, which the next steps provide.

Following work out of sight

Applies when

The run has started and the actor is elsewhere, nearby for a few minutes or away until morning. The agent owes the account promised when it took the work on.

  1. Show the work as it happens — Live presentation · optional

    Show the output as it forms, so the actor can read ahead, judge early, and stop the run. Skip this for a run nobody watches by design, such as an overnight agent; the status and the record cover it.

  2. Keep the run's status visible at a glance

    Show whether the run is still on task, what it has produced so far, when it acts next, and which way its measures are moving. A run waiting for its next trigger still shows that it is live, with a countdown or a current reading. When a measure moves in a worrying direction, the status becomes an interruption.

  3. Show the reasoning — Transparent reasoning

    Show how the agent is working, in the form that fits who is watching: a running account beside the live output when the actor watches, and explanations attached to the record when nobody did.

  4. Keep a lasting record — Activity log

    Record each event with who acted, what they did, what it applied to, and when, and let the actor narrow the record down. This is the account the agent owed when it took the work on.

Receiving the result

Applies when

The run has finished and something substantial has arrived: text, a draft, or a set of changes. The actor's job is now to judge rather than make. Accepting all of it takes no effort, while checking it takes time in proportion to its length.

  1. Present the result for judgement — Generated content

    Let the actor rate the result, take parts of it, and trace each part to the source it came from, so they can stand behind a result they did not make.

  2. Decide where the result goes

    Decide for each result. A short answer that is read once stays in the reply and needs neither.

    Combine any of:

    • Show the result as a set of changes — Change review

      When the result changes something that already exists and matters, show what was there and what would replace it, and let the actor accept it in parts. Show enough of what surrounds it to judge the change, since the actor did not write it and did not watch the work.

    • Move the result out of the conversation — Extraction

      When the result matters more than the conversation that produced it, give it its own name, link, and versions, so it no longer depends on the conversation. Decide what the conversation keeps, so it still reads afterwards as a record of what happened.

Correcting the result

Applies when

The result is not right: close but wrong in a way the actor can name, or wrong in a way they can only reject. Each correction works on the result wherever the previous step put it.

  1. Choose how to correct it

    Choose for each problem, not once for the whole system, since all of these are needed. A third option, making the change directly, leads out of this sequence.

    Combine any of:

    • Say what to change — Instructed revision

      Let the actor say what is wrong, such as shorter, warmer, or only this part, so the result changes without being remade or the request rewritten. Let the actor limit a change to one part, so the parts that were already right stay as they are.

    • Ask for another attempt — Regeneration

      Let the actor ask for another answer to the same request: the whole, a part, or several versions side by side to compare. A new attempt replaces the previous one, and keeping a way back to it is handled elsewhere.

  2. Turn a repeated correction into a standing rule — AI tuning

    When the actor gives the same correction for the third time, offer to make it a rule for every session. Either side can notice the repetition: the actor promotes the correction, or the agent counts the repeats and proposes the rule.

Leaves: The actor corrects results by judging rather than writing, and corrections that recur have become standing rules. The actor has shaped a result they never wrote, so it is unclear who authored it and who answers for its details.

Connections