Letting agents work overnight: the morning review queue
Dennis Zaiser, technical founder
The appeal of unattended agents is simple: queue the work before you stop and wake up to progress. The usual morning is less simple. One run stopped at its first question and sat there all night. Another went in circles until it hit its budget. A third finished, confidently, the wrong thing. The difference between that morning and a good one is rarely the model. It is what the agents were given before you left, and what waits for you when you come back.
Choose the night's work before you leave
Only ready work should run unattended. Ready means three things: the item says what done looks like, it has no open questions, and it doesn't depend on something still unfinished. An item that fails any of these ends in a guess or a stop, and overnight nobody is there to tell the difference. A useful check before you leave: read each item as if you were the agent, with no memory of the conversation that produced it. If you would need to ask a question, the agent will too.
Keep items small enough to review in a few minutes each. A night that produces three reviewable changes is worth more than one that produces a sprawling branch nobody wants to read at breakfast. And take them in the order your plan says matters, so the work that unblocks the most lands first.
If an item needs a product decision halfway through, either make the decision before you leave or design the work to stop at that point and wait.
A run that meets a question waits, not guesses
An agent that meets a real question while unattended has two poor options: guess and carry on, or stop and hold the session open until morning. A third works better. The run records its question with what it has found so far, and waits. Waiting costs nothing: no tokens, no open session, nothing held. Other ready work goes ahead in the meantime.
Faults deserve the same treatment. A run that can't continue, because a service is down or a command keeps failing, should wait with a plain account of what went wrong rather than retry until morning.
Checks decide, not the agent's account
An agent's summary saying that all tests pass is a claim. In a supervised session you would glance at the output. Overnight, nobody does. So the checks have to run apart from the agent's report, in the run's working copy, and their results have to be what decides.
Three mechanisms carry most of the weight. A step can't close until its declared outputs exist. A check that must pass blocks the step until it does. A fix loop repeats until the checks pass, or until a limit you set, and then waits for you instead of trying forever. Bound each run as well, by wall-clock time and tokens, so that one stuck run can't spend the night's budget.
Use the checks you already trust in the daytime: the test suite, the type check, the lint, and whatever the project runs before a merge. Night is the wrong time to introduce a new check. One that fails at random at two in the morning stops a run for nothing.
And one guard is cheap and not negotiable: an agent the engine started never approves its own work. The approval waits for a person.
The morning review queue
What you want at breakfast is one list, not five terminals. Each entry names the item and what was asked, shows what the run produced and the check results, and points to the branch or pull request. Then it offers the decision: approve, send back with a note, redo or cancel.
Questions belong in the same queue as approvals, because both are things waiting on you. Put first whatever unblocks the most work, since one answer may restart two runs. Read the diff where it lives, in your repository, with your own tools.
Decide in the queue, not around it. Approving a change by merging it by hand, or answering a question in a chat window, leaves the run waiting and the record wrong. The decision belongs where the run can pick it up.
A good queue takes one coffee to clear. If it takes the whole morning, the items were too large or too vague, and that is where to fix it.
What to watch over the weeks
A few measures tell you whether overnight work is paying off. How often a run's work is approved without being sent back. How long items wait on you. The estimated cost per item, and how much went into runs that never landed.
Read them as feedback on the inputs. If items keep coming back, the item descriptions or the rules need work, not the model. If runs keep stopping on the same kind of question, write the answer down as a rule, so the next run doesn't need to ask. And watch the waiting itself: a run that waited all night for an answer you could have given in a minute before leaving is the most expensive kind of idle.
Where ctxflows fits
The Engine page covers the night. The engine runs your agents unattended on your machine or server, picks up only ready work in the order your roadmap sets, runs the checks on your machine, and delivers each change as a branch to review or lands it one change at a time with your checks. Workflows supply the structure: loops that repeat until checks pass, and approvals that stop for your decision.
Runs & actions is the morning. Every run is in view, with its position on the workflow's graph. An approval shows the outputs, the checks and the branch, and questions and approvals sit in one inbox of everything waiting on you, answered in the web app, the assistant or your own agent. For example: three items built overnight, and in the morning two approvals and one question waiting.
Analytics tracks the rest: first-pass rate and rework, time waiting on you, and estimated cost per item. The diff stays in your repository; your code never enters ctxflows.