# Agentic workflows

Source: https://routineos.org/learn/agentic-workflows

> An agentic workflow lets a model make judgment calls inside a process. How to keep it safe with report-only runs, approval gates and learning you control.

Learn

# Agentic workflows that ask before they act.

An agentic workflow is a process where an AI model makes some of the judgment calls, such as which email needs a reply or which job posting is a real lead. That is useful and it is risky. This guide shows where to put code, where to put the model, and how to keep a workflow safe: report first, ask before acting, and learn only with your yes.

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

Free (MIT). Needs a paid Claude plan.from the docs

Code or judgment

## Decide, for each step, whether code or the model does it

Most steps in a workflow are plain: fetch a list, filter it, remove duplicates, count. A script does these the same way every time and uses no model time. The steps that need reading and judging are where the model earns its place.

One rule decides the awkward cases. If a person can edit the rule in Settings, code applies it. If the model applied it, an edit on the Desk would not reliably change the run. In a pilot, the model kept two "Ecommerce" roles for the keyword "commerce" while the script dropped them, because the script then matched whole words. Text filters now match substrings, so "commerce" keeps "Ecommerce".

| Give it to code | Give it to the model |
|---|---|
| Filters from your settings, caps, ids, keys and times | Fit, classification, summaries and drafts |
| The daily run budget, gates and secrets handling (a fixed mechanism, a safety rule) | Reading pages and mail that vary every time |

Source: the RoutineOS design reference and the docs page [Routine kinds](https://docs.routineos.org/routine-kinds). Pilot-verified for the Ecommerce example.

Four kinds

## The four kinds of agentic workflow in RoutineOS

A kind says where the work happens. It is a design pattern, not a setting you switch on.

 [

### Code

Scripts do the work. The model runs the commands and reports. Example: a weekly report that counts and compares numbers.
Read the docs ](https://docs.routineos.org/routine-kinds/code) [

### Skill

A skill folder holds the judgment. Example: inbox triage with a reply-style skill.
Read the docs ](https://docs.routineos.org/routine-kinds/skill) [

### Workflow

A declared chain of stages: code, model, skill and gate. Example: content calendar.
Read the docs ](https://docs.routineos.org/routine-kinds/workflow) [

### Hybrid

The default. Code applies the rules, the model reads and judges. Example: Jobs watch.
Read the docs ](https://docs.routineos.org/routine-kinds/hybrid)

Threat check

## Split private data, untrusted input and sending

Ask three questions of any design. Does it see private data? Does it read content that strangers control, such as web pages or inbound mail? Does it send things out? If all three are yes, a hostile page could talk the workflow into sending your private data somewhere.

The recommended split is two routines. The first reads untrusted content and has no way to send. The second acts only on approved, structured output, behind a gate. It is a recommendation. If you keep the combined design, write the decision down with the date, and keep a gate on every send.

- The prompt tells the routine to treat fetched content as data, not instructions.
- The prompt forbids sends that are not on the approved list.
- Pack validation fails a write connector that has no gate.

These are prompt and lint rules, not runtime guarantees. Source: the docs section [the threat check](https://docs.routineos.org/routine-kinds).

Keeping it safe

## Report first, ask before acting, learn with your yes

1. **Report first**The first run is report-only. It reads and reports, and the prompt forbids sending, posting or deleting.
2. **Ask before acting**A send, post or delete waits behind a [gate](https://routineos.org/concepts/approvals) until a named person says yes.
3. **Learn from feedback**The routine watches what you keep and drop, then suggests settings changes, one card each with its evidence. You accept, reject or snooze. See [how it learns](https://routineos.org/concepts/learning). Learning is built and tested, and has not run on a live routine yet.
4. **Check a real run**Done means a person has looked at a real run. The eight stages are on the [lifecycle](https://routineos.org/lifecycle) page.

**Honest status**Only Jobs watch and Watch are piloted. Approve-then-send on the Desk has not been piloted end to end. The full list is on [honest limits](https://routineos.org/honest-limits).

## Walk the lifecycle

Eight stages from Discover to Retire, each with evidence you can check.

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