You ask an assistant to prepare a report, close the laptop and expect a finished document in the morning. Whether anything happens overnight depends on the software around the model. A chat window can describe a plan without creating a job that will keep running.
An agent usually combines a model with tools and a loop: inspect the situation, choose an action, read the result and decide what to do next. Background execution adds another requirement. Something must keep that loop alive after the conversation ends, with access to the files and services the job needs.
That distinction matters before you delegate work. “Can use a browser” describes a capability. “Will check this page tomorrow and send the result” describes a scheduled commitment. The second needs a running service, a trigger and somewhere to deliver the result.
A workflow can continue without being an agent
A scheduled script can download a file every morning and email a summary. Its steps may be fixed in advance. An agent has more freedom to choose the next step: follow a reference, query another source or retry a failed operation with a different approach.
Anthropic’s engineering guide distinguishes predefined workflows from systems in which a model directs its own tool use. That is a useful design distinction, though products use the word “agent” loosely. A predictable task may work better as a short workflow, with a model used only for the part that needs interpretation.
Imagine a weekly inventory report. Fetching stock levels and applying a reorder threshold require little discretion. Explaining an unexpected fall in demand may require several searches and a judgment about which evidence belongs in the report. Giving the entire process open-ended autonomy would add cost and failure opportunities without necessarily improving the routine steps.
Closing the window changes where the work must live
A cloud job can continue while your laptop sleeps if the provider has created a persistent task. A local process may stop when the machine sleeps, loses its connection or closes the application. A browser tab is not evidence of either arrangement.
Look for a task record with a state such as queued, running, waiting for approval or complete. A useful record also shows the last action, the next scheduled run and the output location. If all you have is a conversational promise, check the product’s task controls before relying on it.
Persistence involves more than preserving a transcript. A long job needs to record what it has already done. Otherwise a restart can send the same message twice, create duplicate files or repeat a purchase. Operations with side effects need their own completion records and, where supported, identifiers that prevent accidental duplication.
Permissions determine the practical reach
An agent connected to a calendar might be able to read events, propose a new event or actually invite people. Those are different permissions. A connector appearing in a list does not establish which actions are enabled.
For a report, read access to a selected folder may be sufficient. Publishing the report requires write access somewhere else. Sending it to a client is another action with another audience. It helps to set those boundaries separately, even if the interface presents one broad task.
Approval also needs a place in the job’s state. If a task reaches a step that requires confirmation while you are offline, it should wait and make that visible. Repeatedly asking the model to “use good judgment” does not substitute for restricting the underlying tool permissions.
The same logic appears in browser extension permissions: the useful question is what the software can access and change, not just what its description promises.
Define a finish line the software can check
“Research competitors” has no obvious stopping point. “Compare these five products using their current pricing pages, include source links and save a table” gives the system something it can complete and you something you can inspect.
For a task that can run overnight, specify the output, the sources it may use, the actions it may take and a spending or time limit. Decide what should happen if a required source is unavailable. A partial result with a clear missing item is often more useful than an endless retry loop.
Completion checks should match the task. A file existing does not prove that a report’s claims are supported. A successful request does not prove that the intended record changed. A published page needs a check of the public page, not merely a successful save response.
Read the activity record before trusting the result
An agent can produce a polished explanation of work that only partly succeeded. The activity record should let you trace the important claims to sources and the important actions to results. For actions that affect other people, it should identify the destination and what was sent or changed.
Start with a bounded job whose result you can check cheaply. Increase its scope after observing how it handles missing data, interrupted access and ambiguous instructions. The cost of those checks belongs in the cost of an AI task, alongside model and tool charges.
