Cat-Herding Clankers: Agile Ceremonies Were Built for Humans. AI Agents Need Something Different.#

I spent a few years running engineering organizations. I watched teams drag themselves through agile ceremonies that were supposed to make them faster but mostly exhausted them. Standups where nobody listened. Sprint reviews where nobody argued. Retros where the same three problems appeared every quarter.

Those ceremonies existed for a reason. We forget what our coworkers are doing. We carry social baggage from disagreements. We avoid hard prioritization calls because saying “no” to a colleague’s project feels personal. The ceremonies were designed to compensate for those specific failure modes.

AI agents have none of those problems. They don’t forget. They don’t carry grudges. They don’t need social safety to tell you an estimate is wrong. But they have a set of failure modes that are completely orthogonal to the human ones, and putting them through human ceremonies doesn’t fix those.

This article is about the week I built a multi-agent planning pipeline and realized that sprint ceremonies are the wrong abstraction for AI coordination. The fix turned out to be something I already had on my shelf: the Artifact Pyramid.

What Agile Ceremonies Actually Solve#

Let me be precise about what each ceremony is actually for, stripped of the brand names.

The standup exists because humans forget what their coworkers are doing. A team of six people working on four different features cannot keep a mental model of each other’s progress without regular synchronization. The fifteen-minute standup is a social hack: it exploits our reluctance to admit we don’t know what our teammates are doing by forcing us to say it out loud every day.

The sprint review exists because humans need external validation that they are building the right thing. We show work to stakeholders because our own judgment of “is this good?” is unreliable. The demo is a forcing function for reality contact.

The retrospective exists because humans accumulate emotional debt. A bad decision made in week one becomes a grudge by week four that nobody mentions until the retro, because raising it earlier feels like conflict. The retro is a scheduled permission structure for surfacing things that should have been said day one.

Sprint planning exists because humans need social commitment to prioritize. Saying “we will deliver X by Y date” to a room full of peers is a binding mechanism. Without it, priorities shift daily based on whoever complained last.

AI agents do not need any of these things. They do not forget. They do not hold grudges. They do not need social commitment to prioritize. They do not need a demo to know whether their output meets spec. Putting them through these ceremonies is cargo-cult coordination: going through the motions of agile without understanding what the motions were even for.

What AI Agents Actually Need#

Three things that humans do not need, because human memory and social context handle them implicitly.

Discontinuity tolerance. Every AI agent session is a factory reset. When a researcher agent finishes a task and a writer agent picks up the output, the writer has never met the researcher, never read the brief, and never seen the conversation that produced it. The handoff between them cannot rely on “you know what I mean” or “as we discussed.” It must be a self-contained artifact that carries every piece of context the next agent needs, because the next agent is starting from absolute zero.

Explicit dependency routing. A human team can figure out that the architect needs to talk to the product manager before the sprint starts. They’ll schedule a hallway conversation or a Slack thread. AI agents have no hallways. They have no shared context. The sequence of who does what when must be declared before any work starts, because there is no opportunity for mid-flight correction through conversation. The sequence IS the architecture.

Verifiable output contracts. When a human designer says “the wireframes are done,” the product manager can ask a clarifying question. When an AI architect completes a task, nobody is there to ask a question. The artifact must be pass-fail verifiable against a pre-defined contract, not “looks good to me” reviewed by someone who was in the room.

The Wrong Answer: Agile for Robots#

The most natural but wrong response is to build AI analogues of agile ceremonies.

You see this in the tooling already. Kanban boards for AI agents. Standup summaries generated by LLMs. Sprint planning where an AI estimates story points. These tools map human ceremonies onto AI workflows without asking whether the ceremonies solve the right problem.

A kanban board for AI agents is not a ceremony. It is infrastructure. It tracks state. It manages dependencies. It provides survival across restarts. All of that is valuable. But calling it an agile ceremony misses the point. The board is the substrate, not the coordination mechanism. The coordination happens through the artifacts that move across the board, not through the board itself.

The Architecture That Emerged#

I built a pipeline this week that accidentally solved this. I build on Hermes Agent, which provides the basic infrastructure: profiles, kanban boards, tool dispatch, and subagent spawning. It is an open-source platform designed for multi-agent orchestration, and I have been pushing PRs upstream to close the gaps I find as I go.

The components were not designed as a ceremony replacement. They were designed to answer a specific question: “how do I get five specialist AI agents to produce a coherent product roadmap without having them talk to each other?”

My agents work from a kanban board that looks a lot like what human teams use: columns for backlog, ready, in progress, done; tasks with dependencies; claims and completions. I wrote about the architecture in detail here: The Smartest Agent Orchestration Framework Doesn’t Have a Scheduler. The ceremonies I describe below run on top of that board. The board is the infrastructure. The ceremonies are the coordination.

The Profiles#

A profile is a self-contained AI agent with a defined expertise, a methodology skill, and a curated toolset specific to its domain. Each profile has a SOUL.md: a plain markdown file I can edit that defines its first principles, operating methodology, and boundaries. It is the constitution for that agent. Consider it the system prompt, but durable, versioned, and sitting on disk where I can edit it between sessions.

The planning pipeline uses six of them, shown here in sequence:

• Researcher to understand the market and the user
• UX Designer to map the human experience
• Technical Architect to design the system
• Data Architect to model the data
• Product Manager to prioritize the roadmap
• Implementation Planner to sequence the work
• Reviewer to gate the output

Each profile is a fully realized agent identity with first principles, operating principles, and domain-specific methodology. The Researcher’s SOUL.md says “the question is more important than the answer” and “evidence is not the same as truth.” The Implementation Planner’s says “a plan is a hypothesis about the future.” These are not decoration. They are the axioms that shape every decision that profile makes.

The Orchestrator#

There is another profile that does not appear in the pipeline diagram because it does not produce planning artifacts. The Orchestrator does no research, no writing, no planning, no analysis. Its entire job is deciding who goes when and reading the artifacts they produce.

The Orchestrator’s first principle: “the sequence is the architecture.” Given the same set of specialists, ordering them differently produces completely different outcomes. Researcher before Architect produces an evidence-informed design. Architect before Researcher produces a design that may not survive contact with reality. Both are valid for different questions. The Orchestrator chooses.

The Handoff#

The critical design decision: the researchers output is not a natural language report. It is an Artifact Pyramid written to a known filesystem path. The researcher responds to the orchestrator with a single line:

/tmp/researcher-workflow/market-brief-001/00-index.md

That is the entire handoff. No prose summary. No “here is what I found.” A path.

Downstream profiles read that path. The UX Designer reads the L1 summary for the user needs section. The Technical Architect reads the L2 analysis files for constraints. They do not read the L3 dossiers unless they need to verify a specific claim. The pyramid’s progressive disclosure structure means each profile consumes exactly as much depth as they need and no more.

The AI Ceremonies That Actually Work#

The pipeline revealed four ceremonies that replace the human ones, not by copying them but by solving the AI-specific failure modes.

The Commission Replaces Sprint Planning#

Human sprint planning is a social contract. AI planning is a spec sheet.

The orchestrator writes a discovery brief into the kanban task body before any work starts. It contains the question, the context, the downstream consumers, the depth required, and the gate criteria. This brief is self-contained: if the agent crashes and restarts, a fresh instantiation can execute it without asking for clarification. The brief IS the plan. There is no meeting.

The Produce Replaces the Standup#

A human standup tells you what everyone did yesterday. An AI produce tells you what everyone produced, because the production is the activity.

The specialist reads the commission and produces an artifact pyramid at a known filesystem path. When the researcher completes a task, they respond with a single line: the absolute path to the pyramid entry point. No summary. No status update. The pyramid is the output. The path is the handshake.

There is no standup. The production is the status.

The Gate Replaces the Sprint Review#

A human sprint review is a demo with stakeholders. An AI gate is a pass-fail check against a contract.

The orchestrator reads the L1 summary. It takes fifteen seconds. It validates the gate criteria: does the pyramid have the required layers? Do the findings have adequate confidence? If the pyramid is thin, the orchestrator sends it back before the next specialist ever sees it.

There is no demo. The pyramid was verifiable before any work started because the gate criteria were in the commission.

The Handoff Replaces the Status Meeting#

When a human team finishes a phase, someone schedules a meeting. When an AI agent finishes, the next agent reads a path.

The next specialist in the pipeline reads the completed pyramid’s entry point. They climb as deep as they need: the L1 summary for the overview, the L2 analysis files for their domain, the L3 dossiers only if they need to verify a specific claim. They never ask “what did the previous person find?” because the answer is in the pyramid. They never attend a meeting to learn what they need to know next.

There is no status meeting. The path is the handoff.

The Artifact Pyramid as Infrastructure#

The critical enabling concept here is the Artifact Pyramid. It is a progressive disclosure structure for agent-produced research: three layers of increasing depth, each independently consumable, each linking down to the next.

Progressive disclosure is the principle that governs how agents consume information: metadata at startup, instructions on activation, resources on demand. The artifact pyramid applies the same principle to what agents produce. A downstream consumer starts at the top and only climbs as deep as they need.

Here is what a completed artifact pyramid looks like on disk, from the market research phase of the pipeline I built this week:

/tmp/researcher-workflow/market-brief-001/
├── 00-index.md                  # Project scaffold
├── 01-summary/
│   └── README.md                # L1: key findings, confidence
├── 02-analysis/
│   ├── competitive-landscape.md # L2: per-dimension deep-dive
│   ├── user-needs.md
│   ├── technical-constraints.md
│   └── market-sizing.md
└── 03-dossiers/
    ├── competitor-profiles.md   # L3: source excerpts
    ├── interview-transcripts.md # pulled on demand
    └── benchmark-data.md

Each file at every layer carries an explicit SOURCES section at the bottom describing what the linked files contain and why the reader would open them:

SOURCES (LAYER 2 NAVIGATION)
02-analysis/competitive-landscape.md
  -> Competitor feature matrices supporting Finding 2
02-dossiers/competitor-profiles.md
  -> Raw company profiles for verification

These are not footnotes. They are navigation affordances for agent consumers. Each description answers the question the consuming agent asks before loading: what will I find if I go deeper?

The UX Designer reads only the L1 summary and the L2 user-needs file. The Technical Architect reads the L1 summary and the L2 technical-constraints file. Neither reads the competitor dossiers unless they need to verify a specific claim. The pyramid’s progressive disclosure means each profile consumes exactly as much depth as they need and no more.

I published the concept earlier this week. I did not realize at the time that I had also published the missing piece of multi-agent coordination. The pyramid is not just a way to organize research. It is the API contract between agents in a pipeline. It is the Produce. It is the Handoff. It is the evidence that replaces the demo.

The open-source skill is at github.com/groktopus/artifact-pyramids.

What This Means for Teams#

If you are running AI agents today, look at your coordination architecture. Are you running standups for your agents? Are you having them attend sprint reviews? Are you asking them for status updates?

Those patterns emerged because they felt natural. They are not natural. They are cargo-culted from human team practices that solve human problems your agents do not have.

The alternative is not no coordination. It is better coordination built on the actual constraints of the system: discontinuity, zero implicit context, and verifiable contracts. The artifact pyramid is one implementation of that. The orchestrator pattern is another. The principle is the same: design the handoff, not the meeting.

The conductor does not play an instrument. The conductor decides who plays when. That is the whole job.

Terms and Concepts#

A quick reference for terms introduced in this article:

Profile. A self-contained AI agent with a defined expertise, a methodology skill, and a curated toolset. Profiles are durable across sessions; they keep their identity and skills even when the agent process restarts.

SOUL.md. A plain markdown file that defines a profile’s first principles, operating methodology, and domain boundaries. It lives on disk and can be edited between sessions. Think of it as the constitution for that agent.

Commission. The discovery brief the orchestrator writes into the kanban task body before any work starts. Self-contained, survives restart, contains everything the specialist needs to execute.

Produce. The act of a specialist reading the commission, executing their work, and writing the output as an artifact pyramid at a known filesystem path. The specialist responds with only the path.

Gate. The orchestrator reads the L1 summary of the completed artifact pyramid and validates it against pre-defined criteria before promoting the work to the next specialist.

Artifact Pyramid. A progressive disclosure structure for agent-produced research: L1 is a one-file summary, L2 is per-dimension analysis, L3 is full source dossiers. Each layer carries SOURCES links to the layers below.

Orchestrator. A profile whose entire job is deciding which specialist works when and reading the artifacts they produce. It does no domain work itself.

Kanban board. A shared state machine that tracks tasks through status transitions: backlog, ready, claimed, running, done. The dispatcher claims ready tasks and spawns workers under the assigned profile.