A routine that only runs on a clock is useful.
A routine that runs when the workspace itself changes is operational.
Fractal routines now cover both. You can still schedule recurring work. You can also attach a routine to activity in the workspace, to an external webhook, or to a manual fire — and assign the agent that should own the run.
That is the shift: routines stop being a calendar feature and become a reaction layer for the workspace.
What changed
Earlier, routines were mostly about repeating a job on purpose — a daily brief, a weekly review, a recurring pass.
That still matters. Schedules remain first-class.
What is new is that a routine can listen.
A task moves to in_review. A comment lands. A status changes. An external system posts a webhook. Fractal can start the right agent with the right prompt, keep the run attached to chat history, and leave a trail you can inspect later.
The workspace does not wait for someone to remember the ritual. The ritual is encoded next to the work.
Three ways a routine starts
Every routine has one or more triggers.
Scheduled. Cron-style cadences for work that should happen even when nobody is watching — nightly audits, heartbeats, recurring planning.
Activity. Workspace events with optional filters. A routine can fire when a task is created, when status changes to a specific value, or when a comment is created by a specific causer.
Webhook. External ingress. Another system asks Fractal to act, and the run still lives inside the same agent boundaries and audit trail.
Manual fire remains available for testing and deliberate runs. That is how you prove a routine before you trust it on a live event.
What this looks like in practice
The pattern is not abstract. It shows up as concrete operator workflows.
When a task enters in_review or stopped, a routine can load the full task, read the thread, and notify the founder on Telegram — without anyone rewriting the alert each time.
When a task is created for planning, a routine can open the workspace, write the plan, create todos, and leave open questions for review.
When a comment arrives, a routine can reply in-thread like a teammate — refining the plan if the task is still in planning, or answering the question if it is not.
Same primitive. Different jobs. The trigger decides when. The prompt and assigned agent decide what and who.
Assignment is part of the contract
A routine is not a floating automation script.
It has an owner.
You can assign a concrete agent. You can target the workspace orchestrator. On manual fire, you can fan out to every agent when the job truly needs the full roster.
That matters because Fractal is multi-agent by design. Atlas plans. Orion implements. Veda documents. Aurora analyzes. A routine inherits that roster discipline instead of collapsing everything into one anonymous loop.
Bounded autonomy stays intact: timeouts, scope, and reviewable runs keep the loop from becoming magic you cannot debug.
Runs you can inspect
Every fire leaves a run.
You can see what started, what finished, what failed, and when. The execution is not a black box buried in a log file — it is chat-as-run history attached to the routine itself.
That is the difference between automation you hope is working and automation you can supervise.
If a routine misfires, you open the run. If it succeeds, you keep the trail. If you need to change the prompt, you edit the routine and fire again.
Why this matters
Most tools treat recurring agent work as a schedule with a prompt.
Fractal treats it as part of the operating system: durable prompts, event-aware triggers, named agents, and inspectable outcomes — living next to tasks, goals, memory, and channels.
The clock still matters.
The workspace matters more.
When work moves, Fractal can act — on purpose, with an owner, and with a record of what happened.
That is what turns routines from recurring prompts into a daily operating layer.