Work on Repeat
Menu
AI routines as a service

Put recurring work on repeat.

AI routines run your audits, content, social publishing, and business reports on schedule—using the models and tools you already trust.

Put your first routine to workExplore example routines
Routine rhythm
MON
TUE
WED
THU
FRI

Next responsibility

Weekly security audit

Reads approved sources. Records every step. Returns a reviewable result.

The service

The work is the unit. Not the workflow.

Define a responsibility once. Give it a schedule, a model, approved tools, and clear limits. Each occurrence becomes an inspectable run.

Routines

Weekly security audit

Active

Every Monday · 09:00

SEO and AI-SEO audit

Active

Every Monday · 10:00

Revenue report

Draft

First day of each quarter

Latest run

Weekly security audit

Succeeded
  1. Run startedmanual trigger
  2. Model step completedbounded inference
  3. Repository readapproved MCP tool
  4. Result savedsigned delivery ready

Saved result

Findings are prioritized with evidence and next actions. The complete model and tool trace remains attached to the run.

Example routines

Start with work you already repeat.

Choose a proven responsibility, then adapt the instructions, cadence, model, inputs, and permissions to your business.
ROUTINE / 01

Weekly security audit

Review a codebase and its exposed surface for new security risks every week.

ROUTINE / 02

Weekly SEO and AI-SEO audit

Find search and answer-engine opportunities, then prepare a reviewable GitHub change.

ROUTINE / 03

Blog research and drafting

Research a useful topic and prepare a publication-ready draft on a recurring cadence.

ROUTINE / 04

Social creation and publishing

Turn current business context into channel-specific social posts through Zernio MCP.

ROUTINE / 05

Quarterly revenue report

Read Stripe data and explain the quarter’s revenue movement, risks, and follow-ups.

ROUTINE / 06

Weekly or monthly analytics report

Turn PostHog product data into a recurring, decision-oriented operating report.

How it works

Responsibility in. Reviewable result out.

No blank canvas and no branching diagram to maintain. The setup stays close to the work: instructions, inputs, tools, limits, and schedule.
  1. Step 01

    Choose the work

    Describe the responsibility, supply its inputs, and choose the model that fits it.

  2. Step 02

    Connect the tools

    Add MCP connections. Every discovered tool starts off until you explicitly approve it.

  3. Step 03

    Set the rhythm

    Run once, inspect the trace, then activate the timezone-aware schedule.

Model choice

One gateway. The right model for each routine.

The live LLMGateway directory is the source of truth. Pick a model per routine, change it without rebuilding the workflow, or use a routed model ID when you want gateway-level selection.
Model directory
Provider-prefixed modelprecise control
Gateway-routed modelrouting policy
Per-routine selectionchange anytime

Provider credentials never come from the browser. All inference runs through the configured LLMGateway account.

GitHub MCP

Tool policy

read_repositoryAllowed
search_codeAllowed
create_pull_requestNeeds explicit confirmation

Tool control

Access is explicit. The trace is permanent.

MCP tools are discovered, never presumed. They begin disabled, write capability is called out, and only the allowlist for that routine reaches the model. Inputs, outputs, timing, and errors stay attached to each run.

Developer surface

The same routine service, over a typed API.

Create revocable keys, trigger runs from your own systems, and receive timestamped HMAC-signed result webhooks. The dashboard and API share the same tenant and execution boundaries.
DevelopersRead the docs
Trigger a run
curl -X POST \
  https://api.workonrepeat.com/v1/routines/{id}/run \
  -H "Authorization: Bearer wor_••••••••"
→ queued / request id attached

Security by boundary

Credentials stay server-side. Capability stays explicit.

Encrypted connection headers, hash-only API keys, tenant-scoped persistence, bounded execution, redacted traces, and signed delivery are part of the foundation—not a marketing layer.

Review security

Questions

Know what runs. Know what it can do.

The service is designed around clear boundaries rather than vague autonomy claims.
What exactly is an AI routine?

A routine owns a recurring responsibility. It combines instructions, validated inputs, a model, a timezone-aware schedule, execution limits, approved MCP tools, and optional result delivery.

Can different routines use different models?

Yes. Each routine chooses from the current LLMGateway directory. Model inference stays behind one gateway boundary rather than being wired directly to individual providers.

How are connected tools controlled?

Every discovered MCP tool starts disabled. You decide which routine can call which tool, and write-like capabilities require deliberate confirmation before automatic execution.

What happens when delivery fails?

The run keeps its terminal state and error category. Delivery attempts are tracked independently, so an exhausted webhook never rewrites a successful run as failed.

Your first occurrence starts here

Give recurring work a place to run.

Put your first routine to work