How Work on Repeat works

The objects, the execution path, and where each guarantee actually comes from.

Work on Repeat is small on purpose. Five objects and one execution path explain almost all of its behaviour.

The objects

ObjectOwnsBelongs to
OrganizationBilling-level identity and membership (owner, admin, member).A user
ProjectRoutines, runs, connections, and API keys.Organization
RoutineInstructions, model, schedule, variables, limits, webhook settings.Project
ConnectionAn MCP server URL plus encrypted authentication metadata.Project
RunOne execution, its steps, usage, error, and webhook deliveries.Project

A tool policy sits between a routine and a connection: it is the explicit record of which tools that routine may call, and which may run automatically.

What happens when a routine runs

A run is queued

Either you pressed Run now, your code called POST /v1/routines/:id/run, or the scheduler found the routine due. All three produce the same kind of run; only trigger differs — manual, api, or schedule.

A worker claims it

Runs live in a durable Postgres queue. A worker claims the next available run atomically, which is why overlapping scheduler ticks never execute the same run twice.

Instructions are rendered

{{placeholders}} in the instructions are replaced with the routine's variables. See Variables for the exact rules.

Tools are assembled

Only tools that are enabled for this routine are presented to the model, and each is exposed as <connection-slug>__<tool-name>. Credentials are resolved server-side at call time; the model never sees a token, a header, or a URL.

The model runs, bounded

Inference goes through LLMGateway. The run is bounded twice: by maxSteps (1–25 model steps) and by timeoutSeconds (30–1200). Whichever binds first ends the run — as step_limit or timed_out.

Everything is persisted

Each model step, tool call, tool result, and error is written with its duration, token usage, and redacted input and output. The final result is stored on the run, truncated at 100,000 characters.

Webhooks are queued, then delivered

If the routine has a webhook URL, a delivery row is written before anything is sent. The same one-minute operations tick that claims due routines also claims due deliveries and retries them.

Where the guarantees come from

Deployment shape

The service is four workspace apps:

See Deployment for the environment contract and release order.

On this page

Edit this page on GitHub