Intent, isolated execution, familiar review.
Work is the human-facing task or issue. Attempts are optional candidate executions underneath it. Pull Requests are the familiar Git collaboration boundary where a candidate asks to become canonical.
The three layers
| Concept | Answers | Can exist without Agents? |
|---|---|---|
| Work | What are we trying to accomplish, who owns it, and is it open/closed? | Yes. Work is useful as an ordinary issue/task with body, assignee and comments. |
| Attempt | Which isolated candidate is trying to implement the Work? | Yes. A human or deterministic tool can own an Attempt; it is not inherently an LLM concept. |
| Pull Request | Is this concrete Git branch ready to review and integrate? | Yes. It remains a normal PR surface with commits/files/checks/conversation. |
Work is the issue/task model
A Work item records durable intent: feature, bug, refactor, investigation, maintenance or release task. It can have a description, status, assignee and comments and may never create an Attempt at all. That keeps the simple human-only case familiar.
Work #142 Improve repository error states
status: open
assignee: nick
comments: 3
# no Attempt is required until somebody chooses to execute it
Attempts make concurrency explicit
When implementation begins, one Work item can have multiple Attempts. Each Attempt has isolated Git state and its own execution/provenance history. That makes competing approaches first-class instead of forcing every Agent onto one shared branch.
| Attempt | Actor | Branch | Possible outcome |
|---|---|---|---|
| A | implementer Agent | attempt/a | passes review and opens the winning PR |
| B | human | attempt/b | abandoned after benchmark comparison |
| C | alternate Agent role | attempt/c | fails a contract check but remains useful provenance |
Failed and losing Attempts are not silently discarded. They explain what was tried, which can matter as much as the final diff when automated engineering becomes highly concurrent.
Pull Requests stay familiar
A PR proposes an Attempt branch against a base. The default surface is ordinary Git-host collaboration: conversation, commits, files changed and checks. Switchyard-specific state — Attempt, Agent execution, provenance, risk, queue state — appears progressively when it exists.
Lifecycle example
Work: "Add repository search"
├─ Attempt A (human) ──┐
└─ Attempt B (agent) ──┼─ compare/review
└─ PR from B
├─ check
├─ Review Findings
├─ preview against current main
└─ Integration Queue → main
demo-agents is one Work item with concurrent Attempts so the distinction can be explored without reading implementation fixtures.