Five Doctrine Rules I Landed in One Morning by Listening to My Own Pushbacks
A five-hour conversation with my AI agent produced five new doctrine rules — all because I treated the conversation itself as a product, not a transcript.
This morning I had a five-hour conversation with my AI agent. By the end, five new doctrine rules had been written, saved to memory, and indexed so they’d never have to be discovered the same way twice.
I didn’t sit down planning to write doctrine. I sat down to plan some infrastructure improvements. The doctrine fell out of the conversation because the agent kept proposing things that were almost right, I kept catching what was wrong, and instead of just correcting in the moment, we wrote down why.
I think there’s a pattern here worth surfacing — not about the specific rules, but about how iteration speed in AI engineering works when you treat the conversation itself as a product.
Here’s what landed, what each rule prevents, and why I think the pattern generalizes.
Rule 1: No bridge-and-migrate paths
The conversation started with SMS providers. I’d just gotten EZ Texting approved in a single day after Twilio rejected my Toll-Free number four times over two months. The agent’s first instinct: use EZ Texting for everything now, migrate to Telnyx later when scale demands it.
I shut that down. Not because the recommendation was bad in isolation, but because every migration done with an AI agent in our history has produced bugs — broken callsites, stale data, half-replaced integrations. The migration step itself becomes a load-bearing risk.
So the rule: pick the destination once and commit to it. If a temporary stopgap is genuinely needed, use it from the vendor’s web UI without writing integration code. The throwaway integration is the failure mode.
That single rule changed the recommendation. EZ Texting got narrowed to one specific use case (pull list customer alerts only). Telnyx became the destination for everything else.
This applies anywhere a “temporary integration” creates future migration risk — not just SMS providers. Same logic kills bridge databases, bridge auth systems, bridge file formats.
Rule 2: Don’t conflate marketing channels with ops channels
A few minutes later, the agent recommended Discord as the primary channel for system alerts — SEV1 outages, scout-service failures, drift detection.
I caught it. Discord at our shop is a customer-facing marketing surface. Routing internal failures to a channel where customers might see them is a category error.
The rule: customer-facing channels and ops channels never share a surface. Marketing goes to Discord, Patreon, Instagram, customer email lists. Ops alerts go to a Telegram bot, a Notion mention with mobile push, or a dedicated ops-only Discord server explicitly flagged as not customer-visible.
Rule 3: Match security urgency to threat model
When a webhook signing secret got accidentally exposed in a chat transcript, the agent’s first instinct was P0 emergency rotation: stop everything, generate a new secret, restart services, audit usage logs.
I pushed back. The secret was for staging only. It signed inbound webhooks. Worst case if compromised: an attacker could spoof a STOP keyword routing on staging. They couldn’t exfiltrate customer data, charge cards, or reach production.
The rule: calibrate security urgency to actual threat model, not reflex. Staging webhook secrets are not production service-role keys. Defer low-impact rotations to the next planned maintenance touch instead of demanding emergency action. Reserve “stop everything and rotate now” for credentials with real production blast radius.
This one matters for a small operation specifically because attention is finite. Every false-urgency rotation costs me real focus. If I respond the same way to everything, I respond to nothing well.
Rule 4: Planning is one role, executing is another
Mid-morning the agent caught me trying to do multi-WO ops work in the chat — fetching 13 work-order pages in parallel, planning to audit and revise each one in-session.
I stopped it. That’s not what the planning role is for. The planning role authors specs. The execution role does the work. When the planning role does the execution work in-session, the chat fills with status updates and per-item drafts that drown out the strategic conversation I’m trying to have.
The rule: any ops work that touches more than five existing items, or that requires reading and acting on multiple sources, becomes a single new work order assigned to the execution role. The planning role drafts the spec. The execution role does the work async. The chat stays clear for actual decisions.
Rule 5: Use plain language for architecture, not AI fluff
Late in the morning the agent referred to two of our coordinator agents as a “peer architecture.” I asked whether that was real or fluff.
Honest answer: mostly fluff. Peer-to-peer has a precise meaning in distributed systems — no central coordinator, gossip protocols, eventual consistency. What we actually have is two coordinator agents that share a Postgres state store with domain partitioning. The friendly word was doing work the actual architecture wasn’t.
The rule: use plain English by default. When tempted to reach for labels like “peer architecture” or “agent fabric,” stop and ask whether the term answers a concrete question or just sounds impressive. If it’s hiding decisions you haven’t made, rewrite in plain language and surface the gap.
Why this compounds
None of these rules existed when I sat down this morning. By lunch, all five were written, saved to memory files, and indexed in the agent’s permanent reference. We store them as reference files the agent reads at the start of every future session — no dependency on the agent “remembering” anything; the rules just load.
Tomorrow when the agent drafts a spec, those five rules apply automatically. Future-me doesn’t have to discover them again.
This is the most under-rated property of working with AI agents. Every time you correct the agent, you’re not just fixing this conversation. You’re producing durable doctrine that prevents the same mistake the next ten thousand times the situation comes up.
The catch: you have to actually write the rules down. Most people correct in the moment and move on. The corrections get lost. The agent makes the same mistake next week.
A small habit — every time I push back, ask whether the lesson is durable enough to save — turns a single conversation into a permanent capability upgrade.
That’s the iteration speed of AI engineering when you treat the conversation itself as the product.
LiveSeller Pro is built on a multi-agent operating model with memory feedback files that compound across sessions. Every correction becomes durable doctrine.
Strike Once. List Everything. | livesellerpro.app