Routines

A script you author with a coding agent and Foundation runs on a schedule, so a metric or a list stays current without a person.

A routine is a scheduled task that runs across your context layer: to feed it with data from other systems or workflows, notify people or systems, test for hallucination, clear up conflicts or run other maintenance. You build routines, and Foundation deploys them.

The most common routine feeds an entity from a source, and that is the case this page walks through. You author it with a coding agent, from the source’s documentation and Foundation’s runtime contract; save it through the connector as an immutable revision; preview it; and activate it on a schedule. Foundation runs it after your session closes, in an isolated runtime, with the source’s credentials injected by the host and never visible to the script. Its writes go through the same gate as everything else, under a courier’s name, and are served as data.

A routine has no model in it; it fetches, reshapes and proposes writes.

Not the other routines

Claude Code has a feature of the same name: a saved prompt that runs a full Claude session on your account, on a schedule, with your connectors. That is an agent; it reasons on every run and writes as you. Use it for a digest or a summary. A Foundation routine is deterministic code, runs inside Foundation, and writes as a courier.

Authoring

1. State the outcome, the destination entity, the schedule and the business definition to your coding agent.
2. The agent calls describe_routine_contract, reads the source’s API documentation, and saves a draft with save_routine_draft: the program, its config and schemas, the source allowlist and the credential it uses by name, the destinations, and fixtures.
3. It calls preview_routine. The preview runs the program with full validation and authorization against the live source or a fixture, shows coverage, counts and every proposed write, and commits nothing.
4. You confirm. The agent calls activate_routine with the revision, a cron expression and a timezone. Activation pins the revision; a later edit is a new draft and changes nothing until you activate it.
5. list_routine_attempts shows each run: outcome, coverage, counts and links to the writes. pause_routine stops it. A failed attempt emails the admins in plain words.

The example Meeting transcripts into a list walks it once.

What the program is

One entry point, run(ctx), receiving the validated config, the last committed checkpoint, and ctx.source(name).fetch(path), the only way out. It returns proposed writes and a new checkpoint. Every write carries a key, the record’s identity, so a re-run is a no-op and a changed source record is an update rather than a duplicate. Writes and checkpoint commit together, so a failure between them cannot happen.

What Foundation guarantees

• Credentials never enter the script. A revision names a credential; the proxy attaches it. No preview, attempt record or log carries one.
• Only allowlisted requests leave. Host, path and method per source, re-checked against the resolved address on every request and redirect.
• Bounded. Wall clock, CPU, memory, requests, bytes and writes per attempt; an attempt that exceeds one is stopped and recorded as such.
• Authorization is re-checked before every attempt and every commit: the routine is active, its courier is still in the workspace, its credentials are connected and each destination’s write rule still allows it.

A coding agent reads the numeric limits and the exact shapes from describe_routine_contract.