Long-running agents that stay on course

A long-running agent — a migration, a refactor, a research sweep — drifts across sessions. It forgets the constraints you set on day one, re-proposes approaches you already rejected, and loses track of what's done versus in-progress.

This tutorial shows how to give a returning agent a current project brief and a way to check what changed. Check its answers before it resumes consequential work.

What you'll need

Jackdaw connected to GitHub (or GitLab), and the Local Codebase source if you want the agent to see your files
Jackdaw connected to your AI over MCP or the coding-tool plugin
The task your agent will work on

Step 1: Capture your constraints before you start

Tell the assistant the hard rules for this project, one at a time:

"For the migration project: never modify files in services/node/src/app/core/ directly — those changes go through PR review. Always run pnpm test before marking a task complete. Prefer small, atomic commits."

Each one is captured as a typed constraint in the project’s current state. It can then be surfaced to the agent via get_context when relevant. For a rule that must be enforced, also configure the coding tool’s own guardrail or review gate; retrieved context alone does not enforce behavior.

Step 2: Write the project brief

In your Wiki, create or open the Project page for this run — something like "Migration: Node → Python services." Fill it in with:

Goal — one sentence
Scope — what's in, what's out
Decisions made — choices already locked in
Progress — what's done, what's next

The agent can read this page with read_evidence. Jackdaw does not generate the prose. A connected AI can edit an existing document page when asked, with cited changes and a History entry. It can also record direct, nonconflicting facts with remember; corrections and conflicts wait for review.

Step 3: Start the agent with a grounded prompt

Your first prompt should make the agent read its context before doing anything:

You're working on a multi-day migration. Before you start:
1. Call get_context with "what is the migration project and its current state?"
2. Read the project brief.
3. Summarize what you know and what you're about to do.

Don't start work until you've confirmed your understanding.

Step 4: End each session with an update

Before you close a session, have the agent record the durable changes it learned:

For each durable decision, constraint, or status change from this session,
call remember with the project name in the key and the precise value.
Show me what you saved or what is waiting for review. I will verify
the project brief before the next session.

Direct, nonconflicting facts can land in the Wiki under the agent’s name. Identity details, corrections, and conflicts wait in the Inbox. Verify what actually saved before the next session relies on it.

Step 5: Spot-check for drift

At the start of each session:

Before we continue, tell me from your context (don't guess):
1. What constraints apply to this project?
2. What did we complete last session?
3. What's next?

If the answers are right, you're in sync. If something's off, correct it explicitly so your wiki reflects the truth.

Why this works

The agent may lose its conversational history at a reset, but it keeps access to Jackdaw. The Wiki preserves the project’s current state, the decisions and constraints behind it, and the evidence returned by earlier work. A later run can ask for the current decision and evidence instead of relying only on its previous chat. It still needs to call Jackdaw and verify the answer when the choice matters.