Skip to main content
By the end of this page your task exposes the inputs you intend, keeps its scoring data private, and validates cleanly. You need a task folder from Initialize Task. World data is optional: a task whose inputs fit in workspace/ needs nothing on this page beyond the first section.

​
Files the agent can read

Anything under workspace/ is visible to the agent and counts as task input. For expense-audit that means the claims export and the policy document. Files the agent creates in the workspace during a run are its output, so you do not need to declare output filenames. Keep the answer key out of this folder; it belongs in the task package’s private data. Workbooks are ordinary files here, up to 25 MiB each, ten per task and 100 MiB in total. Save a recalculated copy if your verifier reads cached formula values.

​
A repository to change

For repo-python and repo-node starters, author the checkout under assets_src/repo/ and bundle it whenever it changes:
Bundling builds the repository asset and pins its base commit. The agent receives the checkout at repo/; hidden tests run against a fresh copy with the agent’s changes applied. Give the repository a realistic history and a starting state that does not already pass the checks. Node dependencies are installed offline, so keep package.json and package-lock.json in the repository and vendor anything that needs a build step.

​
Simulated services

A task can declare simulated GitHub, Linear and Slack services. The agent uses the same tool calls it would against the real products: it can read issues, files, tickets and channels, and it can create issues, update tickets, comment, post and reply. Reads show the initial world, successful writes change it, and every call is recorded for the verifier. No real account is connected; the services are clones seeded from your fixtures. Generate a fixture, then replace the generated records with your task’s world:
Each fixture separates public records, which the agent sees through the service, from private state that only the verifier reads. For expense-audit, the finance lead’s Slack reminder about the policy is public; the list of claims she expects to be flagged is private. A schema check cannot see an answer pasted into a message body, so read your own fixtures for leaks. Order matters. Records are replayed in the order you list them, one minute apart, so put issues in ascending number order and conversations in chronological order.

​
Keep people consistent

The registry in seeds/world.json names the people and organizations in your world. Give each real person one handle and use the same display name and email in every service so the linter can connect them:
The registry does not duplicate channels, tickets or messages; those stay in their service fixtures.

​
Grade the resulting world

For service tasks, the verifier can inspect the final state of each service and the recorded calls. Prefer final state for ordinary success, such as the Slack message existing in the right channel or the Linear issue being closed, and use the recorded calls only when the exact action or its order matters. The platform verifies that the recording is authentic; only your verifier decides whether the outcome is right.

​
Validate

Success: validation passes, a debug run shows the agent reading the intended inputs, and the trajectory contains no private data.

​
Next steps

  • Submitting Tasks explains what happens once the task is ready.
  • Run droyd task seed --help and droyd task world --help for fixture and registry options.
In active developmentTask authoring is in active development. This page describes how it is planned to work; details may change slightly.