# Separating the Idea, State, and Artifact Planes in Agent Pipelines > Source: > Published: 2026-08-22 23:17:55+00:00 This failure mode won't show up in your eval suite. An AI architect builds a personal automation pipeline: an agent scouts trending content, pipes ideas into a chat thread, he reacts, things get logged. The agent did its job. It found the trends, wrote them down, and responded when he asked it to. He killed it anyway, and not over hallucination or token cost. He killed it because everything lived in "a flat scroll of messages. No structure, no views, no way to see what is in scripting versus what is scheduled." He was spending his entire one-hour creation window scrolling backwards through a Telegram thread, looking for something he'd written the day before. The model wasn't the problem. The substrate was, and almost everyone shipping agents today has the same problem, because the default agent UI is a chat window and the default system of record is the transcript. If your agent's output lands in a conversation, you've built an append-only log with no schema and no query interface. Retrieval is O(n), and a human eye does the scanning. That works fine in a demo and falls apart somewhere around week three. Break a chat log down to its data properties and the problem is obvious: ``` CHAT TRANSCRIPT AS DATABASE --------------------------- Schema none (freeform text) Primary key timestamp (not semantic) Indexes none Query interface Ctrl+F, human eyes Mutation impossible (append-only, no UPDATE) Aggregation none Views/filters none State transitions untracked ``` The row that matters is `Mutation: impossible` . Real work has state that *changes*: an idea becomes a draft, the draft gets scheduled, the scheduled item ships. In a chat log none of those transitions exist as data. They exist as later messages contradicting earlier ones, and the reader has to reconstruct the current truth by replaying the whole thread. That's event sourcing without a projection. You get the event stream and no materialized view. It also compounds. Every session starts with context reconstruction: *what did I decide? where did I leave off? which of these forty messages is still live?* The human pays that cost every time, and it grows with the length of the thread while the thread's value stays flat. You'll know you have the problem when you catch yourself using the agent to search the agent's own output. The working version of the pipeline separates concerns into three data planes, each with a different write pattern and a different owner. ``` ┌──────────────────────────────────────────┐ │ PLANE 1: IDEA / INTAKE │ │ Google Sheet · append-only │ │ Writer: agent (scheduled, unattended) │ │ Volume: high · Precision: low │ │ Never edited in place │ └───────────────────┬──────────────────────┘ │ human selects (the gate) ▼ ┌──────────────────────────────────────────┐ │ PLANE 2: STATE / PIPELINE │ │ Notion DB · typed records │ │ Writer: agent on human instruction │ │ Volume: low · Precision: high │ │ status ∈ {Idea, Scripting, Filming, │ │ Scheduled, Published} │ └───────────────────┬──────────────────────┘ │ references by ID ▼ ┌──────────────────────────────────────────┐ │ PLANE 3: ARTIFACT │ │ Google Docs · Drive · rendered media │ │ Writer: human (scripts) + agent (renders)│ │ Addressed by link from Plane 2 │ └──────────────────────────────────────────┘ ``` Each plane has a job the other two are bad at. Plane 1 optimizes for recall rather than precision. The scheduled scan writes 20+ ideas a day across TikTok, Reels, X and YouTube, each row carrying the trend, a hook, an angle, a caption, hashtags, format notes, and a suggested post time. Most of those rows are garbage, which is fine. It's an intake buffer, and the rule is *never curate in place*. That rule earns its keep. Agent writes are non-deterministic, so if your agent mutates rows in the same table it writes to, you lose the ability to tell "the agent changed its mind" from "I changed my mind" from "the agent silently dropped something." Append-only intake gives you an audit trail for free, and it makes human selection the only path from noise to signal. Plane 2 optimizes for queryable state: one typed record per unit of work, with a status enum. A single glance answers what's in scripting, what's waiting to film, and what ships next, which is the question the chat thread could never answer. Plane 3 holds the payload. Documents and media are referenced by ID from Plane 2, never inlined into it. That's ordinary normalization, and agent systems break it all the time by pasting entire drafts into chat messages. The state machine itself is simple enough to copy: ``` Idea ──► Scripting ──► Filming ──► Scheduled ──► Published │ │ │ └───────────┴─────────────┴──► Dropped ``` Five states and one escape hatch. That's the whole orchestration model, and both the human and the agent can read it, which matters: an agent that sees `status = "Scripting"` can act on it directly. An agent reading a chat thread has to *infer* status from prose, and inference is where reliability starts slipping. The second architectural idea in the piece is a clean three-way split of what most people mash into a single "agent": | Component | Answers | Analogue | |---|---|---| Workflow | How the job is done | DAG definition / playbook | Runner | Who owns and executes it | Worker identity + permissions + memory | Schedule | When it fires | Cron / event trigger | If you've ever built data infrastructure, this is Airflow's DAG-vs-worker-vs-scheduler split arriving in the agent world, and the fact that it keeps getting rediscovered independently is a decent signal that it's correct. The practical consequence is that each axis varies independently. Same workflow, different runner (dev vs prod credentials). Same runner, different schedule (daily scan vs on-demand). Same schedule, swapped workflow (v1 to v2 of your edit pipeline) without touching the trigger or the identity. The monolithic alternative is a chat agent where the how, the who, and the when are tangled together in a prompt you retype every session. You can't version that, and you certainly can't hand it to anyone else. ``` ENTANGLED (chat agent) "hey can you scan trends and put them in my sheet like you did last time, you know the format" ──► ??? DECOMPOSED Workflow: trend_scan.v3 (deterministic playbook) Runner: content_bot (Drive+Notion scopes, memory: voice/topics) Schedule: 0 6 * * * (daily 06:00) ``` The decomposed version is a config artifact. You can diff it, review it, and roll it back. This is the detail with the longest shelf life. The video editing logic (cut to vertical 1080×1920, word-synced captions, motion graphics, brand logos, phone-legible thumbnail) was a Claude Skill wrapping Remotion. When the pipeline moved to a different orchestrator, that logic wasn't rebuilt from scratch. It was ported into a saved Workflow and invoked by a Runner. The value was never in the runtime. It was in the encoded decision rules: caption style, safe zones, font sizes, brand colors, render steps. Those took work to get right and would be expensive to rediscover. The execution environment around them is commodity infrastructure that churns every eighteen months or so. ``` ┌─────────────────────────────────────┐ │ DURABLE (you author this once) │ │ • decision rules & checklists │ │ • constraints, safe zones, brand │ │ • step ordering & failure handling │ └──────────────┬──────────────────────┘ │ portable ┌──────────────▼──────────────────────┐ │ COMMODITY (swap every ~18 months) │ │ • agent runtime / orchestrator │ │ • model provider · tool bindings │ └─────────────────────────────────────┘ ``` So write skills as instruction artifacts rather than runtime code. A skill expressed as a markdown playbook with explicit steps, constraints, and decision rules is a text file you can carry anywhere. Bind it hard to one vendor's SDK and you've scheduled a rewrite. If you already have Claude Skills, you already have portable assets. They're the durable layer, not vendor lock-in, and every orchestrator (including the one you're using today) is replaceable. The pipeline has five stages. Two of them are deliberately not automated: ``` 1. Trend scan AGENT (scheduled, unattended) 2. Curation HUMAN → agent files the selection 3. Scripting HUMAN ← agent assists on request 4. Filming HUMAN (fully manual, by design) 5. Editing AGENT (workflow-invoked) ``` Automation sits at the ends, intake and post-production, while the human occupies the middle where judgment lives. The stated reason for keeping scripting human is sharp: *"the point of the system is not to remove me from the work that is mine."* The engineering framing is Amdahl's law. Total time is critical path plus serial overhead. In a creative or knowledge pipeline the critical path is judgment, and it's irreducible because *you* are the value being produced. The serial overhead is everything around it: noticing, logging, filing, linking, formatting, rendering. Speed up the overhead and the whole system gets faster. Try to speed up the critical path by automating judgment and you don't get faster output, you get more output that nobody wanted. There's a second constraint the piece names explicitly, and it deserves a term: the friction budget. As he puts it: *"anything that is not seamless does not get done. If an idea requires me to open six tabs, copy something from one place to another, and remember where I put the draft, it dies."* Treat friction as a hard budget. For a part-time operator with one hour, the budget is near zero: six tabs exceeds it, and the workflow gets abandoned no matter how good the agent is. It's the same reason an accurate internal tool that takes six clicks to reach loses to a rougher one sitting behind a single button. Adoption follows friction more than capability. Most agent projects that "failed" cleared the capability bar and blew the friction budget. If you're standing up an agent pipeline, personal or production, the port is mechanical: Every major agent product is converging on the same interface: a chat box. But the moment an agent's work has state that outlives a session, the chat box stops being a UI and starts being a bad database. So which is it? Is chat a transitional interface we'll look back on the way we look back on command-line-only databases, with agents eventually shipping real structured front ends? Or is the transcript fine, and the fix is just better memory and retrieval bolted onto the thread? If you've killed an agent that technically worked, what made you stop using it? I'd bet more of those stories are about state and friction than about the model.