Pick a task whose result you can judge before you start the agent. A first delegation succeeds when you can tell whether the work is useful, identify what the agent changed and recover without reconstructing the whole project. Choose a recurring irritation you understand well enough to describe with a concrete input and expected output.
Pick a task whose result you can judge before you start the agent.
This guide uses real accounts as evidence of what people delegated. The procedure below is our editorial recommendation, not a claim that their results transfer to every team. Follow the source links before borrowing a use case, especially when the account leaves its review process unclear.
Start with a defect you can point to
Write down one observable problem. For a website, that might be formatting leaking into a preview, a button failing with a particular input or an exact-name search returning the wrong page. Include the URL or local route, a sample input and the behavior you expect. Avoid making the first task a broad instruction to improve the whole application.
Simon Willison's blog fix gives a useful example. He supplied a visible Markdown problem and asked Codex for a fix with passing tests. Our entry records the environment and review boundary.
Choose a similar task in a system you already use. If the problem only appears with private customer data, create a sanitized reproduction first. Confirm that the sample still fails. A convenient sample that misses the problem gives the agent a misleading target.
Write the check before the request
Describe the observation that would convince you the task is complete. For a preview bug, inspect the actual rendered description. For a file transformation, compare the output with an independently prepared expected file. For a research task, open the sources behind the most important claims.
Prefer a check that survives changes to the implementation. An agent can rename a function or reorganize files while preserving behavior. A test that only confirms those internal names may obstruct a sound fix without proving the user sees the right result.
The Datasette plugin walkthrough illustrates the danger. Its initial tests passed while a real page failed. Willison made the failure visible to the test before delegating the repair. Read the video entry for the runner and tools used.
Compare candidates by review cost
List a few tasks from your own backlog. For each, write the artifact you expect and how you would inspect it. Estimate the human effort required to confirm correctness, including setup and cleanup. A task that saves typing but creates an hour of uncertain review is a poor first experiment.
A small code fix can be suitable if you can reproduce it locally. A sourced research brief can also work if the question is narrow and you know how to evaluate the literature. Purchasing, sending customer messages and changing production access rules add consequences that make first-run evaluation harder.
Choose the candidate with the clearest check and easiest recovery. Treat tool availability as a requirement: a browser use case needs a browser the agent can actually drive, and a test-driven repair needs a working test environment. Resolve missing dependencies before judging the agent's implementation.
Bound the workspace and permissions
Put the work in a separate branch or scratch directory. Supply the files needed for the task and explain which inputs are authoritative. Keep production credentials outside the workspace unless the chosen task needs them and you have a deliberate permission plan.
Make the first deliverable a proposed change or local artifact. Reserve merge, publication and paid transactions for review. State that boundary in the request and, where possible, enforce it through the available tools. A prompt that says to stop cannot remove a capability already granted by the environment.
Write down the permitted commands and network destinations in terms the operator can check. Avoid a long list of hypothetical restrictions. If a dependency fetch is necessary, specify the approved package source. If the run needs a database, use a disposable database with representative data.
Give the agent a completion contract
Use this request as a starting point, replacing every bracketed input:
Fix [specific observed defect] in [repository or workspace].
Reproduce it using [command or local route] and [sample input].
The expected behavior is [observable result].
Use the current project conventions and keep the change bounded.
Run the relevant checks and inspect the resulting artifact.
Return the diff, checks, failures and unresolved assumptions.
Stop before merging, publishing or changing production resources.
Keep the output requirements short enough to inspect. Ask for command results and file paths, rather than a confident narrative. If the agent cannot reproduce the defect, require it to explain the missing condition before modifying unrelated code. That preserves the experiment's original question.
Review the artifact and the boundaries
Run the completion check yourself. Read the proposed change at the level needed for its consequences. Check whether the agent edited tests, fixtures or configuration in ways that made the result easier to claim. A green test suite deserves less weight if the relevant assertion disappeared.
For a research artifact, sample claims with a bias toward the most consequential ones. The orchestrion research account explicitly leaves its output unverified and incomplete. Use that distinction when deciding whether a research draft is ready to publish.
Record time spent preparing, waiting, reviewing and repairing. Keep the initial input and the final artifact together. Do not convert one successful run into a general productivity metric. Your immediate goal is to discover whether this particular task fits your use case.
Repeat before expanding access
Try another input with the same permissions and review process. Include a case with missing information or an expected failure. Confirm that the agent reports the limitation instead of producing a plausible replacement result.
Once you can judge several runs, change one boundary deliberately. A larger input set may be enough to test usefulness without adding publishing access. Keep the independent check, compare review effort and retain a recovery path. The next delegation can grow from evidence you collected in your own environment.