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
| Object | Owns | Belongs to |
|---|---|---|
| Organization | Billing-level identity and membership (owner, admin, member). | A user |
| Project | Routines, runs, connections, and API keys. | Organization |
| Routine | Instructions, model, schedule, variables, limits, webhook settings. | Project |
| Connection | An MCP server URL plus encrypted authentication metadata. | Project |
| Run | One 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 the durable SQLite-backed 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, both in time:
by idleTimeoutSeconds (60–1800) — how long it may go without recording a
progress event — and by timeoutSeconds (30–3600), the absolute wall-clock
deadline. Whichever binds first ends the run as timed_out, classified
idle_timeout or timeout. There is no model-step cap: a run that keeps
making progress keeps running until its deadline.
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.