Skip to content

Directive changes require 7-step git workflow to reach running agents #685

@laynepenney

Description

@laynepenney

Problem

Changing a team directive (CLAUDE.md, AGENTS.md, process policy) requires a 7-step workflow before running agents see it:

  1. Edit the file
  2. Commit
  3. Push
  4. Create PR
  5. Merge
  6. Communicate to agents (channel post, verbal, etc.)
  7. Each agent syncs (pulls, rebases, or restarts)

That's massive friction for a one-line policy change. And the failure mode is silent: if an agent doesn't sync, they operate on the old directive until they violate the new policy and get corrected manually.

Why it's worse than it looks

  • Agents run on different worktrees and branches. A merge to main doesn't reach an agent on sprint-18 until they rebase.
  • Mid-session changes are invisible. Agents read CLAUDE.md at session start; changes after that are missed.
  • There's no verification that an agent received the update. You find out when they break the new rule.

Options to explore

A: Channel-first delivery

Post directive changes to #dev as directive message type. Agents see it on next channel poll (1-2 min). Git commit is the durable record; channel is the delivery mechanism. recall_channel(action="directive") exists but agents don't treat those as persistent behavior changes.

B: Recall knowledge as live layer

Store directives as knowledge nodes (directive category). Agents search recall before acting. New directives propagate through the shared recall index (no git sync needed). Git stays canonical; recall is distribution.

C: Hot-reload from shared path

CLAUDE.md is at gripspace root (shared across worktrees). Add a file watcher or /reload-directives skill that forces re-read mid-session when the file changes.

D: Structured state layer (Neotoma-style)

Versioned entity store all agents read from. Change in one place, all agents see on next read. No git workflow for operational state.

Context

This came up during a Neotoma.io evaluation. Cross-agent state synchronization is exactly the problem structured state layers claim to solve. The current git-based approach treats directives as code (versioned, reviewed, merged) when they behave more like operational state (needs instant propagation, no review gate).

The right answer is probably a hybrid: git for durable policy, with a fast propagation layer (channel, recall, or dedicated directive store) for immediate delivery.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions