Jobs

Jobs are automated agent runs — either run once on demand, or set up to trigger on a schedule or in response to events.

What Are Jobs?

The Jobs app is a single searchable list that mixes two kinds of items:

Both are the same underlying primitive — a definition plus a trigger — so everything you learn about runs, filters, and rate limits applies to both. Each row carries a live status dot so you can see at a glance which items are healthy, running, or failing.

Every trigger creates a run record you can inspect, so you always have visibility into what ran, when, and whether it succeeded.

How Jobs Are Created

There is no “Create Job” form in the Jobs app — the list only lets you search, open, and manage existing items. You create a job or watch in one of two ways:

• Ask the assistant in chat. Tell the built-in Insulin agent what you want to automate (for example, “every weekday at 9am, summarize new AWS entitlements”). The agent creates the job or watch for you. See Chat.
• Use the REST API. POST /jobs creates a job or watch programmatically.

If you don’t specify an agent when creating a job, it runs under the built-in Insulin agent. Otherwise it runs under the agent you name, with that agent’s access to resources and integrations.

Triggers

Every job has one of exactly three trigger kinds. In the list, manual items appear as Jobs (Zap) and the two automatic kinds appear as Watches (Eye).

Push sources

Push watches subscribe to an event source:

• Suger events are the marketplace events Insulin already knows about. When created over REST, the source must match suger.<entity>.<action> — for example suger.OFFER.ACCEPT. Sources that don’t match this pattern are rejected.
• Third-party events — GitHub (github.<event>), Google Calendar (calendar.<event>), and Gmail (gmail.<event>) — require a live OAuth connection to that provider and can only be created by asking the assistant, which registers the subscription for you.

Cron Scheduling

Cron expressions define when a scheduled watch runs. Standard cron syntax is supported:

A watch’s detail view shows its cron expression as a badge and in the header text, along with Next run and Last triggered timestamps.

Filter Expressions

Filters let you control which events actually trigger an agent run. When an event arrives on a push watch — or when a cron tick fires with a payload — the filter expression is evaluated against the event payload. If the filter returns false, the run is skipped and recorded with the filtered status.

Filters use filtrex syntax — a safe, sandboxed expression language. The event payload is available under the event namespace.

Examples:

event.source == "aws-marketplace"

event.amount > 1000

event.action == "entitlement_created" and event.partner == "AWS"

lower(event.status) == "active"

Available functions: lower(), upper(), includes() (checks if an array contains a value).

Dot notation is supported for nested fields: event.buyer.name, event.offer.info.commits.

Runs

Every trigger creates a run record. Each run ends in one of these statuses:

Filtered and rate-limited events still create a run row, so nothing that fired is invisible.

Where you inspect runs depends on the item type:

• On a Watch, the detail view has an Executions list — each run shows its status badge, any error, and a relative timestamp.
• On a manual Job, the detail view shows the latest run inline: the agent’s Plan steps, the rendered Result (as markdown), or the Error if it failed.

Rate limits

To keep automations from overwhelming your workspace, runs are rate limited:

Limits apply over a rolling one-hour window. Runs that exceed a limit are recorded with the rate limited status rather than executing.

Managing Jobs

Open an item from the list to reach its detail view. Available controls depend on the item type.

Manual Job:

• Run — Start the job. Available only while the job is pending; a job allows at most one in-flight run at a time, so if a run is already active a second Run is rejected with “Job already has an in-flight run.”
• Cancel — Stop a pending or running job.
• Delete — Permanently remove the job and its run history.

Watch:

• Enable / Disable — Pause a watch without deleting it. Disabled watches do not trigger.
• Trigger now — Fire the watch immediately; a run is created as if an event had arrived. (The REST trigger endpoint and the assistant also accept an optional payload to exercise the filter against sample data; the in-app Trigger now button fires with an empty payload.)
• Delete — Permanently remove the watch (with confirmation) and its run history.

Use Cases

• Marketplace monitoring — A cron watch that checks for new entitlements or expiring offers daily and summarizes changes.
• Automated alerts — A push watch on Suger marketplace events that runs an agent to evaluate severity and notify your team.
• Recurring reports — A cron watch that runs a data analyst agent weekly to generate revenue or usage reports.
• Co-sell pipeline tracking — A cron watch that reviews partner referrals on a schedule and flags stale opportunities.