The outbox your agent reads first
The bug report was one line long, typed into my own notes at midnight: "select multiple and drag + drop on desktop not working correctly." No ticket, no repro steps, no priority field. By morning the defect was fixed, deployed, and ticked off, with a dated comment underneath saying what changed and how it was verified. Nobody was awake for any of it.
That line went into an outbox. It is the least glamorous idea in our whole setup and the one visitors ask about most.
The pattern
An outbox is one branch in an outline that you and an agent both read. You write work into it; the agent takes work out of it. Three rules turn that from a wish into a system.
The agent reads it first. At the start of every working pass, before choosing anything on its own judgment, the agent walks the outbox. An open item there outranks whatever it had planned. This single rule is what makes the branch trustworthy: you know that a line written tonight is the first thing considered tomorrow, so you stop holding tasks in your head as leverage.
Done means verified. The agent does not tick an item because it believes it finished. It ticks after checking the live system: the page renders, the test presses the button, the export contains the rows. A tick you cannot trust is worse than no tick, because you stop reading the branch.
Every finished item gets a closing comment. A sub-bullet under the ticked item: what changed, the date, the evidence. Months later the branch reads as a history of decisions, in place, next to the words that asked for them.
Notice what the format buys you. Writing a task costs one line, in the tool you already think in. There is no form. Severity, context and constraints go in the note if you have them, and nowhere if you do not. The agent's job is to turn your one line into a reproduction, a fix and a test; making YOU do that work up front is what ticket systems get backwards.
Where the chat version dies
Most people run this loop through a chat window, and it works for a day. Then the ask from Tuesday scrolls out of view. The agent's session ends and the context dies with it. You said "also fix the digest thing" in the middle of a debugging conversation, the model agreed warmly, and neither of you holds a record. Chat is a place where work is discussed. It is a terrible place for work to wait.
A queue needs three properties chat lacks: items persist until someone closes them, state is visible at a glance, and both sides see the same list. A ticket system has all three and fails one person differently: nobody grooms a backlog for an audience of one, and your agent cannot log into Jira anyway.
An outline is the right size
The outbox needs to be a list that both of you can read and write, with checkboxes, notes, and history. That is an outline. In Pando the branch is shared with the agent the way you would share it with a person, the agent reads and writes it through its own connection, and the changes feed tells it what moved since its last pass without re-reading anything.
Our own outbox runs the launch of this product. The one-line reports become fixes; the fixes become dated comments; the comments become the changelog nobody had to write. The inbox pattern, where the agent files work for YOU as checkboxes, is the same idea pointed the other way, and the two branches together replace standups, tickets and status mails for a team of two where one member never sleeps.
Take the shape
Open the template, press "Show in my Pando", and you have the branch with one worked example of a closing comment and two open items showing the shape. Delete the examples. Then put one line in your agent's instructions: read this branch first, work it before your own ideas, tick with evidence. Write your first one-line report tonight and see what the morning does with it.