---
title: Routines
description: 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](/examples/meeting-transcripts)
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`.