Free guide

Let agents work while you sleep: goals, loops and routines

How I move teams from typing prompts one by one to agents that run on their own, with a clear finish line, a schedule and a human review. Works with Claude Code and Codex.

What's inside

1. 1. Define done before you start

   • Write the finish line as something the agent can prove: 'npm test exits with 0', not 'make it better'.
   • Name the scope: which folders, which tickets, what is off limits.
   • Put a limit into the goal itself, for example 'or stop after 20 turns and report what is left'.

2. 2. Set the guardrails

   • An instruction file per repository with the rules the agent must follow.
   • Branch-only: the agent opens pull requests, it never merges or deploys to production.
   • No production credentials, test accounts only, and a token budget per run.

3. 3. Pick the right mode

   • Clear finish line: a goal (/goal in Claude Code, goal mode in Codex).
   • Recurring check while you work: a loop on an interval, for example /loop 15m.
   • Has to run with your laptop closed: a routine in the cloud, started by a schedule, an API call or a GitHub event.

4. 4. Dry run with a person watching

   • Run it once interactively and read every step.
   • Fix the instructions where the agent went wrong, not just the output.
   • It only runs unattended once a dry run passes cleanly.

5. 5. Run unattended

   • Start small: one repository, one task type, such as dependency updates, failing tests or a nightly report.
   • Every run writes a short summary: what it did, what it skipped, what needs a person.
   • An alert goes to the team chat when a run fails or takes far longer than usual.

6. 6. Review before anything ships

   • A person reviews and merges, exactly as for human pull requests.
   • Hard rules: login, payments, data deletion and permissions always need a human.
   • Staging first, then production, with smoke tests after every deploy.

7. 7. Learn and widen

   • Each mistake becomes a rule in the instruction file, so the next run avoids it.
   • Track the hours saved, the cost per run and the share of runs that needed help.
   • Add the next task type only when the current one has run quietly for two weeks.

8. Rolling it out, by company size

   • Startup: one routine for the boring work, such as dependency updates, failing tests and the weekly report. Usually live within a week.
   • Mid-sized company: a pilot team with shared instruction files and a token budget, then the other teams.
   • Enterprise: managed settings that users can't override, an approved list of models and tools, audit logs and local models for sensitive code.