Persistent AI agents continue through saved state, not endless thinking
A persistent AI teammate can pick up a continuing responsibility across separate sessions. It relies on saved instructions, conversation, work state, source references, artifacts, and corrections. It does not need to run continuously or remember every detail on its own.
The practical promise is simple: when you return to the job, you should not have to reconstruct the entire operating brief from scratch.
Persistence is useful for work that develops over time:
- an LP shortlist changes as the fund strategy becomes clearer;
- a manager brief needs new evidence before a later meeting;
- a diligence question remains blocked until a document arrives;
- a relationship owner corrects how an introduction path should be handled;
- a weekly review carries unresolved commitments into the next cycle.
It is also easy to misunderstand. Persistent responsibility does not mean perfect memory, constant computation, permanent factual accuracy, or unlimited authority.
What must persist
Five kinds of continuity support a useful teammate.
1. The responsibility
The standing job should survive the end of one conversation.
Example:
Maintain a sourced shortlist of LPs that fit Fund III's documented strategy. Preserve exclusions, check existing CRM records, and flag facts that need revalidation.
2. The current state
The system should distinguish what is complete, open, blocked, awaiting review, paused, or superseded. A paragraph summarizing "progress" is weaker than explicit state tied to a specific item.
3. The artifacts
The brief, shortlist, decision table, question log, or draft should remain available as the work product. Later work can refer to the artifact rather than an unreliable reconstruction of it.
4. The correction
A user correction should be applied at the right layer. A changed fact belongs in the source-backed artifact or record. A lasting preference may belong in the teammate's standing instructions. A revised access policy belongs in actual permissions.
5. The provenance
Time-sensitive claims need a source and observation date. Persistence without provenance turns old information into durable ambiguity.
A four-session LP research timeline
Consider a GP using a teammate to maintain an LP research shortlist.
| Session | What happens | What should persist | What must be rechecked later |
|---|---|---|---|
| 1. First assignment | The GP defines strategy, allocator types, exclusions, and output fields | Responsibility, criteria, source requirements, and first shortlist | Current mandate and program availability |
| 2. User correction | The GP explains that a stated geography is a preference, not a hard exclusion | Revised instruction, correction note, and affected shortlist items | Whether the public source still describes the geography the same way |
| 3. Later review | The teammate updates the shortlist, checks CRM duplicates, and flags two changed roles | Updated artifact, prior decision, source dates, and unresolved items | Employment, titles, and institution policies |
| 4. Weekly routine | The teammate reports three updated prospects and one blocked record | Run state, returned work, blocker, and next human decision | Any fact whose freshness threshold has expired |
Nothing in this timeline requires one model to "think" for several weeks. The continuity comes from explicit instructions and artifacts bridging the work.
Anthropic's research on long-running agent harnesses describes a similar technical principle in software development: complex work spans discrete sessions, so agents need clear artifacts and state that help the next session continue. That research concerns coding agents, not private-capital workflows or Aurora performance. The transferable lesson is that continuity must be designed.
The CONTINUE framework
Use the CONTINUE framework to evaluate whether a persistent teammate can resume responsibly.
- Contract: Is the continuing responsibility explicit?
- Observed state: Can the user see what is ready, open, blocked, or paused?
- Named sources: Are important claims tied to retrievable evidence?
- Time: Does each changing fact have an observation or verification date?
- Instructions: Are lasting preferences distinct from one-off edits?
- User decision: Is the next human review point visible?
- Next trigger: Is it clear what causes the job to resume?
- Expiry: Which state, evidence, or instruction should be revalidated or retired?
A teammate that cannot answer these questions may preserve conversation history without preserving operational continuity.
Persistence is not one big memory
Treating all history as one growing memory creates several problems:
- temporary prompts can become apparent permanent facts;
- old research can be repeated without a freshness check;
- a model inference can lose its uncertainty label;
- a correction to one artifact can accidentally become a broad rule;
- irrelevant detail can crowd out current evidence;
- users may not know where to correct or remove information.
A better model separates:
| Layer | What it carries | Example |
|---|---|---|
| Standing instructions | How the teammate should perform its job | "Use official sources for current program eligibility." |
| Conversation | The ongoing interaction around the responsibility | The GP's clarification about geographic preference |
| Work state | Status of a specific run or item | Two prospects ready, one awaiting source verification |
| Artifact | The reviewable output | The dated LP shortlist |
| Durable record | Approved relationship or deal information | CRM owner, stage, verified preference, or completed action |
| Source evidence | The basis and observation date for a claim | Official program page checked September 27, 2026 |
These layers may live in different parts of a product. The important operating rule is that the user can tell which layer changed.
For the deeper retain, retrieve, verify, and forget model, read AI Agent Memory for Relationship Workflows. This article owns the continuity question. The memory guide owns the governance of durable relationship information.
Facts have different freshness windows
Persistent teammates should not treat every saved fact as equally durable.
| Information | Typical change risk | Sensible handling |
|---|---|---|
| User's preferred output format | Low until the user changes it | Keep as a standing instruction and make it editable |
| Fund strategy supplied by the GP | Medium, especially during fundraising | Attach to an approved source and recheck after a strategy update |
| Person's current title | High | Preserve observation date and reverify before consequential outreach |
| Allocator program eligibility | High | Recheck the official program source before recommending action |
| Introduction permission | Specific to the request | Record the actual consent state, never infer it from relationship history |
| Draft message | Short-lived | Treat as an artifact awaiting review, not a completed action |
Freshness policies depend on the job. A weekly pipeline review and an annual market map should not use the same threshold.
How Aurora Agents create continuity
Aurora is the permanent primary identity in Finta. Optional Aurora Agents can have a named responsibility, editable instructions, a character, owned routines, and one persistent primary conversation.
Those elements create distinct forms of continuity:
- Name and character: make the owner recognizable.
- Instructions: preserve how the user wants the recurring job performed.
- Conversation: provides a stable place to return, review work, and give corrections.
- Owned routine: gives the job a supported recurring trigger and returns work to the responsible agent.
- Run state: distinguishes execution and reporting for a particular assignment.
The agent identity is not a separate permission silo. Aurora Agents use the same authorized Finta workspace environment. Do not create one named agent per client, family, fund, or mandate and assume the names isolate their information. Use actual workspace and access controls for separation.
Product capabilities, supported routine schedules, connections, and action controls can change. The evergreen principle is that a persistent teammate needs explicit responsibility, state, artifacts, and review regardless of the interface used to provide them.
Design the handoff to the next session
Every meaningful run should leave a short receipt:
- Assignment: What responsibility and trigger produced this work?
- Sources: Which records, documents, or public sources were used?
- Output: Which artifact was created or updated?
- State: What is ready, open, blocked, or awaiting review?
- Decision: What does a person need to approve, correct, or decide?
- Next trigger: When should the teammate return to the work?
Example:
LP shortlist review completed. Twelve records checked. Two official program pages changed. One prospect remains unverified because the relevant mandate page is unavailable. No CRM records or messages were changed. Review the two updated fit rationales before the next pipeline meeting.
This receipt is more valuable than "Task complete" because it preserves evidence, scope, and the next decision.
Know when not to persist
Some information should not carry forward by default:
- an unsupported inference about a person's interests;
- a private detail unrelated to the continuing job;
- a superseded draft treated as current;
- a temporary instruction that conflicts with policy;
- untrusted external content inserted into standing instructions;
- a one-time introduction permission generalized to future requests;
- stale market or personnel information without provenance.
Persistence creates value only when correction, expiry, and deletion are possible. The goal is not maximum memory. It is sufficient, explainable continuity.
A review checklist for long-running responsibilities
Before relying on a persistent AI teammate, confirm:
- The continuing responsibility is narrow and current.
- The output and quality standard are explicit.
- Source types and access boundaries are defined.
- Important facts carry provenance and an observation date.
- Ready, blocked, and awaiting-review states are distinguishable.
- A user can correct the artifact and the standing instructions separately.
- External actions and consequential decisions have named human owners.
- The routine or trigger can be paused.
- Expired evidence can be revalidated or removed.
- The next run will receive a useful handoff rather than an opaque transcript.
Give continuity to the responsibility
Do not ask whether the model can remember everything. Ask whether the work can resume safely and usefully. Preserve the job, the evidence, the artifact, the correction, the state, and the next human decision.
Use How to Delegate Work to an AI Teammate to define the responsibility, then see AI Agent Routines for giving recurring work a cadence. The broader AI Teammates for Private Capital guide can help choose which role should own it.
Explore Aurora to see how available relationship context becomes reviewable work inside Finta.
Research checked September 27, 2026. Persistence, memory, permissions, schedules, and supported tools vary by product and configuration. The LP timeline and receipts are illustrative. They are not customer results, investment advice, or a promise of continuous or error-free agent operation.