Fundraising Operations
Maintain an AI Agent’s Source Freshness
Keep reused agent facts current with a source-expiry register and an impact queue for outputs that need review.
What you will learn
- Keep standing instructions separate from dated facts.
- Maintain source owners, review triggers and dependent output IDs.
- Recheck and inspect affected artifacts without claiming automatic monitoring.
Keep an agent's standing instructions stable and manage dated facts in a separate source-expiry register. For every reusable source, record its owner, last check, next review or change trigger and the outputs that depend on it. When a source expires or changes, hold the affected claims until someone rechecks them.
Source check: October 22, 2026. The register and impact queue below are a manual operating worksheet. They are not a claim that Aurora automatically monitors websites, expires memory, updates every draft or sends change alerts. Current connected access and remembered context still depend on the authorized account, organization and settings.
Separate a standing job from a dated fact
“Prepare a sourced relationship brief for my review” is a standing responsibility. “The application deadline is Friday” is a dated assertion. Rewriting the responsibility every time a fact changes mixes instructions with evidence and makes stale statements harder to find.
Give the fact a source ID instead. Keep its exact meaning, scope and date in the register, then cite that ID in reusable output packets. A manual spreadsheet or document is sufficient. An expiry flag is a review decision, not proof that the old statement is false.
The maintained source-expiry register
| Field | Record | Why it matters |
|---|---|---|
| Source ID and claim scope | [Stable ID; exact fact, audience and conditions] | Prevents a narrow source supporting an oversized claim. |
| Primary source and version | [URL/document; date or version; permitted excerpt] | Lets the owner repeat the check. |
| Checked at and by | [Date/time, reviewer and account/workspace where relevant] | Separates a real check from a copied citation. |
| Review rule | [Chosen next check date or observable change trigger] | Makes expiry a deliberate operating choice. |
| Owner | [Person accountable for revalidation] | A reminder without an owner does not resolve uncertainty. |
| Dependent outputs | [Brief, draft, task or approved wording IDs] | Finds work that may now be stale. |
| Disposition | [Current / needs check / changed / unavailable / retired] | Shows what may be reused and what must pause. |
Choose review rules by the claim. A program deadline, product availability and historical company fact do not need the same interval. There is no universal freshness period. A known source change can trigger an earlier check even when the planned review date has not arrived.
Operate an impact queue when something changes
- Detect or receive a trigger. A person notices a new primary source, an owner reports a change or a planned review date arrives. Do not imply automated detection unless separately verified.
- Mark the source needs check. Preserve the old checked version and reason for review. Stop reusing the affected assertion as current.
- List dependent outputs. Search your register for the source ID and inspect relevant briefs, drafts and scheduled work. Include missing links as an uncertainty rather than claiming full coverage.
- Recheck the primary evidence. Confirm scope, account, date and any conflicting source. Use the individual source verification worksheet for that investigation.
- Choose a disposition for each output. Reconfirm, correct, remove the claim, hold for review or retire the output. Assign a human owner to unresolved items.
- Inspect the result. Read the actual revised artifact. A corrected source row does not prove that a CRM record, saved memory, conversation or outgoing draft changed.
- Record the next rule. Add a short change-log entry with old meaning, new evidence, affected outputs, reviewer and remaining unknowns.
Fictional worked example: one changed program fact
The invented company Solace Tools keeps source S-17 for a fictional program's application window. On October 1, the official program page said applications were expected later in the month. That fact appears in a research brief B-4 and a founder task draft T-8. It does not establish a guaranteed opening date.
On October 15, the assigned owner sees an official update saying the window is delayed. The owner flags S-17 as changed and opens the impact queue. The company does not treat the old brief as current merely because its citation still opens.
| Affected item | Problem | Reviewed disposition |
|---|---|---|
| B-4 research brief | It suggests an opening window based on the older page. | Replace the sentence with the new status and retain both check dates. |
| T-8 task draft | It assumes an application can begin. | Hold the application task; propose a status recheck instead. |
| Untracked email draft | A reviewer remembers that it reused the claim. | Add it to the queue and inspect the actual text before use. |
The correction is complete only for the inspected artifacts. The owner records that the search for other copies may be incomplete. Nothing is sent, saved or automatically rescheduled in this fictional example.
Handle remembered and connected context separately
Connected tools can retrieve current information when permitted and available, but connection alone does not prove that the latest source was read. Ask which source version the actual output used. Remembered context can also be stale; its user/organization scope and settings remain relevant.
If a remembered fact needs correction, use the available controls and inspect a new answer. Do not infer global correction or deletion from a rewritten paragraph. The persistent context guide covers that layer; this register tracks ongoing ownership and downstream work.
Review prompt for the impact queue
Help maintain this manual source-expiry register in Aurora AI in Finta, Claude or Codex.
Register rows: [source IDs, claims, primary sources/versions, checked dates, owners, review rules and dependent output IDs]. Trigger or source change: [details]. Permitted artifacts to inspect: [details].
Return: sources needing review, claims that must be held, affected-output queue, recheck questions, proposed disposition for each item, and a short change-log draft. Distinguish an actual source check from a proposed one. Mark unavailable or incomplete evidence unknown.
Do not claim continuous monitoring, automatic memory expiry, complete downstream coverage or a corrected saved artifact without inspection. Do not save, send, change routines, connect accounts or update memory from this request. Ask the accountable owner to approve each consequential revision.Common questions
Is this a memory feature?
No. It is an operating register you maintain alongside the work. It helps decide which facts to check and which outputs may be affected; it does not claim automatic product enforcement.
Must every source have a fixed expiry date?
No. Use a date, a concrete change trigger or both. Record why the rule fits the claim and who will notice the trigger.
What if I cannot retrieve the source again?
Mark it unavailable and hold the unsupported current assertion. A previously saved excerpt can explain historical wording, but it cannot prove that a changing fact remains current.
Apply the register to the shared packet in one founder brief, three responsibilities, especially when several drafts reuse the same evidence.