Coordination / intent / transition

Projects don't compound. Coordination of intent does.

Project management is not the thing. It is one implementation of a deeper primitive: coordination of intent under constraints to produce state transitions with bounded variance. Collapse the two too early and every system you build — human team or agent fleet — inherits the limits of the scaffold: rigidity, overhead, bias.

Captured reality

A business is a state machine with intent injections

A business is not "projects plus operations." It is a continuous state machine whose operations are stable transitions, punctuated by projects — deliberate attempts to change the transition function itself. The two do different jobs and compound differently.

  • Cycles

    Operations exploit known transitions. Low variance, compounding returns. The state machine running as designed.

  • Projects

    Intent injections that try to change the transition function itself. Higher variance, capability expansion — when they work.

The invariant that matters: capability increase expands the reachable state space, which improves every future transition. A project only matters if it changes capability — not if it merely produces outputs.

Problem pressure

Delivery tracking is where compounding goes to die

Project management earned its place: it gave teams coordination and tracking, and both should survive. But it tracks delivery, not capability delta — and a system rewarded for "shipped" optimizes for exactly that.

  • Local optimization

    Deliverables ship, dates hold, dashboards stay green — while the system that produces the next project stays exactly as capable as before.

  • Weak compounding

    Ten shipped projects that changed no capability leave you where you started, ten times over. Output happened; lift did not.

  • Hidden entropy

    Each person and agent runs a slightly different model of the work. Delivery tracking never surfaces the divergence — it compounds silently until a project fails for reasons nobody's map contained.

The stronger truth: business success is not doing projects well. It is improving the system that produces successful projects. PM tools operate at coordination and tracking. High-performance systems operate at model quality and feedback quality.

Controller

The Coordination of Intent Protocol

Compressed to something a navigator — human or agent — can actually run. Five fields replace the status report; one invariant replaces the burn-down chart.

CIP — one cycle

intent
desired state + constraints — why change state at all
model
the shared map: task, roles, environment, capabilities
commit
who does what next, time-bounded
signal
actual state vs expected state — the delta, measured
update
adjust the model, the roles, or the intent itself

invariant: each cycle, P(desired_state | actions, model) increases.
If that probability is not increasing, you are not learning — you are just executing.

The deep move is the fourth question most standups never ask: are we coordinating actions, or coordinating understanding? Synchronized commits with divergent models is how projects fail on schedule.

Proof

The same release, run both ways

Delivery-tracked

  • Ship feature X by date Y.
  • Track tickets to done.
  • Success = shipped.
  • Next project starts from the same map.

Capability-tracked

  • Intent: raise agent task completion from 62% to 80%.
  • Model: name where failures occur — planning, tool use, context.
  • Commit: targeted changes; signal: measured completion + failure modes.
  • Update: the failure model itself improves. The next project starts smarter.

Kill condition: if tracking capability delta on a real project never cashes out as better prediction accuracy on the next project, the protocol is overhead — delivery tracking was enough, and this belief dies.

Reader action

Run CIP on one live project this week

  1. Pick one live project. Replace its status report with the five CIP fields.
  2. Write the intent as a measurable state transition, not a deliverable — "raise X from a to b," not "ship X."
  3. At close, answer "what capability changed?" before "what shipped?"
  4. On the next project, check whether your estimates tightened. That delta is the outward gauge.

Five questions that surface model divergence before it costs a project:

  • What capability changed as a result of this project?
  • Did our prediction accuracy improve?
  • Where do models diverge between people and agents?
  • Are we coordinating actions, or coordinating understanding?
  • What part of the system is still non-predictable?

Related canon: