HOW IT WORKS
Three nouns.
That is the whole model.
Caelion has no concept of a form, a view or a pipeline stage you drag things across. It has state, and three kinds of thing that touch state.
- 01
Catalyst
Anything that changes state.
A webhook. A YAML file dropped in a watched folder. A JSON document published to the API. A semantic search that suddenly matches. A calendar invite, a transcript, a paid invoice. If it carries signal, it is a catalyst, and Caelion treats every one of them the same way: state changed, agents wake up.
kind: catalyst name: invoice-paid on: source: stripe event: invoice.paid emit: entity: deal match: { external_id: "{{ data.subscription }}" } set: { stage: won, closed_at: "{{ created }}" } - 02
Foundry
Where raw signal becomes CRM state.
A foundry is a typed pipeline you declare, not a form you fill in. It takes whatever a catalyst brought, resolves it against what Caelion already knows, and forges records: accounts, people, deals, commitments, documents. Matching, enrichment, deduplication and history all happen here, on every signal, without anyone typing.
kind: foundry name: deals-from-calls input: transcript steps: - resolve: { account: by_domain, contacts: by_email_or_name } - extract: [ commitments, next_steps, objections, budget ] - forge: deal: { stage: from(next_steps), amount: from(budget) } commitments: each -> commitment - link: [ transcript -> deal ] - 03
Reaction
What agents do when the state moves.
Reactions are the agents. They subscribe to state, not to a screen. A deal goes quiet: an agent researches the account and drafts the nudge. A commitment lands: an agent books the follow-up. A record contradicts a source: an agent flags it and asks you. Every reaction publishes back out through the same connectors that fed it, so the loop closes without a human in the middle unless you want one there.
kind: reaction name: quiet-deal-nudge when: entity: deal condition: stage in [proposal, negotiation] and idle > 9d agent: seller do: - research: account.recent_news - draft: { channel: email, to: deal.champion, tone: direct } - require_approval: owner - publish: gmail
THE LOOP
Reactions publish through connectors. Connectors deliver catalysts. Round it goes.
An agent sends an email. The reply comes back as a catalyst. A foundry reads the commitment in it. Another reaction books the meeting. Nobody opened anything.
QUESTIONS
Asked before, answered once.
- Is there really no UI?
- There is an optional console, and it is good. But every capability exists in the API first, and the console is one client of it. You can run Caelion for a year and never open it.
- What does "state driven" mean here?
- Every record is state with history. Agents do not poll a screen or run on a schedule by default; they subscribe to state and react when it changes. A foundry writes state, a reaction reads it, and the ledger is the single source of truth for both.
- What are catalysts, foundries and reactions?
- Catalysts are anything that changes state. Foundries are declared pipelines that turn a catalyst into CRM records. Reactions are the agents that act on state and publish back out. That is the whole model.
- Which connectors are supported?
- Connectors are a core primitive, not a marketplace. Webhooks, YAML and JSON files, API publishes, semantic search, email, calendar, transcripts, databases, MCP and SDKs are in from the start, in both directions where that makes sense.
- Can agents act without approval?
- Yes, where you say so. Every reaction declares whether it requires approval, from whom, and for what. The default for anything that leaves the building is approval required.
- Is Caelion available today?
- Caelion is in development. Early access is open for teams who want to shape it, and the API surface documented here is the surface being built.
EARLY ACCESS
Build it with us.
If you can describe what should react to what, you can run Caelion.
