Schedules, goals and mission control
Work that runs on a clock, work you hand over whole, and one screen that tells you which of it needs you.
Scheduled prompts#
A schedule is an ordinary session prompt on a clock. Same agent, model and reasoning level you would pick by hand; it just dispatches itself. The everyday uses are the small reviews nobody remembers to do: a weekday morning brief of commits, open pull requests and what needs attention; a Friday digest of the week; a recurring check of CI runs and dependency alerts.
- Create one from the workspace it belongs to
Schedules live per workspace, in <workspace>/.mirasim/schedules.json — so they belong to the project, review like code, and travel with the repository.
- Write the prompt exactly as you would type it
There is no separate schedule language. Presets cover the common cadences — daily at 9, weekdays at 9, Mondays at 9, hourly, every 30 minutes — or write a plain 5-field cron expression in local time. The minimum interval is 10 minutes.
- Watch it, pause it, or run it now
Each schedule shows its next and last run and its run history, with a link straight into the session a run dispatched. Pause it without deleting it; trigger a run immediately when you want to test it.
SchedulesThis workspace's scheduled prompts: what runs, when it next fires, and what happened last time. — this control is not on the captured screen.
The buttons in this panel work — click them to look around.
Goals: handing over a whole piece of work#
A session is a conversation. A goal is a piece of work with a completion condition, handed to an agent to orchestrate: it splits the work into tasks, dispatches them, drives itself forward, and comes back to you when a call actually needs making. Start one with `/goal` in the composer, describing the objective and what would make it done.
The Goal Room is where you watch it. On one side is the master conversation you shape the goal in; on the other, the contract that conversation produced — the outcome, its testable acceptance criteria, scope, boundaries, explicit non-goals, decisions and assumptions, and whatever is still unresolved. The spec is read-only there, synced from the chat, so there is exactly one place a goal gets changed.
- Aligning
- The orchestrator is turning your conversation into a testable outcome and an execution map.
- Review → Confirm start
- When the outcome, evidence and boundaries are locked, you confirm a specific revision. That confirmation is what authorizes agent work to begin.
- Running
- Tasks execute against the published map, with a mission graph and board, live status per task, and the critical path called out.
- Needs you
- Only decisions that change scope, safety, permissions, or an irreversible outcome block progress. It says how many workers a pending decision is blocking.
- Acceptance → Complete
- Criteria are verified against evidence, not assertions: each node carries its artifact, its verification and the worker record behind it.
Every task node opens onto its evidence — the artifact it produced, whether it was verified, its dependencies and dependents, and the actual work record of the agent that did it. Where a record is missing or unreadable, the room says which and why rather than showing an optimistic summary. You can also add a note about any task, which goes back into the master conversation so the orchestrator continues with that context.
Mission control#
When several sessions and goals are in flight, the workbench is the wrong view — you do not want to read five transcripts to learn that one of them stopped. Mission control is one screen for all of it: how many tasks are active, how many need you, how many need attention, how many finished today.
- Per task: what it is doing right now, its plan, how long it has been on the current step, and an event trail — run started, plan step, sub-agent started or failed, asked you a question, stalled, finished.
- Liveness in plain words: active just now, active N ago, quiet for N — so a stuck task looks different from a slow one.
- System notifications when a task finishes, fails, stalls, or needs you, so you can leave the window.
- Tasks started outside the app show coarse status only, and say so — tasks started here show full live detail.
When nothing is running it says so plainly instead of inventing activity: all quiet, nothing running.
The attention inbox#
Mission control answers "what is happening". The inbox answers the narrower and more useful question: what needs me? Each item carries the verb for what you owe it — answer, align, decide, fix, resume, accept — and how long it has been waiting. Ordinary sessions that finished, got stuck, or need a call show up here too.
Clear an item by marking it read, which removes it from your to-dos and leaves the session untouched, or archive it. The promise the inbox makes is the reason to trust it: if it is not here, you do not need to care.
Something wrong or missing on this page? Tell us