Pulse

Pulse is the automation layer in Dominir. It lets you define triggers — scheduled jobs or incoming webhooks — that run code and dispatch agents without a person initiating the run. The output of a Pulse run lands in your workspace as records, files, or notifications, exactly as if you had run the agent yourself.

Triggers

A trigger is a configuration stored in your workspace as a record. There are two kinds:

Scheduled triggers fire on a cron schedule. You define the schedule (every hour, every weekday at 9am, the first of each month) and the Kernel runs the trigger at the specified time. The trigger does not require a server-side cron daemon or external scheduler — the Kernel manages its own schedule internally.

Webhook triggers fire when an HTTP request arrives at a URL the Kernel provides for that trigger. The request body is passed directly to the trigger's logic as input. You can point any external system — a form submission, a CRM event, a payment processor notification — at a webhook trigger and the Kernel handles it.

What a trigger does

Every trigger can do some combination of two things: run code and dispatch agents.

Running code executes a small Python script inside the Kernel's notebook environment. This script receives the trigger's input payload and can read from the graph, transform data, and produce outputs that are passed to the next step. Use this to normalize incoming data, classify events, or compute values before an agent takes action.

Dispatching agents hands the result to one or more agents. The agents run with the same tools and clearance constraints as any other agent run — they can read records, write records, produce files, and request human approval for sensitive actions.

Dispatch modes

You can configure how code and agents are sequenced:

When neither mode nor agent assignments are set, the trigger defaults to code-only. When you add an agent but no code, it defaults to agent-only. The system infers a sensible default so you do not have to configure something you did not ask for.

Built-in Pulse agents

Three agents handle automated trigger work out of the box:

Pulse Updater is dispatched when the trigger's job is to update the graph — creating records, editing existing ones, or archiving stale ones based on the event payload. It reads before it writes and produces an audit artifact at the end of every run.

Pulse Notifier is dispatched when the trigger's job is to surface information to a person. It does not write records. It produces a concise, scannable artifact describing what happened and what (if anything) the recipient should do. If the event requires no human attention, it says so explicitly rather than staying silent.

Pulse Triage is dispatched when you do not know in advance whether an event needs a graph update, a notification, or both. It reads the incoming payload, decides what is needed, and routes to Updater and/or Notifier accordingly.

Runs and history

Every trigger fire creates a numbered run with a persistent record of what happened: the input payload, any code that executed, agent activity, files produced, and the final result. Runs are listed in chronological order in the Pulse interface and remain accessible for as long as you keep them.

A trigger with many runs does not slow down. The Kernel indexes runs efficiently and the run history does not accumulate in the active graph.

Testing a trigger

You can fire any trigger manually from the Pulse interface with a custom input payload. This creates a real run — the same code executes, the same agents are dispatched, and any records written are written to your actual workspace. Use the demo store to test behavior safely before connecting a trigger to live data.

What Pulse is not

Pulse is not a general workflow orchestrator. It handles event-to-action automation: something arrives or a schedule fires, and the Kernel responds. For longer-running, human-in-the-loop processes — intake procedures, case workup, multi-step reviews — use Workflows.