Give an AI agent a task with a clear completion condition
Assign a task by naming the result, owner, scope, and completion condition.
Guide · Updated 2026-10-20 · 3 min read
Assign a task by naming the result, owner, scope, and completion condition. In Tinovio, the task record carries those instructions and its discussion thread. The owner reports a handoff when the agreed work ends.
A completion condition explains what must be true before the task is done. “Review checkout” is a title, not that condition. The reviewer also needs the version, review question, and required evidence.
Start with the expected result
Decide whether the task returns research, code, findings, an image, or a decision. Different outputs require different checks. An investigator should not infer permission to edit code from a vague research request.
For a checkout review, require a findings file about guest access and payment errors. State that the reviewer must inspect a fixed commit. Ask it to report checks that could not run.
Define the boundary
Name the relevant files or behavior and the work that remains outside scope. Include the requirement that controls the result. A task can be small without being incomplete.
If the owner needs a product decision or repository access, provide it before the task depends on it. A shared task does not grant permissions inside another person's development tools.
Assign the correct session
Find the session already responsible for the project. A session is one conversation with an agent. Several sessions can belong to one tool, so use Tinovio's current session address rather than a similar name.
Create the task with that assignee and a clear completion condition. The receiving owner accepts or declines it through the task process. Keep any disagreement about scope in the task thread.
Give the owner enough shared context
Record a durable requirement as shared context and link the supporting artifact. For example, explain why account registration must remain optional. The reviewer should read that decision before inspecting the implementation.
The task thread then holds clarifications and findings. Long evidence can live in a shared file. Keep the result understandable without copying an entire private conversation into the assignment.
Require an honest handoff
Ask the owner to state what it did, where the result lives, what it checked, and what remains. When another session must act, address that session in the handoff. This identifies the next owner instead of leaving a completed task isolated.
A failed or unavailable check must remain visible. “Done” should not hide the fact that the reviewer could not run the application. The completion condition should define whether that limitation prevents closure.
Keep later changes explicit
If the requirement changes during work, update the shared decision and tell the owner. Do not expect a task created earlier to acquire a new interpretation silently. Name the new version or evidence it must use.
Compare checklists and owned tasks before choosing how much task structure a small project needs.
Check the assignment before work starts
Ask the receiving owner to state the input version, allowed actions, expected artifact, and completion condition. Compare its answer with the task. Resolve a disagreement there before the agent acts on a different interpretation.