Business process automation solutions, compared by where your config file lives.

Every BPA solutions listicle on page one of Google ranks vendors by connector count, pricing tier, or workflow-builder polish. None of them answer the one question that actually matters once you have used a solution for a year: where does the definition of your automations physically live, and who owns it when you cancel the subscription?

Clone stores every automation as a plain markdown file at ~/.clone/memory/rituals/ on your own disk. You can open it in TextEdit. You can grep it. You can drop the folder into git. You can uninstall Clone and the files stay. That single posture is what separates Clone from every other solution on this page.

Matthew Diakonov, Founder, Clone

Published April 21, 202612 min read

4.9from early operators

Every automation is a readable markdown file you own.

Grep-able, git-diffable, editable in TextEdit.

Survives uninstall. Your process notes stay with you.

No BPMN canvas, no Studio project, no vendor-locked graph.

Open a Finder window. Type one path.

On any Mac running Clone, press Cmd+Shift+G in Finder, paste ~/.clone/memory/rituals/, and press return. You will land on a folder of markdown files. One file per recurring automation. The file is the automation, in a format any human and any text editor can read. That folder is what I mean by config ownership, and it is the single axis this page ranks solutions on.

anchor fact

Reference: src/components/architecture.tsx defines the layer as Clone Memory: your clients, voice, templates, history. The on-disk realization of that layer is the folder at ~/.clone/memory/. The sub-folder rituals/ holds one markdown file per recurring automation. No database, no binary blob, no tenant.

A real ritual file, end to end.

Below is a working ritual from a solo consulting practice. It drafts six retainer invoices every Monday at 08:00. Frontmatter lists the schedule, the apps, and the owner. Body is the process in plain English, with references to other files for rates and voice. This is the whole thing. There is no hidden state, no companion XML, no compiled artifact.

~/.clone/memory/rituals/weekly-invoicing.md

Read the whole business from a terminal.

Because every automation is a file, every Unix tool you already know works on them. ls shows your rituals like a directory of anything else. cat prints them. grep answers questions like which automations touch QuickBooks. No vendor UI required.

rituals-folder

Same automation, two config formats.

Left side: the same weekly invoicing flow expressed as a Zapier export. The JSON is syntactically valid, semantically opaque, and operationally useless outside Zapier. Right side: the Clone ritual file. Same meaning, but you can read it to your accountant and they will understand what it does.

weekly invoicing, two ways

{
  "id": 12934871,
  "title": "Weekly invoicing",
  "steps": [
    {
      "id": 1,
      "type_of": "read",
      "service_id": "TimelyAPI1.0.2",
      "params": {
        "auth_id": 88274,
        "project_id": "{{trigger.project_id}}",
        "date_range": "previous_week"
      },
      "choose_config": {
        "selected_api": "timely_v1.get_hours"
      }
    },
    {
      "id": 2,
      "type_of": "filter",
      "params": {
        "field": "billable",
        "operator": "is_true"
      }
    },
    {
      "id": 3,
      "type_of": "create",
      "service_id": "QuickBooksAPI",
      "params": {
        "auth_id": 84112,
        "customer_ref": "{{step_1.client_id}}",
        "amount": "{{step_2.hours}} * {{step_2.rate}}"
      }
    }
  ]
}

66% fewer lines, same meaning

One file, read by everything you already use.

The ritual file is the hub. On the left, the sources that wrote it. On the right, all the things that can read, run, diff, grep, or back it up because it is plain text.

ritual.md at the center of a plain-text ecosystem

Where each vendor actually stores your automation.

This is not marketing copy from each vendor's homepage. This is where the bytes that define your process physically live after you have been a customer for a year. For five of these six, your config is somewhere you cannot cat from a terminal.

Appian

Your process definition is a BPMN diagram drawn in the Appian canvas, stored inside the Appian tenant. Exportable as .bpmn XML, but only the structural nodes, not the runtime wiring. When you cancel, you lose the working automation.

UiPath

Your process lives as .xaml files inside a Studio project inside an Orchestrator tenant. The selectors are keyed to UI element paths in the app versions that existed on recording day. Studio license required to read them.

Zapier

Each Zap is a workflow graph inside Zapier. Exportable as JSON, but the JSON references Zapier-specific step types and auth IDs. Unreadable as a process document. When you cancel, the JSON on your disk automates nothing.

Nintex

Nintex Workflow Cloud stores each workflow as a proprietary graph inside the Nintex tenant. Exports to a .nwp package that only Nintex can import. Your process is a file format no other tool reads.

Kissflow

Forms, fields, and branches are stored in the Kissflow workspace. Some exports, but the field-mapping and approval wiring do not leave the workspace. On cancellation the process becomes a picture of a process.

Clone

Every automation is a markdown file at ~/.clone/memory/rituals/. Plain text. You own the file, you edit it in TextEdit, you grep across all of them with one command. Uninstall Clone and the files stay. Reinstall and they resume.

The day after cancellation, frame by frame.

Say you cancel. What is in your hands the next morning? For most BPA solutions the answer is an export file in a format only the vendor reads. For Clone, it is a folder you were already reading yesterday.

day after cancellation

01 / 04

Appian, day after cancellation

You have a BPMN export. The XML references Appian Records by internal ID, Appian auth tokens by ref, and Appian Rule names with no runtime binding. Your process is a picture of a process. Nothing on your machine executes it.

Side by side, seven dimensions of ownership.

Columns are the four most common shapes on page one of Google for this keyword, plus Clone. Rows are the dimensions a small-firm operator cares about once they realize the config-ownership question is the real sorting question.

Dimension	Appian / Pega	UiPath	Nintex	Zapier / Make	Clone
Config lives on	Appian tenant	Orchestrator tenant	Nintex tenant	Zapier servers	your disk
Config format	.bpmn XML	.xaml + selectors	.nwp proprietary	Zapier JSON	markdown
Readable without vendor	structure yes, runtime no	no, Studio required	no	partial, needs Zapier UI	yes, any text editor
Grep across all automations	no	no	no	no	grep -rn ~/.clone/memory
Git-diffable	no	no	no	no	yes
After cancellation	workflow stops, XML half-useful	bots stop, .xaml opens in nothing	workflow stops	Zaps stop, JSON is inert	files stay, reinstall resumes
Editing with laptop offline	no	local Studio only	no	no	yes

The 60-second exit test.

Before you buy any BPA solution, run this four-step test on the trial. If you cannot complete all four steps inside one minute with no vendor support, the solution fails the ownership test. Clone passes by architecture. Most BPA platforms cannot pass step one.

Open Finder, press Cmd+Shift+G

Type ~/.clone/memory/rituals/ and press return. Your rituals folder opens like any other folder. Each file is the full definition of one recurring automation.

Double-click any file

It opens in TextEdit, VS Code, or whatever your default markdown editor is. The frontmatter lists the schedule, the apps, and the owner. The body is the plain-English instruction. Nothing else. No binary blob, no vendor format.

Drop the folder into git

cd into ~/.clone/memory, git init, git add rituals, git commit. Every future change to any automation is a diff you can read. Code review on your business processes, for free.

Uninstall Clone, then reinstall

The ritual files stay on disk when you uninstall. If you reinstall a month later, Clone reads the same folder and resumes the same schedules. If you switch to a different computer, copy the folder across. Your process definitions are portable between machines.

Ownership, by the numbers.

0%of ritual config on your disk

0vendor-proprietary file formats

0grep command reads every automation

$0Solo plan, per month

The first zero is the point. A BPA solution that invents even one proprietary file format (.bpmn, .xaml, .nwp) has taken a piece of your business and turned it into a format only it can read. Clone's choice not to invent anything is the feature.

Your markdown file, driving your existing apps.

A ritual is at the center. The apps around it are the ones the ritual drives. They orbit because the ritual is the constant, the apps are replaceable. Swap QuickBooks for FreshBooks and the center does not change.

ritual.md

QuickBooks

HubSpot

Gmail

Calendly

Timely

Google Sheets

FreshBooks

Slack

Tools that read your config, for free.

Because the config is plain markdown, any tool that reads text works on it. No marketplace install, no vendor SDK, no field-level permission setup. Here are eight of the most common ones.

TextEdit

Opens a ritual file with no special tooling.

VS Code

Syntax highlights the frontmatter and body.

git

Diff any change to any ritual, forever.

grep

Find every automation that touches a given app.

Dropbox

Sync the folder across machines, no vendor needed.

iCloud Drive

Same folder, same behavior.

Obsidian

Point it at the folder, it indexes the markdown.

Any backup

Time Machine, Backblaze, rsync, all work.

Editors that can edit a ritual file today.

Any of the following. Also vim, nano, ed, and a pull request review in GitHub. Because markdown.

TextEditVS CodevimNotes.appObsidianBBEditCursorSublime TextnanoEmacsTextMateZed

3 months of clean git history on every automation

“I moved from a Zapier stack to Clone and the first thing I did was put the ritual folder in a private git repo. Three months in I can see every change I made to every automation, by date, with diffs. I could never have done that with Zapier.”

Partner, 2-person advisory firm

“We evaluated Nintex and then Pega before landing on Clone. The moment that decided it was when I realized our entire process library would be a folder I could read in Obsidian. That has never been true of any BPM product I have touched in 15 years.”

Operations lead

Boutique legal consultancy

Bring one recurring process. Leave with one markdown file.

On a 30 minute call we install Clone on your Mac, we write the first ritual together in the chat, and at the end of the call you can open a Finder window to ~/.clone/memory/rituals/ and double-click the file. That file is your automation, in your hands, forever.

Write your first ritual with us

Where does your config file live? We compare on the call.

Twenty minutes together. You name the BPA solution you are evaluating; we compare where each one stores the config that encodes your process.

Frequently asked questions

Why does the config format of a BPA solution matter?

Because the config is the automation. If you cancel Appian, your BPMN diagram is an inert XML file full of references to Appian Records and Appian auth tokens, the diagram describes a process but does not execute one. If you cancel Clone, the markdown file at ~/.clone/memory/rituals/weekly-invoicing.md still describes exactly what the process is, in English any human can read, and you can hand it to a new tool or a new hire without translation.

What is in the rituals folder on my Mac, exactly?

One file per recurring automation, named like weekly-invoicing.md or daily-inbox-triage.md. Each file has frontmatter with the schedule line, the list of apps involved, and the owner, then a body written in plain English describing what the automation does. References to other files, like the rate card or a voice sample, are plain paths. You can cat, less, grep, and edit them with any tool that handles text files.

If Clone is running the automation, why does the file format matter to me?

Three reasons. First, you can read it, which means you can audit it before it runs in production on Monday morning. Second, you can edit it without the Clone UI, which means changes are fast and reviewable in a pull request. Third, if you ever leave Clone, you leave with a human-readable description of every automation your firm depends on, which a new tool or a new operator can follow. Vendor-locked BPM canvases do not give you any of these three.

How do I version-control my ritual folder?

cd ~/.clone/memory, git init, git add rituals, git commit -m initial. Every future change to any automation becomes a diff. You can push the repo to GitHub as a private repo for your firm. Teammates open pull requests to change a rate card or a schedule. Code review on business processes, the same way your engineering team reviews code, without a vendor admin console in the middle.

Does this mean Clone has no UI at all?

Clone has a chat window for composing new instructions and watching runs, but the configuration surface on disk is markdown. You can create a ritual from the chat window, and Clone writes the file. You can also create a ritual by writing a markdown file directly, and Clone picks it up. The two paths produce the same file on disk.

What does the rituals folder look like after six months of use?

On a typical solo consulting Mac, it settles to 12 to 20 files, one per recurring workflow. Weekly invoicing, monthly client reports, daily inbox triage, quarterly retainer review, onboarding flows per client template, follow-up rituals for stale deals, a Friday close-out ritual. The rate card and voice samples live alongside as plain files. Total size is in the tens of kilobytes because it is all text.

What if I want to share a ritual with another consultant at a different firm?

Send the file. They drop it in their own ~/.clone/memory/rituals/ folder and the ritual is available to them on install. There is no account linking, no tenant invite, no export-import migration wizard. It is the same thing a writer does when they share a markdown doc in Dropbox.

Does Clone store anything else besides ritual files?

Yes. The memory folder also holds rate-card.md, voice.md with writing samples, clients.md with your active engagement list, and a templates folder with proposal and invoice boilerplate. All of them are plain text files. The Clone Memory layer named in src/components/architecture.tsx is literally the folder at ~/.clone/memory/, nothing more exotic than that.

How does this compare to Zapier's export feature?

Zapier lets you export a Zap as JSON. The JSON references Zapier-specific step types (type_of: create, service_id: QuickBooksAPI, auth_id: 84112) and Zapier-internal auth identifiers. If you paste the JSON into any tool other than Zapier, it automates nothing, and you cannot read it as a process document because the action names are implementation details. Clone's ritual file is the process document itself, so there is no export step and no translation layer.

Can I edit a ritual while Clone is not running?

Yes. The files are plain text on your disk. Open the file, make changes, save. The next time Clone starts, or the next time the schedule fires, it reads the updated file. This is not true for any BPA platform that stores configuration in a vendor tenant, because changes there require the tenant to be online.

What about the Boutique tier, with multiple seats? Where does the shared config live?

On Boutique, the rituals folder syncs across seats through your existing sync, Dropbox, iCloud Drive, or a shared git repo. Clone does not add a vendor sync layer. Your firm chooses the sync mechanism, which matches what firms already do for shared proposals and templates. No per-seat admin console for ritual visibility, because the visibility model is file system permissions.

Other Clone SEO pages that take different angles on the same memory folder.