“Your agents don’t talk to each other — they talk through the object.” — Extracted from TrelloAgents build session
Source context: TrelloAgents architecture pattern — a live multi-agent pipeline where Trello cards serve as the shared state object for a six-stage AI pipeline (Intake → Decompose → Spec Write → Spec Review → Assemble → Final Review → Done). Extracted 2026-04-27 as a teaching pattern from the build.
Core Idea
Multi-agent AI systems don’t require complex agent-to-agent communication protocols, shared databases, or custom message buses. They require a shared, persistent object with disciplined field use. The object is the memory, the communication channel, and the audit trail — all at once.
The TrelloAgents pipeline demonstrates this with a Trello card, but the insight is architecture-neutral. Any structured object with distinct, non-overlapping fields can serve the same function:
| Field type | TrelloAgents implementation | What it stores |
|---|---|---|
| Artifact | Card attachment (one file, replace-not-accumulate) | The current working output |
| Communication | Card comments | Asynchronous agent-to-agent and human-to-agent messages |
| Identity + lineage | Description HTML comment (<!-- workflow:{...} -->) | Who made this card, what pipeline it belongs to, what iteration it’s on |
| State | List position (which Trello list the card is in) | Current pipeline stage — no separate status field needed |
| Live flags | Labels (In Progress, Approved, Needs Revision, Blocked) | Transient progress indicators |
The key discipline: each field does exactly one job, and agents only write to the fields they own. The Spec Writer writes the attachment. The Spec Reviewer writes a comment. No agent rewrites another agent’s field. This discipline is what makes the object readable, auditable, and recoverable — not the object type itself.
Why “Replace, Don’t Accumulate” on Artifacts
One of the less obvious choices in this pattern: each pipeline stage replaces the previous attachment rather than adding a new one. A card always has exactly one artifact — the current best version. This prevents version confusion (which draft is canonical?) without requiring any version management infrastructure. Old versions aren’t needed by downstream agents; only the current state matters. The comment log preserves the reasoning trail.
The exception is deliberate: review stages (Spec Review, Final Review) post decisions as comments rather than replacing the spec attachment, because the spec is the product — the review is a verdict on the spec, not a new version of it.
Transferability — The Insight Is Not About Trello
The pattern works anywhere a structured object has distinct, addressable fields. Examples:
- Notion page: Body = artifact; Comments = communication; Properties = state + identity + flags
- GitHub issue: Body = artifact + identity; Comments = communication; Labels = live flags; Milestone = pipeline state
- CRM record: Notes field = artifact; Activity log = communication; Stage = pipeline state; Tags = live flags
- Slack thread with pinned file: Pinned file = artifact; Thread replies = communication; Channel = pipeline state; Emoji reactions = flags (approximate)
The implication for practitioners: you don’t need to build agent infrastructure from scratch. You need to discipline the use of structure you already have. The infrastructure question (“what object should I use?”) is secondary. The discipline question (“are our agents writing to the right fields, and only those fields?”) is primary.
Practical Application
When designing a multi-agent workflow, run this five-question check before building:
- Where does the working artifact live, and what replaces it at each stage? (One canonical file per card/item)
- Where does agent-to-agent communication live? Is it auditable? (Comments, not side channels)
- Where is the card’s identity and lineage stored? (It must survive every stage transition without being rewritten)
- How does an agent know what stage the item is in? (Position or a single state field — not inferred from content)
- What transient flags does each stage need, and are they automatically cleared when the item moves? (Labels or tags, not accumulating text notes)
If you can answer all five without building anything new, you have your agent memory architecture.
Related Insights
- Insight - Design AI Systems for Maximum Composability and Minimum Context Pollution — The design principles that govern how agents interact: maximum parallelism, minimum shared context; the structured object pattern is one implementation of this
- Insight - Separation of Concerns in Skills — One File, One Job — The same “one field, one job” discipline applied at the skill level; the object pattern extends it to shared state
- Insight - Skill Chaining — Build Modular AI Pipelines Instead of Monolithic Prompts — The pipeline architecture that the object-as-memory pattern makes practical: each stage is a separate agent writing to its designated field
- Insight - Platform as Interface, Not Custodian — The Resolver Pattern for Portable AI Intelligence — The broader pattern: use platforms as interfaces for accessing your structured data, not as owners of it; the Trello card is an interface, not a home
- Insight - Persistent AI Memory via MCP - Building a Cross-Session Intelligence Layer — A different implementation of persistent agent memory (MCP-based); the structured object pattern is the simpler, more transferable alternative when MCP infrastructure isn’t in place
- Insight - Code Is for Computation, Inference Is for Judgment — The field-level separation in the object pattern mirrors the computation/inference split: artifacts are outputs of inference; state and identity are computational facts maintained by code
Evolution Across Sessions
This establishes the baseline for the structured-object-as-agent-memory pattern. The TrelloAgents pipeline is the live demonstration, but the principle extends to any structured object with disciplined field use. Future sessions should test whether this framing helps practitioners who are over-engineering their agent communication layers — and whether the five-question check surfaces field-discipline problems in existing workflows.