Skip to content
flowlakes FlowLakes documentation home

Triggers and events

Agentic work raises five lifecycle events you can react to: an agent run completed, a plan proposed, a plan approved, a plan rejected, and a plan executed. Each event is attached to the record the run or plan is about, so a workflow, a notification, or even another agent can react to it the same way it reacts to any record event. To react, you point a workflow trigger or a notification rule at the event you care about. Chaining one agent off another’s event is allowed, with a depth guard that stops runaway chains.

When you’d use it

  • Kick off a workflow when an agent finishes or a plan is executed.
  • Notify someone when a plan is proposed and needs review.
  • Hand off to another agent once the first one’s plan is approved.
  • Build an audit or follow-up step that reacts to an agent’s outcome.

What you manage

You use these events wherever you configure a trigger:

  • A workflow trigger. Name one of the five events as its trigger type.
  • A notification rule. Name one of the five events as its trigger event.
  • An agent handoff. Trigger one agent from another’s lifecycle event.

The five events are: agent run completed, plan proposed, plan approved, plan rejected, and plan executed.

Calling an agent by hand

A record condition is not the only way work reaches an agent. Anyone who can comment on a record can call one from the activity feed.

  • Type @ in the comment box and pick an agent from the list that appears. The list is ordered the way the platform actually resolves a mention: the agent that last worked this record first, then the agent set as the table’s front door, then the rest. The list appears only on tables you have permission to read; without it the comment box stays a plain text box.
  • Type @agent and the platform picks for you: the agent that last ran on this record, or the table’s front door if none has.
  • Type @ followed by an agent’s slug to call a specific one, including an agent that has no trigger on this table at all.

Good to know

  • A trigger condition narrows automatic dispatch and nothing else. If you filter an agent’s trigger down to one catalog item, that filter decides when the agent wakes on its own. It has no say in who a mention reaches, because a mention is a person giving an instruction.
  • A mention that reaches nobody says so on the record. If no agent is set up for the table, or two claim the front door, the platform posts a note naming the agents you can call directly.
  • An agent called onto an unfamiliar record still runs under its own permissions and charter. It will usually explain that the record is not its job rather than fail.
  • Each subscriber reacts on its own. One failing subscriber does not stop the others.
  • An event with no related record is not raised, so there is nothing to react to in that case.
  • A handoff is depth-guarded. It is refused if it would retrigger the same agent, form a cycle, or exceed the maximum chain depth.
  • Business rules are deliberately not wired to these events, because they already react to the record changes that execution makes.

How it connects

Triggers and events carry observation, not execution. Executing an approved plan belongs to Plans and governance; these events only observe it. How a subscriber reacts is owned by that subscriber, a Workflow or a Notification.