Always-On Agent with Context vs. On-Demand Zero-Context Agent
There are two ways to use an AI agent on a real project.
The first: you open a session, paste in the relevant files, describe the problem, explain the architecture, summarize what was tried last time, and then ask your question. The agent does its job, the session closes, and the next time you come back you do it all again.
The second: the agent is already there. It knows the codebase. It knows what was decided last week and why. It knows which files matter, what the build process is, what "done" means on this project. You send one message. It gets to work.
Most people default to the first approach because that's how they started using AI. But if you're working on an existing project — anything with history, conventions, and decisions already baked in — the second approach isn't just more convenient. It produces meaningfully better results.
Here's why, and when the tradeoff actually flips.
What "Context" Actually Means in Practice
When engineers talk about context in the LLM sense, they usually mean the tokens in the current window. But in a project context, it's more specific than that:
- → Structural context: where things live, how the repo is organized, what the build and deploy processes are
- → Decisional context: why certain choices were made, what was tried and abandoned, what constraints exist
- → Operational context: what's currently broken, what's in progress, what the definition of done is for this sprint
- → Voice and style context: naming conventions, commit message style, code review norms, documentation tone
An on-demand zero-context agent gets none of this by default. A well-configured always-on agent carries all of it — either in a mission description, a CLAUDE.md file, or workspace memory built up over time.
The Cold Start Tax
Every on-demand session begins with a cold start. Before the agent can do useful work, it has to get oriented.
In practice, this means one of three things:
- You re-explain everything — the architecture, the conventions, the current state. This is the most common approach and it's expensive. The re-explanation is often incomplete, which introduces errors.
- The agent reads the codebase — which takes tokens and time, and still produces an incomplete picture without the decisional and operational context that isn't in the code.
- You provide a context dump — a long preamble you copy-paste at the start of each session. Better, but still manual and still missing the live state.
On a greenfield project or a one-off task, the cold start tax is fine. You pay it once, you get your answer, you close the session.
On an existing project — especially one with months of history — the cold start tax compounds. Every session has overhead. Decisions get re-litigated. The agent makes suggestions that were already tried and rejected, because it doesn't know they were tried. Consistency erodes.
What Always-On Actually Buys You
An always-on agent with well-maintained context eliminates the cold start entirely. More importantly, it changes the *quality* of what the agent produces.
It doesn't repeat mistakes. If the agent tried approach X last week and you rejected it, a zero-context agent will suggest X again next session. An always-on agent with workspace memory knows X was rejected and why. It doesn't waste your time.
It follows the project's actual conventions. Not generic conventions. Not what it infers from the first few files it reads. The real naming patterns, the real commit style, the real architecture decisions — because these are part of its standing context.
It produces coherent work across sessions. The blog post written in session 12 sounds like the blog post written in session 4, because the agent knows the voice. The component built on Tuesday follows the same patterns as the component built on Friday, because the agent knows the codebase structure.
It can self-assign. When the agent knows the project state — what's open, what's in progress, what's blocked — it can identify work proactively and queue it for review. A zero-context agent can only respond to what you ask in this session. It can't notice that the integration tests have been failing for three days.
Where Zero-Context Agents Still Win
It's not all one-sided. On-demand zero-context agents have real advantages in specific scenarios.
Exploratory or one-off work. If you're researching a library you've never used, evaluating an architecture option, or drafting a document that has no predecessors, context doesn't add much. The agent's general knowledge is what you need, not project-specific memory.
Isolation is the feature. Sometimes you want the agent to evaluate something without the bias of existing decisions. Fresh eyes. A zero-context agent genuinely doesn't know what you've already tried, and that's occasionally exactly what you want.
Simplicity of setup. For small teams or solo projects in early stages, maintaining workspace context is overhead that may not pay off yet. The cold start tax is low when there's not much history to carry.
Cross-project work. If you're jumping between multiple projects in a single session, context from one can bleed into another in ways that create subtle errors. Zero-context per project is sometimes the safer choice.
The Structural Reason Always-On Wins on Real Projects
Here's the core reason the always-on approach dominates on existing projects: the cost of context is front-loaded; the benefit compounds.
Setting up a CLAUDE.md file, a workspace mission description, or structured memory takes a few hours. You do it once. Every subsequent session runs with full context at zero marginal cost.
The cost of the zero-context approach is per-session. Every session pays the cold start tax. And as the project grows, that tax grows with it — because there's more history, more decisions, more conventions to re-explain.
This is a classic invest-now-pay-later vs. pay-every-time tradeoff. For anything that lasts more than a few weeks, invest-now wins.
What This Looks Like With AgentRQ
AgentRQ is built around the always-on model. Each workspace has a mission description — a standing brief that Claude Code reads before starting any task. It doesn't expire. It doesn't reset between sessions. It's there every time.
The mission description handles the decisional and voice context. The CLAUDE.md file (committed to the repo) handles the structural and operational context. Together, they eliminate the cold start for every task in that workspace.
The result is that a brief like "write a blog post about X" — four words — produces output that knows the site's voice, the SEO conventions, the converter workflow, and how previous posts were structured. Not because you re-explained it. Because the agent already knows.
A zero-context agent receiving "write a blog post about X" produces output that might be good on its own terms, but won't match the project's existing voice, won't follow the commit conventions, and won't know to run the converter before submitting.
Same model. Same capability. Dramatically different output. The difference is context.
Setting Up for Always-On
If you want to move from reactive, per-session agents to a persistent, context-aware setup:
- Write a
CLAUDE.mdat the project root. Cover: repo structure, build and deploy process, naming conventions, what "done" means. Keep it up to date as the project evolves. - Create a workspace mission description that covers the project's goals, constraints, and voice — the things that aren't in the code but that shape every decision.
- Use approval loops, not fully autonomous execution. The agent works continuously; you stay informed and in control. That's the human-in-the-loop part.
- Let memory accumulate. Over time, the agent builds up a picture of what works, what was tried, what the team prefers. That accumulation is the compound interest.
The on-demand approach feels simpler because each session is self-contained. The always-on approach feels heavier up front. But on a real project with real history, the always-on agent is doing fundamentally different — and fundamentally better — work.
The cold start is a tax. Stop paying it every session.