An Insulin job pairs one of your agents with a task and a trigger, then runs it unattended. The trigger is the design decision: one time, on a recurring schedule, or when a business event fires.
Automating recurring work is rarely the hard part. Choosing when it runs is, and the wrong choice produces one of two familiar complaints.
Too slow: the check runs nightly, so a problem introduced at nine in the morning is found the following day, after it has propagated. Too noisy: the job runs every fifteen minutes to catch that problem faster, and now produces a daily stream of “nothing to report” that people stop reading — which means the one real finding arrives inside a channel everybody has muted.
Both are trigger problems, and both are avoidable by asking one question first.
The question that picks the trigger
Is this work tied to a deadline, or to a change?
Work tied to a deadline belongs on a schedule. The month-end close happens at month end whether or not anything changed; the Monday digest is due Monday. Time is the thing that makes the work due, so time should be the trigger.
Work tied to a change belongs on an event. A record that just moved to a stage needs attention because it moved, not because it is Tuesday. Polling for it on a timer is a worse version of being told.
The complaints above are what happens when this is inverted. Nightly checks for change-driven work are always stale by up to a day. Frequent polling for change-driven work generates noise proportional to the polling rate rather than to how often anything actually happened.
The three triggers
One-time. A single unattended run — a backfill, an audit, a sweep across your records. Underrated, because it is the honest way to answer “would this be useful on a schedule?” Run it once, read the output, and find out. A one-time run also handles genuinely one-off work without leaving a job behind that somebody has to remember to disable.
Recurring. The agent on a timer, defined by a cron expression: every morning, every Monday, at month-end. The right trigger for deadline-shaped work, and the one to reach for when the value is in the regularity — a digest people expect at a known time is more useful than a better report that arrives unpredictably.
Event-driven. The run starts when a change occurs in the business, so the agent reacts when something actually happens instead of waiting for the next tick of the clock. This is the trigger for anything where latency between the change and the response is the cost.
What a job inherits
A job does not define its own permissions. It runs under the agent you name — or the built-in Insulin agent if you name none — and it runs within the creating user’s scope, which means the agent reaches the same resources and integrations that user does. The agent’s own allowlist narrows things further.
Two bounds, then, and it is worth knowing which is which: the person who created the job sets the ceiling, and the agent’s configuration sets the limit beneath it. Neither is adjusted at the job. The practical consequence is that the security decision for a scheduled run happens before the schedule exists — if a run should not reach a system, the fix is the agent’s allowlist or who owns the job, not a setting on the job itself. It is another reason to keep agents narrowly scoped.
The grounding comes along too. An unattended run at seven in the morning reads the same documents and returns the same cited sources an interactive session would, which is what makes overnight output worth the same as output somebody watched being produced.
Designing the output
The trigger decides when a job runs. What it produces decides whether anyone benefits.
Deliver where the team already talks. Output that lands in the channel people read gets read. Output that lands somewhere people must remember to check is the same as no output.
Say what changed, not what ran. “Compared 1,482 records, 13 flagged, here they are” is a result. “Job completed successfully” is a log line. The second trains people to ignore the first.
Consider silence on a clean run — carefully. A job that only speaks when it finds something keeps attention valuable, but it is indistinguishable from a broken job. The workable compromise is a brief digest on a schedule people expect, and an immediate alert only when there is something to act on.
Review the runs. Jobs are not fire-and-forget. Read the output for the first few cycles and adjust the task; a job whose instructions were right in March and unchanged in August is describing a business that no longer exists.
Frequently asked questions
What triggers can an Insulin job use? Three: one-time for a single unattended run, recurring for a schedule, and event-driven so the agent runs when a business event fires rather than on the next tick.
How do I choose between a schedule and an event? Ask whether the work is tied to a deadline or to a change. Deadlines belong on a schedule; changes belong on an event. Polling for change-driven work is either stale or noisy.
What permissions does a job have? A job runs within the creating user’s scope, so the agent reaches the same resources and integrations that user does, narrowed further by the agent’s own allowlist. Neither is set on the job.
Do unattended runs still use our documents? Yes. A job reads the same attached knowledge bases an interactive session would and returns the same cited sources, so overnight output follows the same policy.
Should a job report when it finds nothing? A silent job is indistinguishable from a broken one. A brief digest on a schedule people expect, plus an immediate alert only when action is needed, is the usual compromise.
Takeaways
- Deadline-shaped work goes on a schedule; change-shaped work goes on an event. Inverting this makes automation stale or noisy.
- Use a one-time run to find out whether recurring work is worth scheduling.
- A job runs in the creating user’s scope, bounded by the agent’s allowlist — the permission decision happens before the schedule exists.
- Grounding follows into unattended runs, so overnight output cites the same documents.
- Report what changed rather than that the job ran, and deliver it where the team already talks.
Insulin jobs run your agents unattended — once, on a timer, or on a business event. Explore Insulin jobs, see how agents are scoped, or get a demo.
Sources
Primary sources for the platform rules cited above. Last verified August 14, 2026. Cloud providers change fees, eligibility, and program terms without notice — check the source before relying on a figure.
- Suger Insulin docs: Jobs — One-time runs, cron-scheduled recurring watches and push watches that listen for events; a job runs under the agent you name or the built-in agent, and runs within the creating user's scope so the agent reaches the same resources and integrations that user does.
Stay Updated
Get the latest Cloud GTM insights, product updates, and marketplace strategies delivered to your inbox.