How automations work
Execution model, reliability, and operational guarantees behind automation runs.
Lightfield automations run on a durable execution engine built for reliability at scale. This page covers how runs execute and recover, at a high level, for teams evaluating Lightfield’s reliability and operational behavior.
Runs, steps, and the run thread
Section titled “Runs, steps, and the run thread”- One trigger starts one run. Multiple trigger types can feed the same automation; each enters the same step sequence.
- Each run executes one immutable version of the automation and produces a run thread: the record of what each step did.
- Steps run in sequence on that shared run thread, so context passes between them automatically, with no manual wiring.
A single step can involve many actions behind the scenes; that all counts as one step. Steps are durable: if a run is interrupted partway through, it resumes where it left off instead of starting over.
Runs execute to completion without interruption. You can’t approve or redirect actions mid-run; human-in-the-loop happens afterward through For review.
Durable execution
Section titled “Durable execution”Automation steps can take a long time. An agent reasoning over a complex payload might run for 60 seconds; an external call might take 30. Lightfield’s execution engine is designed around this reality.
Slow work (external calls, AI execution) is separated from fast work (state updates, scheduling the next step). The engine stays responsive regardless of how long individual steps take, and no step blocks another from making progress.
Each step’s side effects are idempotent. If a step is retried after a transient failure, it produces the same result without duplicating records or sending duplicate requests.
Event processing
Section titled “Event processing”When a trigger fires (webhook received, record changed, schedule ticks), the event is captured atomically. Events are never lost, even if the system crashes immediately after the trigger.
A sharded background processor dispatches events to runs. Sharding ensures that a single high-volume automation can’t starve others. Each event is processed with a scoped idempotency key, so replaying events after a failure never creates duplicate runs.
For event (record) triggers, matching is precise. If a trigger watches the stage and amount fields on an opportunity and an update only changes the description field, the trigger doesn’t fire. This filtering happens before a run ever starts.
Identity and isolation
Section titled “Identity and isolation”Each run’s identity (its run-as actor) is resolved once, at run start, and never re-resolved, so editing the automation later can’t retroactively change who could see a historical run. Every step in the run executes under that identity, and run visibility follows from it: workspace-user runs are visible to eligible workspace members; specific-user runs are visible only to that user and workspace admins.
Each step is limited to its declared permission set. Any tool, connector, API, or CLI call outside that set is blocked and recorded as a policy violation.
Reliability guarantees
Section titled “Reliability guarantees”| Guarantee | How |
|---|---|
| Events are never lost | Trigger events are captured atomically with the originating change |
| No duplicate runs | Scoped idempotency keys on every event |
| Safe to edit active automations | Immutable version snapshots; running runs are pinned to their start version |
| Stable run identity | Run-as actor and inputs are resolved once at run start and never re-derived |
| Automatic recovery | Interrupted runs resume from a durable checkpoint |
Error handling
Section titled “Error handling”A step is monitored for completion and may be marked failed if errors are detected. When a step fails terminally, the run fails and no later steps run. The failed step retains the error and any results up to the point of failure, so the run thread shows exactly what happened.
Infrastructure interruptions (a worker restarting mid-step) are handled separately from logical failures: the run resumes from its checkpoint rather than counting as a failure.
Observability
Section titled “Observability”Every run produces a browsable run thread: a record of each step’s input, actions, and output. From the run details page (or from chat), you and the agent can inspect a run together: status, duration, trigger metadata, per-step transcript, and any policy violations. Because the agent can read the same run thread, troubleshooting and improvement are collaborative; you can ask it what went wrong on a run and it can propose a fix to the automation.
For how to build and configure automations, see Building automations. For the human-in-the-loop surface where reviewers approve the drafts a run produces, see How For review works.