A ticket is a single, scoped unit of work: one task, one issue, one thing to build or fix. In the agent era a good ticket is more than a to-do line. It is a small package of context an agent can act on directly.
What makes a ticket agent-ready
The same qualities that make a ticket good for a human make it good for an agent, and the agent is stricter about it because it cannot lean on the hallway context a teammate would have:
- A clear title and a one-paragraph description of the outcome.
- Scope: what is in, and what is explicitly out.
- Pointers to the relevant files, docs, or prior work.
- Acceptance criteria, so both of you know when it is finished.
A ticket like that is really a small spec. The difference is mostly size: a spec might cover a feature, a ticket covers a slice of it.
One ticket, one context
Scoping matters because context is finite. A tight ticket keeps the session focused and makes a clean handoff easy when the work rolls to the next agent or the next day. A sprawling ticket, by contrast, drags in half the codebase and thins the agent's attention across all of it.
Related terms
Spec
A spec is a written description of what to build and why, handed to the agent up front. Specs-as-context reliably beat vague one-line requests.
Read definition →Agent
An agent is a language model wrapped in a loop that lets it call tools, read the results, and decide what to do next. The model supplies the judgement; the loop and the tools give it hands.
Read definition →Handoff
A handoff is passing work from one session or agent to the next by summarising the current state, so the successor can continue without relearning everything. It is the antidote to a dead or overflowing window.
Read definition →