PowerUp Coaching — Living Knowledge Base

The Code Is the Chassis, The Prompts Are the Car — Why Behavior Belongs in Text Files

5 min read

Topic

The architectural pattern of separating AI agent behavior (what an agent thinks, decides, and produces) from AI pipeline infrastructure (how the pipeline runs, manages state, and routes outputs) — and why this separation is the difference between a one-time AI project and a maintainable AI system.

Target Reader

Knowledge entrepreneurs and coaches who have built or are building multi-stage AI workflows, and who are experiencing the maintenance pain of entangled prompts and code. AI maturity: intermediate to advanced — they’re building real pipelines, not just using chat. Specific friction: they find it hard to iterate on agent behavior because the behavior is buried in code, or they’ve handed off a pipeline to a client/collaborator who can’t modify the agent behavior without their help.

The Fear / Frustration / Want / Aspiration

Fear: “My AI system works but I can’t easily change how it behaves, and neither can anyone else on my team.” Frustration: every behavior tweak requires a code edit and redeployment. Want: a workflow they can hand to a domain expert who doesn’t write code. Aspiration: AI systems that improve over time because the behavior layer is visible, editable, and owned by the person with domain expertise.

Before State

Building AI workflows where prompts are embedded directly in code — buried in Python strings, hardcoded in function arguments, scattered across the codebase. Behavior and infrastructure are entangled. Changing how an agent thinks requires finding the right string in the right file, understanding enough surrounding code not to break anything, and redeploying. Handing the system to a non-developer is impossible.

After State

Separates every AI workflow into two clean layers: behavior (.md files, one per agent role) and infrastructure (code that loads and runs those files). Can change how any agent behaves by editing a markdown file. Can hand the behavior layer to any domain expert. Can swap the infrastructure entirely without touching agent behavior. The person who owns the domain owns the behavior; the code just runs it.

Narrative Arc

The reader starts with the familiar frustration of AI systems that are hard to iterate on. The turn is the realization that this isn’t a prompting problem — it’s an architecture problem. The behavior layer and the infrastructure layer are entangled, and the fix is structural, not tactical. The resolution: one refactor — extract every embedded prompt into a named .md file — turns a fragile, developer-dependent system into one that domain experts can own and improve.

Core Argument

An AI pipeline where behavior and infrastructure are entangled is not maintainable; separating them into text files and code is a single architectural decision that unlocks iteration, delegation, and reuse.

Key Evidence / Examples

  • TrelloAgents: six .md files in agents/ define the entire behavior of a six-stage multi-agent pipeline (role, output format, evaluation rubric, persona, escalation logic, domain knowledge) — the infrastructure is entirely generic and unchanged regardless of what those files say
  • The maintainability test: can the person who owns the domain edit the agent’s behavior without touching code? If no, the layers aren’t actually separated
  • The two failure modes of entangled systems: (1) behavior needs to change → developer finds + edits embedded string, risks breaking code, redeploys; (2) infrastructure needs to change → developer hunts through code for all behavior strings, extracts them, re-embeds in new infrastructure
  • The “just text” power: a well-crafted agent .md file carries role, output format, evaluation criteria, escalation logic, and domain knowledge — all legible, critiqueable, improvable, versionable, shareable, teachable
  • The three-minute architecture check: three questions that reveal whether a workflow’s layers are truly separated

Proposed Structure (5–7 beats)

  1. Open with the scenario: you’ve built a working AI pipeline, but iterating on it feels harder than it should — every behavior tweak is a code expedition
  2. Name the architectural problem: behavior and infrastructure are entangled, and this is structural, not a prompting issue
  3. The separation pattern: behavior layer (.md files, one per agent role) vs. infrastructure layer (code that loads and runs them) — the TrelloAgents example
  4. What “just text” actually carries: role, output format, criteria, escalation logic, domain knowledge — all of it visible and editable
  5. The maintainability payoff: the two failure modes of entangled systems, and why separated layers mean each concern fails (and improves) independently
  6. The three-minute architecture check: three questions that reveal whether your workflow’s layers are truly separated
  7. The immediate action: extract every embedded prompt string into a named .md file, name it after the role the agent plays, reference the file from the code — this one refactor makes the behavior layer real

Editorial Notes

Tone: clear, architectural, practical — this is for someone who builds things and feels the pain of what’s being described. The “chassis and car” metaphor is the hook; use it early and return to it. The immediate action (extract to .md files) is critical — don’t let the article end without a concrete first step. The companion insight (Structured Object as Agent Memory) pairs naturally — consider framing these as a two-part series: “the memory layer” + “the behavior layer” of any multi-agent system. Note: scored 5.0 overall — this is the highest possible score; the editorial challenge is to write to that ambition without being abstract. Every claim should be grounded in the TrelloAgents example. Source is a build session, not a mastermind session — this is practitioner-derived architecture, which is actually a stronger hook than theory.

Next Step

  • Approved for drafting
  • Needs revision
  • Deprioritised

Graph View