What_Routines_Doesn't_Solve

Routines handles scheduling and execution. It doesn't handle orchestration. It doesn't coordinate between agents. It doesn't enforce quality gates. It doesn't know what an agent should know when it starts.

My nightly repo audit — deployed in April as a Claude Routine (trigger ID: trig_01D6WAcCPALST8R8t1w8BFES), running every night at 5am SGT — is the first production Routines deployment in my system. It checks four health signals across six repositories: failing CI (GitHub Actions status on main), open Dependabot PRs, stale branches (no commits in 30+ days), and open PRs older than seven days. Results post to Slack #updates. Routines triggers the execution, runs the prompt on Anthropic's cloud, and handles the scheduling constraint — the audit runs once per night, deliberately within the daily run quota.

What Routines doesn't do: it doesn't read the manifests before starting the audit. It doesn't know what "stale branch" means without the audit prompt spelling it out. It doesn't coordinate with the other eleven agents to decide whether to run simultaneously or sequentially. It doesn't enforce the PR comprehension gate or the spec-before-code rule — those are still human or orchestration decisions.

The manifest infrastructure the audit relies on — the depends_on fields, the failure_modes declarations, the per-module contracts — that's the knowledge base. Routines is the scheduler. The two layers are distinct. Confusing them explains a lot of the hype coverage.

The_Operational_Layer_Still_Yours

Before Routines, I had session-boundary documents. Sessions ended with a write to a file: here's what's done, here's what's blocked, here's what the next agent needs. That bridge still exists. That discipline is still required.

Before Routines, I had model tiering rules. Sheena (the orchestrator) is the only Opus user. Sonnet-tier agents do code and strategy. Haiku-tier agents do copy and design. That routing decision still happens. Routines doesn't know about role hierarchies.

Before Routines, I had a spec-before-code rule: anything touching more than two files requires a brief first. That rule is still in place. Routines doesn't check whether a brief exists.

The scheduling problem is solved. The coordination problem is not. The knowledge persistence problem is not. The orchestration problem is not.

What this changes about running a multi-project agent team: you replace your session management conventions with a cloud scheduler. You stop writing "use /handoff before ending a session" because the scheduler handles session boundaries now. You keep everything else.

That's the upgrade path Routines creates. Not autonomy. Not full-stack agentic decision-making. A faster trigger mechanism for something you were already doing manually.

For a solo operator like me, running twelve agents across six repos, the upgrade is concrete: one less thing to script, one less thing to manually trigger, one less place for discipline to slip. The audit runs reliably at 5am without me starting it. That's the win.

The question it raises isn't conceptual. It's operational. If your agent team is currently held together by handwritten session management conventions and manual triggers, what gaps would a scheduler actually fill — and what would you still have to provide?