Lesson 01. What a Standing Agent Is

You close your coding agent's session on Friday. It has spent three hours learning your repo's layout, your naming conventions, which tests are flaky, and that you prefer small commits. Monday morning you open a new session and none of that is there. You re-explain the repo, re-state your preferences, re-point it at the flaky tests. This is not a one-time cost. It is every single day, for as long as you use the tool this way.

A coding agent is built to answer one prompt and stop. That is the right shape for "fix this function." It is the wrong shape for "keep an eye on my inbox," "remember that I hate stand-ups before 10am," or "check the deploy every morning and tell me if it's red." Those tasks span sessions. The agent needs to still be there, and still know what it knew, after you have closed the laptop. A standing agent is what you get when you deliberately build for that gap instead of living with it.

A standing agent is the same model plus four things

Nothing about the underlying model changes. You do not need a bigger model, a fine-tune, or a different vendor. What changes is what surrounds the model between calls. Four components, and the standing agent is precisely their composition:

• Persistent memory: files on disk that survive when the process exits. Not context-window state, not a chat history the provider keeps for you. Files you own, in your repo, that the agent reads and writes.
• Retrieval: a way to pull the relevant slice of memory into context without loading all of it. Memory that only grows is useless if nothing can find the right five lines out of five thousand.
• Tools: narrow, wrapped access to the outside world (your calendar, your inbox, your task tracker) so the agent can act, not just talk.
• A schedule: something that invokes the agent without you present. A cron job, a systemd timer, a scheduled cloud run. Without this, "standing" is just marketing; the agent still only runs when you type something.

Each piece is close to useless alone. Memory with no schedule is a diary nobody reads. A schedule with no memory reruns the same blind prompt forever, learning nothing. Tools with no memory re-authenticate and re-discover state on every call. The four together are what let an agent accumulate value over time instead of resetting to zero on every invocation.

The rule and its condition

Use a standing agent when the task needs to survive your own absence in either of two ways: it must remember something from a previous run when it acts again, or it must start itself on a schedule instead of waiting for you to type a prompt. If neither is true, a standing agent's memory, retrieval, and schedule are three components paying rent for nothing.

The observable test: would this task still work today if it forgot everything between runs and only ever ran when you typed something? If yes, you don't need a standing agent yet, you need something smaller.

Once a task's shape matches the third row, the rest of this lesson is about how a standing agent is actually built.

Loop: Remember, Retrieve, Act, Report

The four components above map onto a loop the agent runs every time it wakes up. Watch how the schedule only ever triggers the first stage, and how the arrows run one way: there is no branch back to "wait for a human" in the middle of a beat.

That fixed order is the whole loop: nothing skips a stage, and nothing repeats one out of sequence before the beat completes. Remember loads what the agent already knows about you and the current task. Retrieve pulls the specific slice of history relevant to this run: not everything, just what's relevant. Act does the actual work through tools. Report writes the outcome back to memory and tells you about it only if it's worth interrupting you for. The rest of this course builds one stage of this loop per lesson, in order: memory (lessons 2-3), tools (lessons 4-5), then the schedule and the trust layer around it (lessons 6-8).

What a standing agent is not

It is not a chatbot with a longer memory window. A chatbot answers when spoken to; a standing agent initiates on its own schedule and acts through tools without a human typing the trigger each time. If you never gave your assistant a schedule or write access to anything, you built a chatbot with notes, which is fine. Just don't expect it to do anything while you're asleep.

It is not an autonomous employee. That framing invites scope you should refuse: an agent that decides its own goals, expands its own permissions, or acts irreversibly without being asked. Everything in this course is the opposite of that. The agent's goals are the ones you wrote down. Its permissions are the ones you granted, one tool at a time, read before write. Its irreversible actions are the ones you explicitly allow-listed. "Standing" describes when it runs (continuously, on a schedule), not how much authority it has. Those are independent variables, and conflating them is how people end up with an agent that emailed a client at 3am on its own initiative.

It is also not a framework you install. The next section argues that point directly.

The trust boundary: what it reads, what it writes, what it asks about

Before writing a single line of code, decide three things about your agent, because every later lesson assumes you already have answers:

1. What can it read by default? Start here: everything you'd hand a new contractor on day one, and nothing you wouldn't. Calendar metadata, yes. Bank statements, no. Not because the agent is untrustworthy in some abstract sense, but because read access is the ceiling on what can leak through a bug, a prompt injection, or a logged transcript. You cannot leak what you never granted read access to.
2. What can it write, and where? Write access is a strictly smaller set than read access, and it should be a list you can recite, not a vague "it has my API keys." Lesson 4 formalizes this as a wrapper pattern: the agent never holds a credential, it calls a local CLI that holds the credential and enforces the allow-list.
3. What must it ask about before acting? Some actions are reversible and low-stakes (draft a summary, append a memory entry): let those run unattended. Some are irreversible or externally visible (send an email, delete a file, spend money): those get a confirmation step or stay off the allow-list entirely until you've watched the agent behave correctly for a while.

Write these three answers down. The requirements file below is where they go. Treat the boundary as a starting position, not a permanent contract. The direction of change matters more than getting it perfect on day one. Start narrow, watch the agent operate inside that boundary for real runs, and widen deliberately, one permission at a time, once you've seen it behave correctly at the current scope. Widening after evidence is a normal part of building this; starting broad because narrowing later "would be easy" is the mistake that produces an agent you can no longer fully account for.

Why build your own instead of adopting a framework

The tempting shortcut is to install an existing "AI agent" framework (memory included, tools included, scheduling included) and configure it. Three concrete costs make that a bad trade for a personal standing agent, argued from mechanism, not from general suspicion of other people's code:

• Audit surface. A framework that gives you memory, retrieval, tools, and scheduling in one package is, conservatively, several thousand lines you did not write and probably will not read. Your own version of the same four components, built lesson by lesson in this course, stays in the hundreds of lines: small enough that you can read every line that touches your credentials and your data before it runs. "I trust it because I audited it" is only available to you if the audit is actually feasible.
• Permission explicitness. Frameworks default to broad capability because broad capability demos well and serves the largest number of users. Getting from "broad capability" down to "only the three things I actually approved" means fighting the framework's defaults, which is harder than starting from zero and adding only what you need. Building your own means every permission the agent has is one you wrote down on purpose.
• Ability to change it. When a framework's memory format doesn't fit how you actually think, or its scheduler doesn't support the trigger you want, you are stuck with an issue tracker and a maintainer's roadmap. When you own three files and a cron entry, you edit the file.

This is not an argument that all frameworks are bad software. Many are well-engineered for their actual target, which is teams shipping a product to other people. It is an argument that a framework optimized for breadth of use case is the wrong tool for one person's personal standing agent, where the design goal is the opposite: minimum surface, maximum legibility, permissions you personally granted one at a time.

There is a second, quieter cost: composition. A framework's memory format, tool-calling convention, and scheduler are usually coupled to each other and to the framework's own abstractions. Swapping out just the retrieval piece for something better a year from now means understanding how the framework wires retrieval into everything else first. Four small, separately-understood pieces you wrote (a memory format that's just markdown, a search module that's a few hundred lines of TypeScript, a wrapper CLI per tool, a cron entry) compose loosely enough that you can replace any one of them without touching the other three. That property, not raw line count, is the real payoff of building it yourself.

What each component looks like when it's real, not abstract

The four components sound abstract until you see them as files and processes. This is the concrete shape they take by the end of this course. Nothing here is speculative, every row is something you build in a specific later lesson:

Notice none of these require a database server, a message queue, or a hosted service. Files on disk, one CLI process per tool, one cron entry. That is a deliberate consequence of the audit-surface argument above: every piece stays something you can cat and read in under a minute.

None of this rules out scaling up later. If your memory files grow past what plain search handles well, lesson 3 covers embeddings, still local, still a file on disk, just a different search strategy over the same three markdown files. If one tool integration turns out to need more than a CLI wrapper, the wrapper pattern from lesson 4 still applies; you just write a second wrapper. The point of starting minimal is not that you'll never grow past it. It's that every step of growth stays deliberate and legible, instead of inherited wholesale from a framework's defaults on day one.

A day in the life, concretely

Here is the loop running once, for a specific, small agent: one that tracks open pull requests and reports what's waiting on you. This is the level of concreteness your own requirements file should aim for.

Decide now: two things happened since yesterday's snapshot. PR #38 merged. PR #42 got a new review comment. Which one, if either, is worth a message that interrupts you?

PR #38's merge is the outcome the open PR was always heading toward; nothing about it needs a decision from you, so the correct move is silence. PR #42's new comment is information a human hasn't seen yet, exactly what the "tell me" threshold exists to catch. Message on both instead, the tempting safe default, and you pay for it the way the opening scene already warns about: a channel that pages you on routine outcomes trains you to stop reading it, and the day a comment genuinely needs a same-day reply, it sits in the same feed as every routine merge nobody needed to see.

Nothing here required the agent to be clever. It required the four components to be wired together correctly, and a clear rule for when silence is correct (PR #38, routine) versus when a message is warranted (PR #42, needs you). That rule lives in the "Report style" section of the requirements file below. Write it down now, refine it once you've watched the agent run for a week.

Notice too what did not happen in the trace: the agent did not decide on its own to comment on PR #42, close it, or message anyone other than you. It read, it noticed, it told you. Every write it could have made stayed off the table because this particular agent's requirements file never granted it. That restraint is not the agent being cautious by nature. It is the direct, mechanical consequence of a tool wrapper that simply does not expose a "comment on PR" function yet. Lesson 4 covers why that's a wrapper design choice, not a prompt instruction you hope the model honors.

Faded case

Skip to the open case if this is familiar. A second agent watches nightly deploys instead of pull requests. It wakes on its own schedule. REMEMBER loads yesterday's snapshot: the last deploy went green, no open issues. RETRIEVE searches episodic.md for the last few deploy outcomes, looking for a pattern like "this slot fails most nights this happens." ACT calls a deploy-status wrapper and gets back two facts: the earlier deploy went green, and the later deploy is still marked running, well past when it usually finishes.

Decide now: given those two facts, does REPORT send you a message, stay silent, or do something else?

Open case

Your own agent, built from Exercise 1's filled-in agent/REQUIREMENTS.md, wakes up for its first real run. No trace is handed to you this time. Using nothing but the shape of this lesson's loop and your own Report style rule, decide for yourself what counts as routine (stays silent) and what counts as new (sends a message) for the specific task you wrote down. Exercise 4 below asks you to write that trace out in full.

Further Reading

• Anthropic: Effective Harnesses for Long-Running Agents: the state-management and verification arguments this course extends to a standing, scheduled agent.
• OpenAI: Harness Engineering — Leveraging Codex in an Agent-First World: the harness-vs-model distinction this lesson's "same model, four bolted-on components" framing builds on.

Key Takeaways

• A standing agent is the same model plus four bolted-on components: persistent memory, retrieval, tools, and a schedule. Remove any one and it degrades to something else (a diary, a blind rerunning script, a chatbot, a one-shot tool call).
• The loop is Remember → Retrieve → Act → Report. Every lesson after this one builds one stage.
• "Standing" describes when it runs, not how much authority it has. Scheduling and permission scope are separate design decisions: decide both.
• Write down what the agent may read, may write, and must ask about, before you write any code. This is the trust boundary and it constrains every later lesson.
• Build your own over adopting a framework for three concrete reasons: audit surface, permission explicitness, and your own ability to change it later.

What You Have Now

An architecture sketch and a requirements file describing the agent you specifically want.

Example Files

agent/REQUIREMENTS.md

Fill in every section before lesson 2. This file is the single source of truth for what your agent is allowed to do. Later lessons' code reads its intent from here.

# Standing Agent Requirements

## Purpose
<One sentence: what job does this agent do for you specifically?
Bad: "help me with things." Good: "track my open PRs across three repos
and tell me each morning which ones are waiting on me.">

## Trust boundary

### May read by default (no confirmation needed)
- <e.g. calendar event titles and times, not descriptions>
- <e.g. GitHub PR status and review state for repos I list>
- <...>

### May write, and where (explicit allow-list)
- <e.g. append entries to agent/memory/episodic.md>
- <e.g. post a comment on a PR I own, never on PRs I don't>
- <...>

### Must ask before acting (confirmation required every time)
- <e.g. sending any email>
- <e.g. anything that spends money>
- <e.g. anything that is hard to undo>

### Never allowed
- <e.g. reading files outside agent/ and the repos it's told about>
- <e.g. holding or printing raw API keys or tokens>

## Schedule
<How often does it wake up, and what triggers it?
e.g. "every weekday at 8am via cron, plus on-demand when I run it manually.">

## Report style
<When should it interrupt you vs. stay silent?
e.g. "only message me if a PR has been waiting on my review for >2 days;
otherwise just update the memory file and exit quietly.">

## Out of scope for v1
<What are you deliberately NOT building yet? Naming this prevents scope
creep into "autonomous employee" territory before you've built the basics.
e.g. "no autonomous replying to messages, no financial actions, no
multi-agent delegation.">

Where the rest of this course takes you

This lesson is the only free one. It has to stand on its own, so read it as the whole map even if you go no further. If you do continue, the next seven lessons build the four components in the order the loop needs them: memory first (lessons 2-3), because retrieval and tools are both pointless without something worth retrieving or acting on. Then tools (lessons 4-5), because a schedule with nothing to act through is just a timer. Then the schedule itself and the trust hardening around it (lessons 6-8), because you only want to automate a loop you've already watched behave correctly by hand.

By the end, you hold a running agent, not a set of slides about agents. Every lesson's "What You Have Now" section names a specific file or script sitting in your repository: the course's own deliverable-per-lesson principle, applied to itself.

Exercises

1. Copy agent/REQUIREMENTS.md into your own repository and fill in every section for an agent you actually want to build over the rest of this course. Be specific in "Purpose": if you can't state the job in one concrete sentence, the scope is still too vague to build against.
2. Redraw the architecture diagram from this lesson for your specific agent: replace the generic tool box with the actual 1-2 tools you listed under "May read by default," and note which stage (Remember/Retrieve/Act/Report) each one participates in.
3. For each item in your "Must ask before acting" list, write one sentence explaining what could go wrong if that item were moved to the unattended allow-list instead. If you can't articulate a concrete failure, reconsider whether it needs confirmation at all. The list should be short and load-bearing, not defensive padding.
4. Walk through the "day in the life" trace above and rewrite it for your own agent's first scheduled run: what does it load in Remember, what does it search for in Retrieve, which single tool call does Act make, and what is the exact rule that decides whether Report messages you or stays silent.

Check your understanding