How lane context works
ADE keeps the context it injects local to the work being done. When an agent starts in a lane, it receives:- Lane and session state — the lane’s branch, base, intent (as you have set it), and the current session’s metadata.
- Selected artifacts — any artifacts you have attached to the session, plus worker run details when the session belongs to a worker run.
- Explicit instructions — the prompt you send and any standing instructions for the lane.
This is a deliberate design choice. Generated summaries go stale the moment the code changes; direct repo inspection is always current. ADE injects the minimum lane/session context an agent needs to orient, and trusts the agent to read the repo for everything else.
Editing the lane intent
The lane intent is a short statement of what the lane exists to accomplish. ADE derives an initial intent from the branch name and early commits; refine it to be specific — a precise intent meaningfully improves agent behavior. Weak:Fix auth
Strong: Add a refresh token endpoint (POST /auth/refresh) that validates, rotates, and returns a new access/refresh token pair. The login endpoint must also return a refresh token.
Edit the intent in the right inspector. The intent is also used to pre-fill PR titles and descriptions.
Audit and replay artifacts
ADE stores a small set of compatibility artifacts under.ade/artifacts/packs/ for audit and replay. These are records of what happened — they are not automatically prepended to all agent prompts as ambient context, but specific packs are explicitly provided to the relevant agent when needed (for example, the Conflict Pack is handed to the resolver agent when resolving a merge conflict):
These files are plain Markdown / JSON. You can read them in any editor, diff them across versions, or use them outside ADE.
Next Steps
Lane Overview
Learn how lanes isolate work, state, branches, and agent sessions.
Agent Context
Understand how agents manage context windows and inspect repo context.