Execution Layers

Triggers vs Schedules vs Interactive Agents

Not every task should become a chat flow. Good agent systems choose the right execution model before they choose the model.

One of the most common mistakes in agent systems is forcing every task through a conversational interface. A more reliable approach is to separate three execution layers: triggers for event-driven work, schedules for recurring background work, and interactive agents for dynamic tasks that need clarification, judgement, or iteration.

Key Facts

Execution layers: 3
Primary decision: Event, schedule, or conversation
Shared backbone: Workflow engine + context + monitoring
Operational concern: Retries, idempotency, hand-offs
Common failure: Forcing every task into chat
Use with: Queues, workers, inboxes, operator UIs

How should a team choose the right execution layer?

Use triggers when something external changes and the system should react. Use schedules when the work is predictable and time-based. Use interactive agents when the task needs clarifying questions, steering, approvals, or judgment mid-run.

When should a team not use an agent?

Do not introduce an LLM where a deterministic rule, webhook, form flow, or scheduled job already solves the problem cleanly. Agent layers should handle ambiguity, prioritisation, judgment, and recovery, not replace straightforward automation for its own sake.

Evidence

See the examples library

Use implementation examples to compare direct automation patterns with more agentic flows.

Open examples

Doctrine

Return to orchestration doctrine

Keep the execution-layer decision connected to the orchestration and delegation principles.

Open principles

Use the three-layer model deliberately

Each layer exists for a different kind of operational uncertainty. The architecture improves when teams stop treating chat as the universal entry point and instead route all three layers through a shared workflow engine backed by state, context, tools, and monitoring.

Trigger-driven workflows

Best for event reactions such as inbound messages, CRM changes, failed payments, support escalations, or uploaded files.

Persist the incoming event first

Design for idempotency and retries

Keep the success or failure trace inspectable

Scheduled workflows

Best for recurring summarisation, reporting, cleanup, follow-up sweeps, and maintenance tasks.

Make time windows explicit

Persist job state and retry strategy

Expose missed runs and stale jobs clearly

Interactive agents

Best for cases where the system needs clarifications, approvals, or real-time steering from a human operator.

Keep delegation boundaries clear

Expose blockers and waiting states

Represent the work as a system, not only a transcript

Shared workflow backbone

All three layers should converge on one workflow engine that can call the database, external APIs, AI runtime, and monitoring stack while reading from a versioned context hub.

Persist event state and outputs in the database

Treat MCP as part of the AI runtime and tool layer, not the whole architecture

Keep monitoring and context-hub traces connected to every run

Continue through the runtime branch

This branch is meant to work as one library. Use the other guides to complete the operating model beyond the current topic.

Context Hubs

Tiered Context Loading for Agent Systems

One of the fastest ways to make an agent slower, more expensive, and less reliable is to give it too much context too early. Tiered context loading turns context discovery into a staged process so the runtime has a navigation system, not just a pile of files.

Runtime Safety

Safe Delegation to Heavy Runtimes

Modern agent systems increasingly combine a lightweight tool-using agent with a heavier runtime that can browse, run shell commands, inspect files, or operate more autonomously over many steps. The design question is when delegation is justified, how it is bounded, and how it can be reviewed afterwards.

Should everything start as an interactive agent?

No. Many tasks are better as triggers or schedules. Interactive agents are most useful where intent is ambiguous or the user needs to steer the work.

Can one system use all three execution layers?

Yes. In mature systems, triggers, schedules, and interactive agents often share the same underlying infrastructure.

Are triggers less agentic?

Not necessarily. They are often more appropriate. Agentic behaviour should be applied where it improves outcomes, not as a default wrapper around everything.

Continue through the runtime branch

This branch is meant to work as one library. Use the runtime landing page to recover the full operating picture, then move into principles when you need to reconnect runtime decisions to doctrine.

Back to landing page Open principles