# Caelion

> Headless agentic CRM. The CRM with no screen to log into. Caelion is a CRM you never have to open. State comes in through connectors, agents react, records write themselves. The interface is optional.

Status: in development. Early access open at https://caelion.app/early-access/
Site: https://caelion.app (also caelion.pro, caelioncrm.com)
Contact: hello@caelion.app

## The model

### 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.

```yaml
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 }}" }
```

### 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.

```yaml
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 ]
```

### 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.

```yaml
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
```

## Connectors

Anything that can emit or accept state is a connector. The list below is where we started, not where it stops.

**Signal in:** Webhooks (Any HTTP source. Stripe, Calendly, your own app); YAML and JSON files (Drop a file in a watched path. Caelion reads it as state); API publish (POST a document. The schema is yours; the foundry maps it); Semantic search (A saved query that matches new material is a catalyst); Email and calendar (Google Workspace and Microsoft 365, read and write); Meeting transcripts (Zoom, Meet, Teams and Fireflies-style feeds); Forms and chat (Website forms, Intercom, Slack channels); Databases (Postgres, MySQL and BigQuery tables as live sources).

**Action out:** Email send (Drafted by an agent, approved by you or not, your choice); Slack and Teams (Reactions post where the team already is); Webhooks out (Every state change can call any URL); Documents (Proposals, QBR decks and summaries, generated and filed); Task systems (Linear, Jira, Asana, Notion); Billing (Stripe and Chargebee objects created from won deals).

**Both ways:** MCP (Caelion is an MCP server. Your assistant of choice reads and writes state); REST and GraphQL (The whole model, every field, no hidden UI-only data); Warehouse sync (Snowflake and BigQuery, bidirectional); Other CRMs (Run Caelion beside Salesforce or HubSpot while you migrate, or forever); Files (S3, Drive, SharePoint. State goes out as YAML; edits come back as catalysts); Your code (SDKs in TypeScript and Python. A foundry is a function if you want it to be).

## Caelion versus dashboard CRMs

Lightfield, Attio, HubSpot and the rest ship a screen first and bolt agents onto it. Caelion is the other way round: the agents and the state are the product, and a screen is one of several clients you may or may not want.

- **Where the truth lives.** Dashboard CRMs: In a database behind a UI. Agents get an API to it. Caelion: In a state ledger. Agents subscribe to it directly. The UI reads the same ledger you do.
- **How data gets in.** Dashboard CRMs: People type. Some integrations sync fields. Caelion: Catalysts. Files, webhooks, searches, transcripts, publishes. Typing is allowed but never required.
- **What “automation” means.** Dashboard CRMs: Rules: if field X changes, do Y. Caelion: Reactions: agents with judgment, subscribed to state, publishing back through connectors.
- **What you have to open.** Dashboard CRMs: The app. Every day. Caelion: Nothing. Ask in Slack, in your assistant, in the terminal, or open the console when you feel like it.
- **The schema.** Dashboard CRMs: Theirs, with custom fields. Caelion: Yours. Foundries map any shape onto the model; the model extends in YAML.
- **Where it runs.** Dashboard CRMs: Their cloud. Caelion: Ours, or yours. The engine is a single deployable with Postgres behind it.

## API surface

Everything the console can do, the API can do, because the console is just a client. Publish state, declare foundries and reactions in YAML, subscribe to changes, and read the whole model back.

- `POST /v1/publish`: Send any document. Foundries decide what it becomes.
- `GET /v1/state/{entity}/{id}`: Read a record with its full history and provenance.
- `GET /v1/search?q=`: Semantic search across every record and document.
- `PUT /v1/foundries/{name}`: Declare or update a foundry from YAML.
- `PUT /v1/reactions/{name}`: Declare or update a reaction from YAML.
- `GET /v1/subscribe`: Server-sent events for every state change, filterable.
- `MCP`: mcp.caelion.app exposes the same surface to any MCP client.

## Questions

**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.

## Pages

- [Home](https://caelion.app/): Caelion is a CRM you never have to open. State comes in through connectors, agents react, records write themselves. The interface is optional.
- [How it works](https://caelion.app/how-it-works/): The whole Caelion model in three nouns. Catalysts change state, foundries forge records from signal, reactions are agents that act on state and publish back out.
- [Connectors](https://caelion.app/connectors/): Webhooks, YAML and JSON files, API publishes, semantic search, email, transcripts, databases, MCP. Connectors are a core primitive of Caelion, in both directions.
- [Console](https://caelion.app/console/): When you want a screen, Caelion talks back like an assistant, not a dashboard. Ask questions, approve reactions, open records. Or never open it at all.
- [Compare](https://caelion.app/compare/): Dashboard CRMs added agents to a screen. Caelion started from agents and state and made the screen optional. Here is the difference, row by row.
- [Developers](https://caelion.app/developers/): Publish state, declare foundries and reactions in YAML, subscribe to changes, read the whole model back. REST, SSE, MCP and SDKs. The API is the product.
- [Company](https://caelion.app/company/): Caelion is built and operated by Vervelio, a Detroit-born software firm that ships its own AI-first SaaS products. Caelion is one of them.
- [Early access](https://caelion.app/early-access/): Caelion is in development. Tell us how your team works and what should react to what, and we will build with you.