Multi-agent coordination via content lifecycle

Most orchestration frameworks require an upfront workflow definition. Forge takes a different approach: agents coordinate through content state transitions. No central orchestrator. No graph. Just a signal bus and a state machine.

Most multi-agent frameworks ask you to define the workflow before you run it. In LangGraph, you draw the graph: node A feeds node B, node B branches to C or D. In Temporal, you write the workflow function that sequences activities. The coordination logic is explicit, centralised, and defined upfront.

This works well for workflows you understand in advance. It is harder when the process is long-running, requires human review between steps, or should be composable without touching the orchestration layer.

Forge takes a different approach.

Content lifecycle as coordination protocol

In Forge, every content type has a lifecycle:

Draft → Scheduled → Published → Archived

State transitions fire signals. Signals trigger agents. Agents produce content. Content transitions fire more signals. The coordination emerges from the state machine. No central orchestrator required.

A concrete pattern:

1. Agent 1 receives a brief, writes a technical specification, and calls publish_spec. Forge fires after_publish for the Spec type. 2. Agent 2 is subscribed via ContentTypeFilter: "Spec". It picks up the signal, reads the spec via get_spec, breaks it into implementation tasks, and calls publish_task for each one. 3. Agent 3 is subscribed to after_publish for Task. It picks up each task, implements it, and writes the result back as a new content item. 4. At any point, a human can inspect the state: every item is visible in Forge with a full audit trail, and intervene before the next transition fires.

Each agent is an independent AgentJob. They do not call each other. They do not share memory. They coordinate through Forge state.

What this means in practice

No central orchestrator. There is no process that knows the full workflow. Each agent knows only its trigger and its task. Adding a new step means publishing a new AgentJob, with no change to existing agents.

Emergent composition. The workflow is implicit in the set of published AgentJobs and their ContentTypeFilter values. You can add, remove, or replace steps without touching the coordination layer, because there is no coordination layer, only signal subscriptions.

Human intervention is always possible. Because each step produces Forge content, an operator can review and intervene between any two agents: archive a Task before Agent 3 picks it up, edit a Spec before Agent 2 processes it. Whether you want a fully automated pipeline or a reviewed one at every step is your decision. The architecture does not prescribe it either way.

Auditable end-to-end. Every state transition, by an agent or a human, is recorded in Forge's audit trail. Who published what, when, from what previous state. No extra instrumentation needed.

Access control per agent. Each AgentJob uses its own MCP token with its own role. Agent 1 might have Author access to Spec. Agent 3 might have access only to Task. The boundaries are enforced by the framework, not negotiated between agents.

ContentTypeFilter is the router

ContentTypeFilter is what makes this composable. Without it, every after_publish signal would trigger every subscribed agent. With it, agents are scoped to the content types they understand:

AgentJob: write-spec
  trigger: after_publish
  content_type_filter: Brief

AgentJob: plan-tasks
  trigger: after_publish
  content_type_filter: Spec

AgentJob: implement-task
  trigger: after_publish
  content_type_filter: Task

Publishing a Brief starts the chain. Each agent fires exactly once per relevant content item. AgentJob lifecycle events never trigger other jobs. The framework guards against self-activation loops automatically.

vs. graph-based orchestration

The difference from LangGraph or Temporal is not capability. It is where coordination logic lives.

In LangGraph, the graph is the source of truth. To add a step, you modify the graph definition. To inspect the workflow, you read the graph.

In Forge, the state machine is the source of truth. To add a step, you publish an AgentJob. To inspect the workflow, you look at published AgentJobs and their filters: each one a content item with its own lifecycle.

This makes the workflow itself manageable as content. An operator can archive an AgentJob to pause that step. They can publish a modified version to change behaviour. No redeploy. No graph edit. No restart.


forge-agent v0.3.4.

*forge-agent on GitHub* *Typed persistent state for AI agents: the state layer argument* *forge-agent: scheduled and reactive jobs: how AgentJob works*