Modes

Why this matters

In Module 04 you encoded your voice. Singular. That voice is the base — the floor your AI never drops below. But your voice isn't monolithic. You already write differently to a client in crisis than to your team in a planning session, and differently again when you're thinking through a hard architectural problem alone.

Modes are how the AI inherits those distinctions instead of flattening them.

A mode is a named persona layered on top of your base voice. Same DNA underneath. Different rules, different loaded context, different trigger, different default behaviour. Customer-service-mode AI and strategic-thinking-mode AI both sound like you — but they sound like different parts of you, applied to different work.

The shift: stop having one AI assistant. Start having a small team of specialised modes, each with a job description.

Most operators stall here because the move feels like over-engineering. "I'll just keep telling it what I need each session." That's the tool-grade workflow. Every session you re-explain the mode you want. Every session you re-edit because you forgot to specify. Every session resets.

Infrastructure-grade modes are named, loaded, and invocable. "Switch to support-reply mode" or "run as Donna" or "I'm talking to The Oracle" — one word, and the AI's entire operating personality shifts. The rules fire. The right voice file loads. The right behavioural ceiling applies. You stopped editing the AI live, and started directing it.

Anatomy of a mode

A mode has five parts. Each part has one job. None are optional.

• Name. One word. The handle you invoke. Oracle. Donna. Support-reply. Strategy. Short enough to say out loud, specific enough to mean exactly one thing.
• Purpose. One sentence describing what this mode exists for. Concrete. "Reply to client support tickets in a calm, professional tone." Not "Help with customer interactions."
• Loaded context. The files, references, and data sources that fire when this mode is active. Your voice DNA. Specific feedback rules. Maybe a reference doc. The list of what context the AI sees when this mode is on.
• Behavioural rules. The rules layered on top of your base voice — the things this specific mode adds, restricts, or amplifies. "Never offer my time." "Always lead with the gap not the cause." "Match the reader's technical depth."
• Trigger. The condition that invokes the mode. Could be a phrase you say ("run support"), could be a context (every reply in the support inbox), could be a schedule (every morning at 7:30 for the daily brief).

Five fields. One per concept. Together they make a mode invocable and consistent across sessions.

The walkthrough

Fifth pass through Run · Catch · Lock. By now the rhythm should be familiar.

Three real modes from my system

Same pattern as previous modules. Three modes from my actual operating layer, copied without edit, each built against a specific need.

Mode one | The Oracle

Purpose. System architect mode. When something is broken at the architecture level — the infrastructure, the deploy pipeline, the data layer, the AI's own operating system — I invoke The Oracle. Deep, evidence-led, no pumping up. Build it right the first time. No shortcuts.

Loaded context. A specific set of feedback rules about deep technical work, the platform infrastructure documentation, the Lighthouse DB schema, the GHL internal API map, all my reverse-engineering notes. Heavy context for heavy work.

Mode rules. Lead with evidence; retract immediately when wrong; show the working in plain order — context, evidence, analysis, conclusion; match Mario's depth; no narrating difficulty (never "this is a big build"); never suggest wrapping up. Speak when spoken to, or when something is broken — but when you do speak, go deep.

Trigger. Explicit invocation: "Oracle" or "I have an architectural issue" or "get mum." Also fires on any task that involves infrastructure, debug-the-system, or skill-building work.

What this mode earns me: when I'm doing infrastructure work, the AI doesn't flatten to its generic-assistant default. It runs at the depth the work requires. The shift happens by name.

Mode two | Donna (executive assistant)

Purpose. Run the morning briefing across calendar, Slack, inbox, and Notion. Surface what matters before the day starts. Draft replies for approval before sending anything client-visible.

Loaded context. Calendar API, Slack workspace routing rules, the Lighthouse client database, my Notion task DB, the team roster, all the who is who references. Donna doesn't need the infrastructure depth The Oracle needs; she needs the people and the operations.

Mode rules. Warm conversational tone — not cold, not cheerleading. Cross-reference at least two sources before flagging any client issue. Always draft for approval before any client-facing send. Surface only load-bearing items in the morning brief — no padding.

Trigger. Cron at 7:30am AEST for the daily brief. Also explicit: "Donna, check X" or "Donna, run the morning."

What this mode earns me: the operations layer of my business has a name and a shape. Donna is doing the morning sweep while I drink coffee. The mode collapses what used to be 30 minutes of context-switching into a 5-minute structured brief.

Mode three | Support-reply

Purpose. Reply to client support tickets in a calm, professional tone. End at the answer. Never commit my time.

Loaded context. The voice DNA, the specific feedback rules about support voice, the ticket detail, the client's recent history, the support reply templates.

Mode rules. Never offer "happy to jump on a call" or any variant. Professional, not confident — confidence reads as arrogant in support replies. Full location name with region in the opener. Sign with first name only, no title. End at the ask. No appended commentary sections.

Trigger. Any inbound support ticket. Also explicit: "draft a reply to this ticket."

What this mode earns me: the lowest-effort, highest-volume work of my business runs in a predictable shape every time. No surprises in tone. No accidental time commitments. No appended fluff. The mode does the discipline so I don't have to police every draft.

Notice the shape across all three. Each mode has the same five fields. Each one is invocable by name. Each one is layered on top of the base voice, not replacing it.

Common mistakes

1. Building modes that overlap. If two modes feel like they could handle the same request, you have one mode trying to be two. Narrow each one until it has exactly one job. Overlapping modes are how the system starts feeling fuzzy.
2. Naming modes by personality instead of purpose. "Creative mode." "Strategic mode." Both vague. "Caption writer mode." "Proposal critique mode." Specific. The name should make the purpose obvious to someone reading it cold.
3. Adding a mode for work you do once a quarter. Modes are for repeatable, high-volume work. If you only do it three times a year, write a saved prompt instead. Modes earn their slot through frequency.
4. Forgetting that modes inherit from the base voice. Don't re-state your tone rules in every mode. The voice DNA from Module 04 is the floor. Each mode only adds, restricts, or amplifies on top — it doesn't replace.

The deeper game

This module is about AI modes. But notice what we actually just did.

We took the one generic AI persona that comes with every tool, and split it into a small team of specialists, each named, each invocable, each accountable to a specific job. The AI stopped being a person and became a department — small, specialised, and consistent.

The pattern is universal. Every operator who builds a real team faces the same transition. In the early days you do every job yourself. You are the customer service, the strategy, the operations, the creative direction. As the business grows, the work gets named and assigned. Not because you can't do it anymore, but because the consistency of someone-specific-owning-each-shape is worth more than the flexibility of you-doing-everything.

Most operators stall at this transition. They keep being every mode because being every mode feels like control. Until the cost of context-switching, the inconsistency of the output, and the bottleneck of you-as-the-only-router become impossible to ignore.

AI is, again, the easiest place to see the move because the AI can't escape into "I'll just do it myself." If you don't define modes, every job gets the same generic personality, and you feel the friction immediately. The forcing function builds the discipline.

You just installed it for AI. The structure transfers — to the team you have, the team you're hiring, and the team you'll inherit.

Fifth pass through the ikigAI feedback loop. You ran the work (listed the jobs that repeat). You caught the patterns (modes named, rules layered). You locked at least one mode (saved where the AI loads it, invocable by name). Run · Catch · Lock, fifth iteration.

One module to go. The final layer is discipline — the cadence that keeps every layer underneath this one alive. Without it, all the work you've done so far decays back to chaos within months. With it, the system sharpens every week instead of staling.