---
{
  "n": 57,
  "title": "How agents orchestrate plans and tickets",
  "abstract": "",
  "refs": [
    "dump:23",
    "doc:56"
  ],
  "seen": [
    "agent",
    "user"
  ],
  "data": {
    "environment": "main",
    "revisions": 1,
    "open_until": 1790274881.9233868,
    "kept": false
  },
  "created": 1790273081.629188,
  "updated": 1790283139.622842,
  "deleted": 0.0,
  "completed": 0.0,
  "outcome": "",
  "type": "doc"
}
---
Redmar's model from a Dutch voice note of 24 September 2026: one worker agent runs each plan through its phases, each ticket has its own orchestrator that starts role agents as it needs them, the environment agent is a co-assistant, and some agents, such as deployment, exist once for the whole journal.

## Summary
- **Plans and tickets.** A ticket is a card on the board. A plan is a subset of the board's tickets, and several tickets can come from one plan.
- **One worker agent per plan.** It orchestrates the whole plan: phase one's tickets first, and only when they are all done, phase two's, because a phase depends on the one before. A plan should be a worktree.
- **The environment agent** can stay, but only as a co-assistant ("how is this or that going?"). The work is done by the plan's worker agent, not the environment agent.
- **A separate agent per ticket, not subagents.** For the three tickets of phase one, the plan agent starts three agents. Each ticket has its own orchestrator, which asks for or starts the role agents it needs from the agent organization, such as a developer.
- **Roles scale.** A developer is not one agent per ticket: any ticket can start one, or two, so there can be many at once. A one-per-plan role, such as a feature planner, gets a queue.
- **Global agents.** Some agents stand outside every plan. The deployment agent is responsible for deployments and exists only once in the whole journal.

## What Redmar said
Translated from the Dutch transcript:

"My question was more what you mean by ticket. Do you mean a ticket is a Kanban item on the board? That's what I call a ticket. But imagine you make a plan, something has to be fixed; then you can of course make several tickets for a plan. So what you call a plan is a subset of all the tickets on a board, and several tickets on a board can come from the same plan. That's why I'd say: one agent per plan, which orchestrates the plan, because you want the whole plan carried out.

A plan is really a sequence diagram, right? In your application I mostly see to-do lists without real dependencies... or you have phases, yes, you have phases, okay. So in theory the plan orchestrator, which must be an agent, makes sure phase one's tasks are carried out first, and when they're all done, phase two's, because there's a dependency. You want one agent orchestrating per plan, not an environment agent.

You can have an environment agent purely as 'hey, how is this or that going?', just your co-assistant. But you do need a worker agent per plan. It delegates: it spins up separate agents, not subagents, one per task it wants done.

Say it's in phase one with three tasks, and tasks are tickets then; it spins up three agents for those three tickets. Each of those tickets has its own orchestrator agent too, which can work out on its own that it should ask for, or start an instance of, a certain type of agent from the agent organization, a developer for example.

A developer isn't one agent per ticket, I saw you called it that. You can spin up developers without limit: this ticket can start one, another ticket can start one, a third can even start two. But if you have one agent per plan, say the feature planner, then a queue comes in.

And you also have agent types like the deployment agent, which is of course a global agent. It sits outside the plan, because it's responsible for deployments, and there's only one of it in the whole journal; you can't have two deployment agents."

## How it differs from today
- Today a ticket is started in an environment of its own with one agent that delegates to domain leads through journal todo delegate. In Redmar's model, a plan agent sits above the tickets, and every ticket agent starts role agents as full agents, not subagents.
- Today the worktree-per-ticket cardinality marks some roles as one per ticket. Redmar would rather let roles like developer scale freely, and queue only roles that are one per plan.
- Global agents, one per journal like deployment, don't exist yet.