The questions your agents save for you

Asking without interrupting

An agent that stops to ask you something has two bad options. It can ask in its own chat and hope you look, so the question sits in one of six terminals while the agent idles. Or it can guess, and you find the guess a day later, built on. Neither is what you want when you are running several agents at once and your attention is the thing in short supply.

Codecast gives the agent a third option. It writes the choice up as a decision: one question, the options with what each one costs, and the reasoning you need to pick without opening its session. The decision goes into your queue, the agent ends its turn, and by default nothing more happens in that session until you answer. Your other agents keep working.

What the card carries

Here is a real one. On September 13th the agent that runs our Google Ads check had been checking a campaign that was not serving for ten days. It had run out of useful work, and rather than keep reporting the same three facts every day, it asked:

The question is a question, not a status report. Under it, the page names the session that asked and the person it was asked of. Then the context, written for someone who was not there: why the campaign is dark, what the earlier checks found (Google was serving the bare query "claude code" off one of our keywords), why a daily check still has some value, and what the agent will do either way. You can decide from this page without opening the session. If you would rather talk it over first, Discuss opens a thread with that agent about this decision.

Below the context are the options, and each one says what happens if you pick it:

The costs cut both ways. Checking every three days saves about a dozen empty runs, and it means a restarted campaign could go unnoticed for up to three days instead of one. Keeping it daily catches a restart within a day and spends about eighteen more runs saying nothing new. Neither option is padding. Each one is something the agent would actually do.

When the agent has a preference, it says so. Here is another decision from the same month, about how to fix a delivery problem in codecast itself. The agent marked its pick, and the card shows the mark as Suggested at the end of that row:

Answering in one sitting

Every open decision from every agent lands in one queue, Questions in the sidebar, with a count of how many are waiting on you. The order is deliberate. Questions whose agent is stopped and still reachable come first, because answering one restarts work right away. Questions whose session has gone away come next. Advisory questions, where the agent named a default and kept working, come last. Within each group the oldest comes first, so the queue does not reshuffle while you work through it.

You can read the queue as a list or step through it one decision at a time. In the one-at-a-time view the keyboard does the work: a number key picks that option and moves on to the next decision, T lets you answer in your own words, P passes a decision to someone else, X dismisses one that no longer matters, and Esc takes you back to the inbox. When an option does not fit, the answer you type goes to the agent as a message. The desktop app shows the same queue, and the phone app has a Decisions screen with the same order: tap an option and it moves to the next one.

The queue is not pictured here. On the day we wrote this it held five open questions, all from other projects, and this blog only shows codecast's own work. The decisions in this post were answered weeks ago, so they have left it.

What happens after you answer

The decision also lives in the conversation that asked it. In the agent's transcript the card sits inside the turn where it was posted, collapsed, with its status and your answer in the header:

Your answer reaches the agent as your next message, Check every 3 days while dark, with a link back to the ask. The agent was parked on exactly that, so it starts its next turn from the answer:

It did what option 1 promised. The trigger's history shows the schedule moving from every day to every three days seventeen seconds after the answer was recorded. Then it took care of the part that is easy to lose: option 1 included a promise to go back to daily the day the campaign served again, and a scheduled agent does not remember a promise between runs. So it wrote the condition into the task its runs report to, where the next run would read it: the first check that sees the campaign serving again puts the schedule back to daily.

That is the loop. The agent asks once, with everything you need. You answer when you are ready, alongside every other question waiting on you. The agent carries on from your answer without you having to say more.

From a script

Agents post decisions with a command, and the card is what that command produces. You never need to type it, but if you script your own agents, this is how one asks:

$ cast decide "Should the daily check keep running every day?" -o "Check every 3 days :: what happens if chosen" -o "Keep it daily :: what happens instead" --context -

Codecast records every coding agent session you run, on any machine, and gives you one place to see them, steer them and answer them.

All five screenshots are the codecast web app on 2026-10-15, of two real decisions about codecast's own work, both asked and answered in September. Each is cropped to the content column: the sidebar, the top bar and the right rail are outside every crop. On the ads decision, the context's last paragraph and the agent's status line under the card are cropped out because they carry the campaign's dollar figures. On the second decision, the third option is cropped because it names another project. The open queue is described from the app, not pictured, because it held only other projects' questions that day. No decision was posted, answered or edited for this post.