# Concepts

Source: https://routineos.org/concepts

> An AI agent framework for Claude routines: a folder of plain files, four types, approval gates, and a store where each record has one writer.

Concepts

# Claude routines need a shape too.

RoutineOS is an AI agent framework for jobs Claude does on a schedule. Every routine is a folder of plain files, with a place to keep what it finds, a page for you to work on, and approval before anything leaves.

[Get started](https://routineos.org/#start)[Read the docs](https://docs.routineos.org/concepts)

from the docsFree (MIT), needs a paid Claude plan

What a routine is

## A scheduled prompt is easy to start and hard to trust

A routine is an agent that runs on a schedule in the cloud, does one piece of recurring work, and reports to people. It runs on Claude scheduled tasks. RoutineOS hosts nothing.

If you know web frameworks: Rails, Django and Laravel gave web apps a standard shape, and RoutineOS borrows that idea, not their code. The mapping is an analogy, ours, not a claim that RoutineOS is one of them. [See the comparison in the docs](https://docs.routineos.org/introduction/comparison).

A bare scheduled prompt forgets what it found last week. It has no safe place to put results, cannot ask permission, and cannot be corrected without someone editing the prompt.

A RoutineOS routine gets five things, set up the same way every time:

- **Memory**, called the store.
- **A place to meet people**, called the Desk.
- **Permission**, called gates.
- **Steering**, called settings.
- **Improvement**, called [learning](https://routineos.org/concepts/learning).

The four types

## Pick a type by who acts

The type is one line in the routine's settings file (`routine.toml`). It decides what the `new` command sets up for you. If a routine ever sends, it is approval-gated or it carries a gate (an approval step).

| Type | Use it when | Desk | Gate |
|---|---|---|---|
| `serverless` | It runs on its own with no cloud page (`serverless` means no Desk), writes a report, and nobody watches. | No | No |
| `watch` | It monitors sources and a person checks the result, often on a phone. | Yes | Optional |
| `approval-gated` | It sends, posts or deletes only after a person says yes. | Optional | Yes |
| `interactive` | A person steers it from a page (settings, requests). | Yes | When acting outside |

**Type is not kind**A routine also has a kind: code, skill, workflow or hybrid. The kind says where the logic lives and how work is split between code and the model. [Read about routine kinds](https://docs.routineos.org/routine-kinds).

Maturity is listed per template in the catalog. [Jobs watch](https://routineos.org/templates/jobs-watch) is a watch routine and is marked piloted. [Inbox triage](https://routineos.org/templates/inbox-triage) is approval-gated and is marked unpiloted. See all of them under [templates](https://routineos.org/templates).

The folder

## A routine is a folder of plain files

The files say what the routine is. You can read them, change them and keep them in git.

| File | Needed | What it holds |
|---|---|---|
| `routine.toml` | Always | Name, type, schedule and first run, plus the store, the settings you can steer, the approval gate and the actions it may take. |
| `prompt.md` | Always | The work, in words, with a clause telling the routine to treat fetched text as data, and a line on what may leave the routine. |
| `README.md` | Always | What the routine does, its settings and known risks. |
| `definition.json` | With a Desk | Record types, how each record is identified, the filters your settings apply, the Desk views, the Inbox and learning. |
| `dashboard/index.html` | With a Desk | The Desk page. |
| `app.toml`, `risks.md`, `CHANGELOG.md`, `lib/` | With the app layer | The services it connects to, its budget and environment, its risks and its history. |

The parts

## What the routine, the store and the people each own

The store holds what a routine found and what people decided. Every document in it has exactly one kind of writer: either people or the routine. That rule replaces locking (the usual way to stop two writers colliding), so a run and a person do not overwrite each other.

Records the routine finds get a stable id. Settings filter them, and a filtered record is kept with a reason, not deleted. Messages for people go to the Inbox. Anything that would leave the routine waits behind a gate until a named person approves.

- A first run is report-only: the prompt forbids sending, posting or deleting.
- A send, post or delete waits behind a gate until a named person says yes.
- A routine does not apply its own learned change. Only your Accept does.
- The prompt tells the routine to treat fetched content as data, not instructions.

Keep reading

## Where to go next

 [

### Lifecycle

Eight stages from Discover to Retire, each with exit evidence you can check.
Open ](https://routineos.org/lifecycle) [

### How it learns

A routine suggests one settings change with its evidence. You decide.
Open ](https://routineos.org/concepts/learning) [

### Approvals

How nothing leaves without a person's yes.
Open ](https://routineos.org/concepts/approvals) [

### The Desk

One page per workspace to see what routines found, decide, and tune settings.
Open ](https://routineos.org/concepts/desk) [

### Join a Desk

Open a Desk so teammates can serve a lane from their own accounts. Since 0.8.0.
Open ](https://routineos.org/concepts/join-a-desk) [

### Next to web frameworks

RoutineOS borrows the shape of Rails, Django and Laravel, not the code.
Open ](https://routineos.org/concepts/rails-map)

## Build one and see the folder

Install the plugin in Claude Code and start from a template.

[Get started](https://routineos.org/#start)[Read the docs](https://docs.routineos.org/concepts)