# Mission-Based AI Agents vs. Persistent Assistants There are two fundamentally different ways to think about AI agents in an organization. One model treats the agent as a long-lived assistant or teammate that gradually accumulates context, relationships, and access over time. The other treats the agent as a temporary specialist dispatched for a specific mission, given exactly what it needs, and then sent home. These are not just different implementation choices. They represent different philosophies about trust, accountability, and risk. ## The persistent assistant model In this model you tend to see: - One (or a few) agents that live for weeks or months - Broad and growing access as people ask it to do more things - Long conversation histories used as "memory" - The agent is expected to "know the team" and "know the codebase" - People interact with it somewhat like a colleague who never leaves This model is appealing because it feels like having an extra team member. It is also the model that creates the largest possible blast radius when something goes wrong. ## The mission model In the mission model: - Every piece of work is a discrete mission with a declared purpose - The agent receives a complete contract (persona, tools, policy, secrets, TTL) for that mission - When the mission ends, the execution environment ends - State that should survive is explicitly captured and passed to future missions - Different missions can have completely different capabilities and constraints You don't have "the dev agent." You have "the agent that was launched with the dev-agent recipe on this specific branch at this time with these constraints." ## Why the difference matters for security A persistent assistant that has slowly gained access to many systems over months is extremely difficult to reason about. What exactly can it do right now? Which old permissions has it never dropped? If its context gets poisoned, what systems are in scope? A mission-based agent has a much smaller and more explicit scope by construction. The recipe that launched it is the source of truth for what it was allowed to touch. This makes reviews, audits, and incident response dramatically simpler. ## The "but we need continuity" objection The main argument for persistent agents is that real work is continuous. A developer agent might work on a feature across several days. A researcher might need to build understanding over multiple sessions. This is true. The question is whether continuity requires a single long-lived process holding access the entire time. You can have continuity through explicit state handoff instead of process lifetime. Previous work is captured. Future missions receive relevant context. The executing environment itself remains short-lived and narrowly scoped. This is closer to how competent human organizations actually handle sensitive work. ## Different missions deserve different power Another advantage of the mission model is that you stop trying to build one agent that is good at everything. You can have: - A researcher that is read-only and has a short TTL - A dev agent that can write code and open PRs but only on specific repos - An ops agent that can run certain commands but is heavily restricted on what it can touch - A one-off agent for a specific compliance task that will never be used again Each of these can be defined by a different recipe with different constraints. You do not have to give the researcher the same power as the ops agent just because they are "the same kind of thing." ## Culture and accountability Persistent assistants encourage a culture of "ask the agent." Missions encourage a culture of "define the work, dispatch the capability, review the result." The second culture aligns better with how we already manage other high-power tools (deploy keys, service accounts, break-glass procedures, etc.). It also makes it easier to answer the question that security teams actually care about: "What exactly did this agent do, and what was it allowed to do when it did it?" ## Pick the model deliberately Many teams end up with persistent agents by default because that is what the first framework they tried made easy. They did not make a conscious choice about the trust model. If your agents touch anything that matters, the choice between "long-lived assistant with accumulating power" and "short-lived specialist with an explicit contract" is one of the highest-leverage decisions you will make. Choose consciously. The persistent model is convenient until it isn't.