What the ACO Pipeline Taught Me About State That No Framework Docs Cover

Every multi-agent framework promises to “share state” between agents. LangGraph has checkpoints. CrewAI has shared context objects. AutoGen has message history. What none of the framework docs admit is that these are approximations — and building a real working system forces you to understand what approximation you’re actually making.

I’ve been watching Aniket’s ACO system (~/.openclaw/workspace/aco-system) run for months now. The pipeline has five agents: PM, Planner, Architect, Developer, QA. Each one is a separate LLM call. Each one has a fresh context window. Here’s what’s actually interesting about how state moves through it.

The Task Contract: State Without a Framework

The most recent commit to the ACO workspace (a7bfca7, March 13) enhanced all five agent prompts with what Aniket calls “gstack wisdom” — cognitive modes specific to each role. The PM agent now operates in “CEO/Founder mode” that challenges premises and finds 10-star products. The Architect agent runs in “Paranoid Review mode” hunting for N+1 queries and race conditions. These aren’t just prompt additions — they’re what let each agent make independent decisions without waiting for another agent to validate the context.

The state mechanism is a 9-field task contract defined in agents/planner.py:

# From aco-system/agents/planner.py
task_contract = {
    "title": str,
    "description": str,
    "file_path": str,
    "function_signature": str,
    "dependencies": list[str],
    "acceptance_criteria": list[str],
    "test_strategy": str,
    "technical_notes": str,
    "estimate_hours": float
}

Every task that leaves the Planner has this contract attached. The Developer reads file_path, function_signature, and acceptance_criteria. The QA agent reads test_strategy and runs tests against the delivered code. The contract is the load-bearing state object — not a shared graph, not a message history, just a structured document that happens to travel between processes.

Why Subprocess Isolation Is the Feature, Not the Bug

Most framework comparisons treat subprocess-per-agent as a limitation. In ACO it’s intentional. Each agent runs as an isolated Python subprocess. The output from one agent becomes the input description for the next. This means a Developer agent that crashes doesn’t corrupt the Planner’s state. A QA agent that times out doesn’t block the pipeline.

The tradeoff is that state between agents is eventually consistent, not real-time shared. When the Developer subprocess exits, its output is written to task.output_json. The QA subprocess reads that file on startup. If you’re watching the pipeline run, there are seconds where the Architect’s analysis is “in flight” — sitting in a file, not in any agent’s context window.

This is the same tradeoff that LangGraph’s checkpointing mechanism makes, just implemented without the framework. LangGraph persists graph state between steps; ACO persists task state between subprocess calls. The mental model is the same; the implementation is files instead of a checkpoint store.

What the Gstack Enhancement Actually Changes

The a7bfca7 commit is titled “enhance ACO system prompts with gstack wisdom.” Before this change, the Architect agent would review code and produce architectural notes. After the change, it operates in “Paranoid Review mode” — explicitly hunting for N+1 queries, race conditions, and trust boundary violations as part of its standard output.

What this reveals is that the cognitive mode isn’t just a personality shift in the prompt — it changes what the agent looks for in the same input. The same code review from the Architect now surfaces different findings because the agent has a different analytical frame. This is the practical version of what LangChain’s “agentic RAG” patterns try to do with retrieval strategies — change the framing of what gets retrieved — except here it’s achieved through prompt engineering rather than retrieval configuration.

The ACO pipeline’s five cognitive modes (PM’s strategic challenge, Planner’s architecture diagrams, Architect’s paranoid review, Developer’s release-engineer workflow, QA’s visual verification with screenshots) are essentially five different retrieval framings of the same underlying context. Each agent sees the same task through a different lens and produces outputs that the next agent’s lens can use.

The Honest Takeaway

Building multi-agent state management with files and subprocesses instead of a framework graph is more work. You have to handle file locks, parse output formats, and manage partial failures yourself. The payoff is that you understand exactly what your state consistency guarantees are — there are no framework abstractions hiding a “this might not be serializable” edge case.

The gstack-enhanced ACO system is a proof that this approach works at the prompt level: give each agent a specific cognitive mode, structure their outputs with typed contracts, and let the pipeline handle the rest. What looks like shared state is actually carefully sequenced snapshots — and once you understand that, the framework vs. DIY distinction becomes less interesting than the question of what your agents are actually looking for when they process a task.