Routines: standing work for @g1t on a trigger (design first, then phases) #198

Design and build Routines: saved work for @g1t that runs by itself on a trigger, with nobody at the keyboard. The owner calls this "a huge one". Start with a design the owner approves, then build it in phases, each shipped (on main and deployed) before the next.

The owner's direction (2026-10-15)

• Routines aren't only about code. They're standing instructions to @g1t, a personal and team assistant that takes things over. Examples: a morning brief, a digest posted to a channel, follow-ups and reminders (one-off ones too), a watch on production, spend or a topic, as much as triage or CI fixes.
• The name stays Routines ("Tasks" clashes with work items, "Automations" with Actions). A routine is "say what, say when, say where it lands". Whose it is also belongs to the object: yours (it runs as you), or the workspace's (kept by a team, so it outlives anyone leaving).
• Routines is its own rail mode, after Artifacts, for every member and not gated on Code, at /<workspace>/-/routines. A stub of the page is on main with every control disabled (c430feda, 7352c5da). It has the composer (what / when / where it lands / whose), the tabs Yours · Workspace's · Runs, starting points grouped as Keep up, Team, Code, Watch and Find work (which proposes work items that wait for a person's yes), and "How a routine works". Build onto that page rather than restarting it.

The shape people already know

Claude Code routines (a research preview since 2026-04-14, at claude.ai/code/routines or /schedule) are a saved setup: a prompt, one or more repositories, connectors or MCP servers, and who the routine runs as. Triggers can be combined: a schedule, an API endpoint with its own bearer token, and repository events. Each run starts fresh, with the prompt carrying all the context, and keeps running with the laptop closed. Plans limit runs per day. Check Anthropic's current docs before relying on any of this.

What it should be on g1t

A first-class object in a workspace (and on a repository) that is listed, edited, paused and run by hand from the site, the CLI (g1t routine …) and the MCP server (a routine resource tool with an action). Every run is a g1t session: titled and recorded, with its pull requests going through checks and the merge queue like anyone's, and its cost on the workspace's bill. People can see what each routine did, when, and why.

Build on

• services/integrations/src/agent_sessions.rs: g1t starts a Claude Managed Agents session on the workspace's own Anthropic key, records it as a g1t session (harness claude_managed_agents), and keeps its token in a vault the model never sees. Today it's started by hand for a work item.
• g1t Actions: crates/actions/src/cron.rs (schedules), services/actions, runners and their sandboxes (crates/runner), workspace managed workflows.
• Sessions, claims and decisions: services/work/src/coordination, guides/sessions.md.
• Chat channels and @g1t (services/chat), notifications, webhooks, events. Ask and a DM with @g1t are one conversation, answered by the workspace's own provider.
• Billing: per-run cost, limits and budgets (services/billing).
• The sibling investigation, #186 (how g1t runs GitHub Agentic Workflows): a routine and an agentic workflow overlap. Decide whether one is built on the other, and say so.

Design questions to answer before building

1. The object: its fields (prompt, repositories, triggers, runs-as, connectors, output policy, caps), where it lives (workspace or repository), and whether it can also be written as a file in the repository.
2. Who it runs as, and with what rights: a run credential like agent_sessions' (g1t acting for the person who made it, with their role, on that repository only), and what happens when that person leaves or loses access.
3. Where it runs: Managed Agents on the workspace's key, a runner sandbox with the person's harness, or both. Cover failover (people's computers first, then g1t cloud), and how a run is recorded either way.
4. Triggers: cron with a sensible minimum interval, an API endpoint with its own revocable token, and repository events through the event bus. Cover debouncing and concurrency: a routine never runs twice at once on the same thing.
5. Safety: what a run may write (draft pull requests, comments, work items, messages), approvals that wait for a person (today a call that would wait is declined), budgets per run and per day, and a kill switch.
6. Visibility: the routines page, each run's session, failures that notify the owner, and Home's daily update picking up what routines did.
7. Limits and billing by plan, using the existing pass-through-plus-overhead model.
8. Phases: the smallest first slice that ships (likely a scheduled routine on one repository, run as a Managed Agents session, recorded, with a page to create, pause and run it), then triggers, then runner execution, then files in the repository.

Rules

• g1t runs no models of its own: the workspace's provider or the person's agent does the thinking. There's no model picker.
• Runner work runs in host-proof sandboxes.
• The architecture is services, contracts and events. API bodies are snake_case. MCP is a few resource tools with an action, filtered by token scopes.
• UI comes from shadcn components; a single action goes in a dialog.
• Docs are updated with every phase (guides and reference).

Deliverable for the first session

The design, published as an artifact the owner can read and share, with the open decisions called out. Stop and ask before building. Once the owner approves, build in phases under this item.

How to work on this repository

• Claim this item before you start (g1t work claim <number>), and add G1t-Session: $G1T_SESSION to every commit.
• Other sessions share the main checkout: work in a worktree of your own and stage only your own files.
• Pushing to main deploys production, and pushes to main and release tags are the owner's. Land the work through a pull request on this item, or commit locally and hand the owner the exact git -C <path> push ….
• Shipped means on main and deployed. Check it live with real data and look at the rendered pages: a status code doesn't show it works.
• Docs ship in the same change as the feature (guides, reference, llms.txt), to a high standard.
• User-facing text never names other products or compares g1t to them. Internal notes and code comments may.