Job

If a queue is the rail of order tickets, a job is the single ticket.

One specific piece of work. Defined, handed off, tracked, completed. Not the whole workflow — not the system — just this one thing that needs to happen.

A concrete job list from a typical day of running a software product:

• Send the welcome email to the customer who signed up at 3:47pm.
• Generate the weekly summary report for account #8812.
• Resize the profile photo that user just uploaded.
• Process the batch of orders from last night's sale.

Each one is a job. They're distinct. They each have a start and an end. You can check whether they ran, whether they succeeded, whether they failed.

Why "job" is worth treating as its own word.

Because once you understand jobs, you start seeing your own work differently.

Most of what a business does can be broken into jobs. The real question is: which ones are you (or your agents) running manually right now, every time? And which ones could be queued, handed off, and handled without you watching?

A job has a few useful properties:

• It either succeeded or failed. No ambiguity. This is what makes jobs trackable. If you don't know whether your weekly report generated last Sunday, that's a "did the job run?" question.

• It can be retried. A job that fails doesn't have to stay failed. A good system notices the failure and tries again. The welcome email that bounced gets queued for another attempt. That's called retry logic, and it's one of the fastest ways to make agent workflows more stable.

• It can have a schedule. A job that runs at 9am every weekday isn't magic. It's a job with a trigger attached. That trigger system has its own name (cron — and it's worth its own entry).

The distinction that saves headaches.

There's a common confusion between "is the system working" and "did this specific job work." The system can be perfectly healthy while one job, for one customer, on one specific day, failed quietly. Knowing they're separate things means you know to check both.

Ask your system: did the job run? Did it succeed? Your system should be able to answer that. If it can't, that's worth fixing before the failure is the customer asking why their email never arrived.

Jobs are the atoms of automated work. Small, trackable, disposable. Build them that way and the whole thing gets easier to watch.