Automation & connectors

Everything a space does — create a node, approve a draft, send an email, invite an actor — is an operation. Operations are a declarative capability language: you name the thing you want done, and the platform handles permission, execution, and audit. The same operation is what a UI button triggers, what an API call invokes, and what an AI prompt resolves to. One verb, three front doors.

Operations are the unit of action

Every operation shares four guarantees:

Property	Meaning
Idempotent	Running it twice lands in the same state as once
Permission-checked	It runs only if the actor holds the right
Auditable	Every run is logged — who, what, when
Synchronous	It completes inline; no background queue to reconcile

There’s no event bus. An operation that needs to do three things does them in sequence, in one call. Flat and synchronous means you can read an operation top to bottom and know exactly what it did — and the audit log reads the same way. Debugging is following a line, not chasing a fan-out.

Three loop protections keep operations from triggering each other into a storm: a depth limit on nested calls, duplicate-detection at plan time, and the acyclic depth-gate the graph already enforces. Destructive operations (delete, wipe) require typed confirmation — the actor types the target’s name, the way GitHub makes you type a repo name before deleting it.

Operations are a versioned public contract, named verb.subject.vN — create.node.v1, approve.draft.v1. A new version can change behaviour without breaking callers pinned to the old one.

Connectors: bridges to the outside

A connector is how a space reaches an external service. They’re grouped into categories, and only one connector is active per category — so a space has exactly one email provider, one payment provider, one AI provider at a time:

AI · Email · Payments · Storage · Notifications · Authentication · Translation · Image

Each connector follows the same lifecycle:

install  →  configure  →  activate  →  deactivate

The one-per-category rule is what prevents vendor lock-in. Operations call the category (“send via Email”), not the vendor. Swap the email connector from one provider to another and every operation that sends mail keeps working — you changed the bridge, not the code that crosses it.

The wizard

The wizard is a space-level automation tool, structured as a three-stage pipeline:

bot       interprets the request, drafts a plan of operations
assessor  checks the plan: permissions, loop safety, destructiveness
executor  runs the approved plan, operation by operation

A request becomes a plan of operations before anything runs, the plan is assessed, and only then executed — so automation lands on the same audited, permission-checked operations as everything else.

AI is optional, not required

The wizard runs whether or not an AI connector is active. CtxrLLMClient is a pattern-engine — it resolves structured requests through deterministic rules with no model behind it. It’s a production feature, not a demo stub: a space with no AI budget still automates. Activate an AI connector and AnthropicLLMClient takes over the same interface, adding natural-language understanding. One entry point, graceful scaling.

Webhooks: same operations, new transport

An inbound webhook from an external service is just another way to reach the operation layer. The payload is mapped to an operation, the operation runs with the webhook actor’s permissions, and the result is audited like any other run. A webhook isn’t a side channel that bypasses the rules — it’s a different doorway into the same room.

That’s the shape of automation in CTXR: one operation layer, reached by button, API, AI, or webhook, every path audited and permission-checked the same way.