The Always-On Agent:
Long-Running Processes That Learn Over Time

The context tax

Every time you spin up a fresh sandbox, the agent starts from zero. It clones the repo. It reads the codebase. It discovers the test suite. It figures out the architecture. This "context acquisition" takes 5–15 minutes. For a 30-minute task, that's 25–50% of the run wasted on orientation.

A human employee doesn't re-learn the codebase every morning. They walk into their office, open their laptop, and their IDE has the same tabs open, the same terminal history, the same bookmarks. They remember what they tried yesterday that didn't work. They know which tests are flaky. They have a mental model that took weeks to build.

An always-on agent has the same advantage. Its sandbox persists. The repo is already cloned. The dependencies are already installed. The notes from yesterday's work session are in a file it reads first thing. It doesn't waste time rebuilding context — it just picks up where it left off.

The contractor model vs the employee model

The guides in this series so far have described contractor agents. They show up, do a specific job (review this PR, research these competitors, process this spreadsheet), deliver the result, and leave. You pay for the hours they work. They're efficient for bounded tasks with clear inputs and outputs.

But some work isn't bounded. Building a new feature takes days. Growing a research database takes weeks. Learning a codebase well enough to make good architectural decisions takes time. These are employee-shaped problems, not contractor-shaped problems.

What accumulates: why persistence matters

The value of an always-on agent isn't just "it doesn't re-clone the repo." It's the knowledge that builds up over time and makes each day's work better than the last.

Working notes

The agent maintains a progress file: what it tried, what worked, what didn't, what's blocked. On Day 1, it explores the codebase and writes notes. On Day 3, it reads those notes and skips the blind alleys it already identified. A human engineer does the same thing — they just keep the notes in their head.

Accumulated git history

Every change the agent makes is committed. After three days, there's a detailed git log of every approach attempted, every refactor completed, every test added. If a human reviewer wants to understand the agent's reasoning, the commits tell the story.

Learned patterns

The agent discovers that the CI takes 4 minutes to run, that the database migration script is in scripts/migrate.sh, that the team uses a specific naming convention for API routes. These aren't in any documentation — the agent learned them by working in the codebase. Ephemeral agents lose this knowledge every run.

Intermediate artifacts

A research agent building a competitor database creates intermediate files: extracted pricing data, normalized feature lists, cross-reference tables. Each day's run adds to these artifacts. A weekly synthesis is better than a daily one because it draws on 7 days of accumulated data.

Five use cases where persistence changes everything

1. Multi-day feature development

Building a complex feature — a new billing module, a migration from REST to GraphQL, a redesigned permission system — takes 3–5 days. An ephemeral agent would need to understand the entire codebase from scratch each morning. A persistent agent spent Day 1 exploring the codebase, Day 2 writing the core implementation, and Day 3 testing. Each day builds on the last. Total cost: ~$1.00 for 3 days of compute. Model costs dominate, not infrastructure.

2. Growing a knowledge base

A competitive intelligence agent that runs daily doesn't just report today's changes. Over weeks, it builds a local database of competitor pricing history, feature evolution, and positioning shifts. Ask it "when did Linear first add AI features?" and it can answer from its accumulated data, not from re-scraping.

3. Infrastructure monitoring

An agent that checks your production dashboards hourly learns what's normal. "CPU at 80% on Tuesdays at 3pm" is the weekly batch job — not an alert. "CPU at 80% on a Saturday at 3am" is anomalous. The agent's accumulated context reduces false positives because it's seen the baseline patterns over weeks.

4. Onboarding to a new codebase

Drop Claude Code into a persistent sandbox with a large codebase. Day 1: it reads the README, explores the directory structure, runs the test suite. Day 2: it understands the architecture well enough to answer questions. Day 3: it can make changes with confidence. You're onboarding a new team member — it just happens to be an AI.

5. Long-running test or migration suites

Some tasks genuinely take 6–12 hours: full regression suites, database migrations on large datasets, model fine-tuning. The sandbox runs overnight. You check the results in the morning. The persistent filesystem means the output is right where the agent left it.

The cost comparison

At $7.26/month, an always-on agent with 8 active hours per day costs less than a single lunch. The model inference costs (Claude API) are typically 5–10x the compute costs, so the total is $40–80/month for a persistent AI employee that works every day, remembers everything, and never takes a sick day.

Compare to the ephemeral alternative: running the same 8-hour task fresh every day would cost the same in compute, but waste 15–30 minutes per run on context rebuilding. Over a month, that's 8–15 hours of wasted work — the agent spinning its wheels re-learning what it already knew.

The human-agent workspace

The most underappreciated feature of persistent sandboxes: they're shared workspaces. The agent works in the sandbox. You can SSH in, review its work, make corrections, and leave notes. The agent reads your notes the next time it runs and incorporates your feedback.

This is how you manage an AI employee. You don't micromanage every action. You check in periodically, review the work, course-correct when needed, and let the agent continue. The persistent sandbox is the medium for this collaboration — the files, the git history, the working notes are the shared context between human and agent.

The sandbox is the agent's desk. You can walk over, look at what's on the screen, leave a sticky note, and walk away. The agent reads the note and adjusts.

When not to use always-on agents

Persistence has costs. Be honest about when ephemeral is better:

• Bounded tasks with no carryover. Reviewing a PR, processing a CSV, checking a website — these don't benefit from persistence. Use ephemeral.
• Parallelizable workloads. 50 browser containers running in parallel don't need shared state. Each is independent. Ephemeral is cheaper and simpler.
• High-security tasks. If the task involves sensitive credentials that should not persist on disk, ephemeral sandboxes that are destroyed after use are more secure.
• When the agent is unreliable. If the agent's work quality degrades over a multi-day session (context window limits, compounding errors), daily fresh starts with good task descriptions may produce better results than persistence.

The rule of thumb: if the task benefits from the agent having done the same task yesterday, use persistent. If each run is independent, use ephemeral.

Where this goes: agents with months of context

Today's always-on agents persist for days or weeks. The context window limits how much accumulated knowledge the model can use in a single conversation. But context windows are doubling every 6 months. Claude's context went from 100K tokens (2024) to 1M tokens (2026). At this rate, by 2027, an agent could hold months of working context in a single session.

When that happens, the always-on agent becomes something new: a team member that has been on the project since Day 1, remembers every decision, every tradeoff, every bug that was fixed and why. The persistent sandbox provides the filesystem and the institutional memory. The model provides the reasoning. Together, they create an AI employee that genuinely improves with tenure — just like a human.

The companies building persistent agent workflows today are establishing the infrastructure, the supervision patterns, and the organizational habits that will compound as models get better. Start with a 3-day feature project. Then a 2-week research initiative. Then an ongoing monitoring role. Each step teaches you how to manage AI employees that persist.

What's next