A conversation is you asking an agent something. A job is that same work running without you — once on demand, on a schedule, or when an event arrives. The signal to move something over is repetition: the third time you type roughly the same request, you have already written the job.
Chat is where everything starts, and it should be. You do not know what you want until you have asked for it a few times and seen what comes back.
The trouble is that chat is also where things stay. The Monday-morning summary is a message somebody sends every Monday morning. The check on whether anything is stuck is a question somebody remembers to ask, until the week they do not.
Work that recurs but depends on a person remembering is not automated. It is just delegated to whoever has the best memory.
What is a job?
Jobs are automated agent runs — either run once on demand, or set up to trigger on a schedule or in response to events.
The Jobs app distinguishes two item types:
- A Job is a one-off agent run you start on demand.
- A Watch is a standing automation that triggers an agent on a schedule or when an event arrives.
Both share the same structure — a definition plus a trigger — and differ only in how they execute. That symmetry is useful in practice: you build something as a one-off, run it a few times until the output is right, then give it a trigger.
The three triggers
| Trigger | Runs when | Good for |
|---|---|---|
| Manual | You start it | Work you want on demand but not retyped |
| Cron | A recurring schedule, e.g. 0 9 * * 1-5 for weekdays at 09:00 | Reports, digests, periodic checks |
| Push | An event arrives from Suger, GitHub, Google Calendar or Gmail, if a filter passes | Reacting to something happening |
The push trigger is the one worth dwelling on, because it is the difference between checking and reacting. A cron job that runs hourly to see whether something changed is a poor imitation of an event trigger that fires when it does — and it is worse than the imitation suggests, because it is either too slow or mostly wasted runs. Scheduled vs event-driven jobs covers the choice properly.
The test for moving something over
Three questions, in order:
Does anyone need to be here? If the work requires judgement mid-way — deciding which of three things to pursue, choosing tone, reacting to something surprising — it stays a conversation. Jobs are for work whose shape is known.
Has it happened three times? Once is a question. Twice is a coincidence. Three times is a pattern, and by then you also know what good output looks like, which is the thing you actually need to define a job.
Is the output useful without you? A job produces something someone reads later. If the value came from the back-and-forth — you asked, you saw, you refined — then the conversation was the product and there is nothing to schedule.
What a job can reach
Jobs run within the creating user’s scope, so the agent has access to the same resources and integrations that user does.
This is the most important operational fact about jobs and the easiest to overlook. Two consequences:
A job inherits your access, not the agent’s ambition. If you cannot see something, neither can the job you created. That makes the security model predictable, and it also means a job built by someone with narrow access may quietly produce thin results.
Ownership is a real dependency. Only organisation admins or the owning user can run, edit or delete a job. A recurring job owned by one person is a dependency on that person — worth thinking about before the standing Monday report belongs to someone who changes team.
Attach a knowledge base if the work needs your written policy rather than live system data. That is what makes an unattended run apply the same rules a person would.
Watching the output
Results surface differently by type. A manual job shows the agent’s plan, the rendered result, or an error inline in the detail view. A watch keeps an Executions list with each run’s status and output.
Read the Executions list for the first fortnight of any new watch. A scheduled job that has been silently failing looks exactly like a scheduled job that had nothing to report, and the two are indistinguishable until you go and look.
Frequently asked questions
How is a job different from chatting with an agent? Chat is you asking; a job is the same work running without you. Jobs run once on demand, on a cron schedule, or in response to an event.
What is the difference between a Job and a Watch? A Job is a one-off run you start on demand. A Watch is a standing automation triggered on a schedule or by an incoming event. Both share the same definition-plus-trigger structure.
What events can trigger a job? Push triggers listen for events from Suger, GitHub, Google Calendar and Gmail, and run the agent if a filter condition passes.
What can a job access? Whatever its creator can. Jobs run within the creating user’s scope, so the agent has the same resources and integrations that user does.
Who can edit or delete a job? Only the owning user or an organisation admin, which makes job ownership a real dependency worth assigning deliberately.
When should something stay a conversation? When it needs judgement mid-way, or when the value came from the back-and-forth rather than the final output.
Takeaways
- The third time you type roughly the same request, the job is already written. Move it.
- Jobs and watches share one structure, so build as a one-off, get the output right, then add a trigger.
- Use push triggers to react. An hourly cron that checks whether something changed is either too slow or mostly wasted.
- A job runs in its creator’s scope, which makes access predictable and makes ownership a real dependency.
- Attach a knowledge base so an unattended run applies the same policy a person would.
- Read the Executions list early. A silently failing watch is indistinguishable from a quiet one.
Work that recurs should not depend on somebody remembering. See how Jobs run on a schedule, on an event, or on demand.
Sources
Primary sources for the platform rules cited above. Last verified August 16, 2026. Cloud providers change fees, eligibility, and program terms without notice — check the source before relying on a figure.
- Suger Insulin docs: Jobs — That jobs are automated agent runs; the Job versus Watch distinction; the manual, cron and push trigger kinds with their sources; that jobs run within the creating user's scope; and how results appear for manual runs versus watch executions
Stay Updated
Get the latest Cloud GTM insights, product updates, and marketplace strategies delivered to your inbox.