Before You Let the Agent Run Alone: Four Settings to Lock In First
Letting an AI task run unattended is a different decision from asking it a question. When you ask a question, you read the answer and decide what to do with it. When you hand over a task that will run on a schedule or kick off without you, the answer is no longer the thing that matters. The actions are. Before anything runs while nobody is watching, four settings should be fixed on paper, not left to defaults: how often it runs, what it can touch, what budget it stays inside, and what it remembers.
Most of the trouble with unattended AI comes from one of these being left open. A task set to run "whenever" fires far more often than anyone intended. A task with broad access can reach records it never needed. A task with no spending ceiling can quietly consume a month's allowance in a weekend. And a task that remembers too much, or the wrong things, carries yesterday's assumptions into today's decision.
How Often Should It Run?
Frequency is the easiest setting to get wrong and the easiest to fix. Ask what the task is for. A morning briefing needs to run once a day, before people start work, and not again. A reconciliation check might need to run hourly if the data changes hourly, but running it every minute produces noise and cost without producing better answers.
Write the frequency down as a sentence: "Runs at 7:00 on weekdays, once." If you cannot phrase it that plainly, the task is not yet defined. A useful habit is to also set a stop condition, such as "stops after the first success for each day," so that a retry loop cannot turn one failure into two hundred.
What Can It Touch?
This is the setting where the most damage happens. An agent that reads a customer table and writes a summary needs read access to that table and write access to one output location, and nothing else. Give it the entire database because it was simpler to configure and you have created a risk you will not notice until something changes.
Separate reading from acting. Many of the safest deployments let the AI see everything it needs but send nothing, change nothing, and delete nothing without a person approving the specific action. If the task is to draft a follow-up email, the draft goes into a queue. A human presses send. The same logic applies to records: a status update, a payment, or a deletion should require an explicit confirmation step, not a silent write.
Check the scope against a plain question: if this task behaved badly once, what is the worst thing it could change? The answer should be small and recoverable. If the honest answer is "anything in the account," narrow the permissions before you schedule it.
What Budget Does It Stay Inside?
Every model call costs money, and an unattended task multiplies that cost by however many times it runs. Set a ceiling per run and a ceiling per period, such as per day or per month. Then decide what happens when the ceiling is reached. The task should stop and report, not silently fall back to a more expensive model or keep retrying.
Budget also shapes design. A task that sends the entire history of a conversation on every run will grow more expensive as history grows. Passing only the fields the task needs, and summarizing older context instead of carrying it forward whole, keeps the cost predictable. If you cannot estimate the cost of one run within a reasonable margin, run it manually a few times and measure before you leave it alone.
What Does It Remember?
Memory is the setting people forget entirely. An agent that keeps notes between runs can become more useful, but it can also keep stale facts alive. If last month's pricing was stored as a fact, the task may keep quoting it after the price changed. If an earlier error was recorded as a lesson, the mistake may persist as policy.
Decide explicitly what carries over. Some state is worth keeping: a list of items already processed, so the task does not duplicate work. Other state should expire: a snapshot of a customer's status should be refetched rather than remembered. Keep the memory small, label where each piece came from and when it was written, and review it on a schedule. Anything the task remembers should be something you could explain to a colleague in one sentence.
Put the Four Answers in Writing
The practical step is to write the four answers into the task's configuration or a short document attached to it: the schedule, the permissions, the budget ceiling, and the memory rules. When something goes wrong, which it eventually will, that page is the first thing to check. It tells you what the task was supposed to do, and it makes the gap between intention and behavior visible.
Unattended work is worth doing. It is the reason to build these systems at all. But the time to decide how often, how far, how much, and how long it remembers is before the first run, while you are still the one watching.
