Skip to content
MenuClose
Register interest

A desktop workspace for Claude and Codex.
Project context, agent sessions and human review.

Skip to documentation
Project context

AigentFlow Desktop is in pre-release. This documentation reflects the current build and will change before general availability.

Keeping control

Project context

A project keeps its own notes on disk, next to the code, in a folder you can read. Decisions survive the session that made them.


Each project can hold an .aigentflow/ folder. It is plain markdown and JSON, readable and editable by you, and it is where the project remembers itself.

The planning files

Seven files sit directly in the folder. Each appears when something writes to it, so a project only carries the ones it has actually needed.

.aigentflow/
  DISCOVERY.md      what the project is and what was found
  CODEBASE_MAP.md   the shape of the code
  CONTEXT.md        the working context for the project
  DECISIONS.md      what was decided, and why
  REQUIREMENTS.md   what has to be true
  ARCHITECTURE.md   how it is put together
  ROADMAP.md        phases and tasks

What else the app writes there

  • STATE.md, a short record of where the work got to.
  • handover/, a handover document written when the context window is close to full.
  • goals/, an append-only log of a goal: what you asked, what was planned, which member did what, and how it ended.
  • reports/, an execution report for each completed member task, and a readable report for a goal.
  • roadmap/ and execution/, the task files and journals behind the task system.
  • autonomous/, the plan behind a phase run, kept both as data and as a readable document.

The wizard adds .aigentflow/ to the .gitignore it generates. If you would rather commit the project’s memory alongside its code, remove that line.

How context actually reaches an agent

Four separate routes, which is worth knowing because they behave differently.

  1. CLAUDE.md and AGENTS.md in the project root are read by the agent itself, as they would be in any project.
  2. A team member is given the working context, architecture and decisions files inline in its first message, because it never sees the conversation that produced its task.
  3. The count of active constraint rules travels with every instruction you send.
  4. Learnings are injected once, on the first instruction of a session.

Syncing the project writes your constraint rules into CLAUDE.md. That is how a rule reaches an ordinary session at all.

Drift

The app can compare what your context and decisions files claim about the project’s dependencies against what is actually installed, and report where the two have drifted apart.

Staying inside the project

Every path the app builds, or an agent proposes, is checked before it is used. A path that climbs out of the project, a drive-qualified or network path, or a link inside the project pointing somewhere outside it, is refused. For paths the model chose the check runs twice: once on the text, and again on the resolved real path.