A background agent works without requiring you to keep an active conversation open. A scheduled agent starts at a set time; an event-driven agent starts when a configured change arrives. These are different ways to start and run work. They do not mean that a model thinks continuously, remembers everything, or has unlimited authority.
How do background, scheduled, and event-driven agents differ?
Swipe sideways to see all columns →
| Concept | What it describes | Fictional example |
|---|---|---|
| Background execution | Work continues without an open conversation; it may start from a request, schedule, or event. | Finish checking the approved Matter 42 packet and report when ready. |
| Scheduled start | A clock-based rule starts a run. | Check the Matter 42 folder each workday morning for five workdays. |
| Event-driven start | A configured event starts a run. | Inspect a newly added document when the approved repository reports its arrival. |
The trigger answers “when should work start?” The runtime answers “how does it execute, pause, resume, and stop?” A scheduler can start a fixed script as easily as an agent. Scheduling alone does not make the work agentic: the model must have a role in choosing steps or interpreting results within the task.
What starts a run, and how does it get fresh information?
LangSmith's cron-job documentation shows scheduled runs receiving configured input. That input is repeated each time; it is not automatically a fresh snapshot of the outside world. The platform supports schedules associated with an existing thread and stateless schedules that create a new thread for each run. Those are implementation choices, not universal behavior.
For a monitor, make each run fetch the current approved records and record when it checked them. Compare record IDs and versions with the last verified result. An event should identify what changed and where; receiving an event does not establish that its document is relevant, complete, or accessible. Recheck the source and permissions before interpreting it.
How does an agent save progress and resume later?
A checkpoint stores execution state so a run can continue later. LangGraph's persistence guide distinguishes thread-scoped checkpoints from stores for application data shared across threads. An in-memory checkpointer loses its contents when the process restarts; recovery requires storage that survives the interruption. Saved state is separate from whatever context the model receives on its next step.
A run can pause for review instead of repeatedly asking the model to continue. LangGraph's interrupt documentation describes saving state and resuming with external input. A resumed node runs again from its beginning, so earlier side effects may repeat. Design repeated operations to avoid duplicate effects, and put consequential actions behind approval. A checkpoint is not a guarantee that an external action happened exactly once.
What would a useful document monitor do?
Imagine a fictional Matter 42 folder awaiting a signed services agreement. A named reviewer authorizes a five-workday monitor of that folder. Each morning, the run checks for new records, verifies candidate versions, and prepares an internal note with source references. It neither sends the document nor updates a matter record. No real client information or account is involved.
Keep a small ledger: last successful check, document IDs and versions inspected, unresolved questions, and notifications already issued. If nothing changed, record the successful check quietly. If a candidate arrived, inspect the saved file rather than relying on its name. A status saying “signed” is a reason to verify the agreement and expected signatures, not a conclusion by itself.
Suppose the download succeeds but the run fails before saving its checkpoint. On recovery, inspect the existing file and operation record before trying again. Use a stable operation ID and a recorded receipt so a repeated request does not create another copy or notification. Bound retries; an expired credential or forbidden read needs intervention, not an endless loop.
How should schedules handle time zones, missed runs, and overlap?
Specify the intended time zone and daylight-saving behavior, rather than saying only “every morning.” LangSmith cron schedules use UTC. Temporal's schedule documentation describes named time zones, overlap policies, and catchup windows that govern late starts. These behaviors differ by platform. Test clock changes, skipped or repeated local times, outages, and an earlier run that is still active.
For Matter 42, choose one active check at a time and define whether a delayed check should run late or be skipped. Do not silently replay a backlog of obsolete daily notices. Record the actual last successful check, and escalate when the monitoring gap exceeds the agreed limit. Pausing future starts and stopping a run already in progress are separate controls.
How do you control authority, limits, and notifications?
Assign an owner, approved sources and destinations, end date, run-time and cost budgets, maximum attempts, and stop conditions. Enforce these in the runtime and connected services. Recheck access on each run and after a pause: yesterday's permission may have been revoked. Stored instructions do not extend an account's authority or approve new external actions.
For this monitor, notify the reviewer about a verified new candidate, a failure that leaves the folder unchecked, completion, or a decision requiring approval. Include what changed, its source, and the next decision. Deduplicate repeated alerts. If sending or modifying anything becomes necessary, pause and show the exact proposed action; approval of monitoring alone does not authorize it.
When is simpler automation enough?
If the entire rule is “when a new file arrives, notify the owner,” a deterministic automation may be enough. Add a model when interpreting changing evidence or choosing a bounded next step supplies a measurable benefit. Compare both versions on missed changes, duplicate alerts, reviewer effort, time, and cost. Also test failure recovery and whether the monitor actually stops when its authority expires.
