Cori
Getting started

Capture from an agent conversation

Turn a multi-step agent conversation into a deterministic, reusable Cori workflow — the core Cori workflow.

This is the wedge use case. You've just solved something with a coding agent — processed rows in a spreadsheet, translated a batch of files, validated a set of product records — and you want to run that same process again without re-involving an LLM every time.

With the Cori skill installed in your agent, you ask it to save the work as a workflow. Here's what happens.

Prerequisite: npx skills add cori-do/cori is done and the skill is active in your agent. See Install.

Finish the task you want to capture

Work with your coding agent to complete a multi-step task. For example, you might say:

"Read the rows from products.csv, translate the description column to French using an LLM, and write the results to a new fr_tab sheet."

The agent works through the problem: it calls tools, writes code, checks results, maybe backtracks. This is the design-time phase — the LLM is doing real thinking.

Ask the agent to save it as a Cori workflow

Once you're happy with the result, say:

"Save this as a Cori workflow."

The agent invokes the cori_save_workflow skill. It re-reads the conversation and distinguishes:

  • Productive actions — steps that belong in the workflow
  • Dead ends and retries — steps that led nowhere, excluded
  • Scaffolding — one-time setup, not included

The agent decides the workflow structure

For each productive step, the agent picks the right activity kind:

  • Did it run a CLI command? → cli step
  • Did it call an MCP tool? → mcp_tool step
  • Did it write pure computation? → code step
  • Did it call an LLM to classify, translate, or summarize something? → llm step

It also decides which inputs are parameters (things that will change next run, like input_file) versus constants (things that are always the same, like a target language).

The agent writes the workflow folder

The agent creates a folder like translate_product_sheets_fr/ containing:

translate_product_sheets_fr/
  manifest.md          # title, description, parameters, tools required
  types.ts             # shared Zod input/output types
  steps/
    01_read_source_rows.ts
    02_translate_rows.ts
    03_check_gpsr.ts
    04_ensure_fr_tab.ts
    05_write_results.ts
  tests/
    03_check_gpsr.test.ts

Most captured workflows have zero LLM steps at runtime. Only the step that genuinely needs to process new data each run (like translation) gets an llm step. Everything else is deterministic.

Review and approve before any disk write

The agent shows you the proposed workflow folder structure and key decisions before writing anything to disk. You review:

  • Are the parameters right? (Did it miss one? Over-parameterize?)
  • Is the step decomposition correct?
  • Are all required tools declared?

Approve, request changes, or cancel. Nothing is written until you approve.

The agent runs cori check

After writing the folder, the agent runs:

cori check ./translate_product_sheets_fr

This validates the manifest, compiles the step files, and verifies all required tools are declared. If it passes, the workflow is ready to run. The agent may then suggest:

cori run --dry-run ./translate_product_sheets_fr

Run it

cori run ./translate_product_sheets_fr input_file=products.csv

The LLM is no longer in the loop (except in the one translation step). The workflow executes deterministically from here on.

What just happened: The LLM did its reasoning work exactly once — at design time, in your conversation. From now on, the workflow executes without re-deriving the plan. Parameters change; the structure doesn't.

See the cookbook example for the full translate_product_sheets_fr workflow with all step files.

On this page