This is a blueprint.
Not a copy-paste tutorial. Not a product pitch.
It’s the sequence of decisions that produced a working AI Executive Board inside Slack, in a way that an Operator can repeat: deliberate roles, deliberate constraints, deliberate friction.
Phase 1: The Signal
The system started with an observation that felt like a bug until I treated it like data.
I would ask the same business question to different models and get radically different advice. Not small stylistic differences, but different conclusions and different priorities.
For example, “marketing advice” from Claude and “marketing advice” from ChatGPT can land on opposite sides of the same decision.
The key insight was: this isn’t a flaw. This is what real executive teams do.
A competent team produces tension. A finance mind and a growth mind do not naturally converge. They disagree, argue, and stress-test assumptions until something holds.
Once I saw model disagreement as value, the opportunity became clear: don’t force one assistant to be everything. Instead, structure disagreement and make it persistent.
That was the analysis phase.
Phase 2: Choose the Interaction Surface
The next question wasn’t “what framework?” It was “where should this live?”
The answer was Slack.
Slack already had what I needed:
- I’m there every day.
- The friction is low.
- It supports identity (channels, roles, mentions).
- It supports files.
The most important constraint was also the simplest:
No custom UI.
Text-first. Fast iteration. No detours into dashboards that exist mostly to feel like “a product.”
Phase 3: Technical Preferences (Before Architecture)
Before thinking about architecture, I locked a few boring decisions:
Node.js, TypeScript, webhooks.
For persistence: Supabase. Not because it’s magical, but because it’s simple and flexible, and it gives you toggles without ceremony.
I didn’t assume this would become a big project. I wanted an implementation that wouldn’t fight me if the scope stayed small.
Operator rule:
Pick boring tech that won’t fight you.
Phase 4: Persona Discovery (Letting AI Help)
This is where the system became real.
Instead of designing “the perfect executive team” from scratch, I asked the model a direct question:
“Who do you think I need on this executive board?”
The first two roles that emerged were:
- Chief Reality Officer
- Chief Growth Officer
That mattered. They weren’t invented in isolation. They were shaped by context and by my own failure modes.
I could have created ten personas on day one.
I didn’t.
I let the system earn complexity.
Phase 5: Product Thinking Without a Product UI
At this point, it was tempting to “just start building.”
Instead, I started a new chat and assumed the role of a Product Manager.
I wrote the boring artifacts:
- epics and user stories
- acceptance criteria
- edge cases
This step did something subtle: it surfaced scope creep early.
The model suggested a UI. It wanted settings screens and dashboards. It wanted “a product.”
The Operator correction was explicit: reject UI. Keep it Slack-only.
That one constraint prevented overbuilding before the core loop was stable.
Phase 6: Architecture Definition (And the First Wrong Turn)
The initial system flow is almost embarrassingly simple:
Slack → webhook → app → LLM → Slack.
I initially implemented it with serverless functions (Vercel functions), because that’s the default move in modern web dev: cheap, easy deployment, minimal ops.
It didn’t work well for this workload.
Functions timed out. Messages spawned processes that never completed. Debugging was opaque in the worst way: failures were intermittent and hard to reproduce, which is exactly what you don’t want in a system meant to be “always there.”
The insight wasn’t “serverless is bad.”
It was more precise: serverless was the wrong abstraction for long-running, conversational work.
Phase 7: The Critical Pivot
The pivot was simple and decisive: abandon serverless for this.
Replace it with a long-lived process.
In practice, that meant moving to a Next.js app that could host the Slack webhook handling and maintain predictable execution characteristics.
Once I made that change, everything unclogged:
- stable execution
- predictable behavior
- debugging that made sense again
This is the part most people miss: the hard part is rarely “writing the code.” The hard part is choosing an architecture that doesn’t turn every bug into a mystery.
Phase 8: Build, Then Test
With the pivot in place, the rest was straightforward. I built the core loop, then ran a tester role against it.
Deployment was Vercel, plus environment variables and secrets management.
The first working version, with two executives, took about 2 - 3 hours.
Speed wasn’t the point. Clarity was the point.
Phase 9: Add an Executive Assistant (The Foundational Role)
After the first “board” was live, I manually added one more role: the Executive Assistant.
This role does not give opinions. It manages global context.
It handles commands like:
- “Add this to global context.”
- “Remember this goal.”
- “Forget that constraint.”
That one role became foundational, because it allowed shared facts to exist outside of any one executive’s persona.
Goals, company info, handles, constraints. These are things you want the whole board to know without repeating yourself.
Phase 10: Context Design (Underrated)
There are two kinds of context in the system:
Role-specific context, and global context.
Global context is editable from Slack. It’s easy to add to, and just as easy to subtract from.
That last part matters more than most people realize.
Forgetting context is intentional. It prevents system bloat. It keeps the board adaptive, instead of becoming a museum of old decisions.
Phase 11: File Support (The Real Game Changer)
Text-only interaction is fine for lightweight debate.
It’s limiting for real work.
Once I enabled Slack file uploads and forwarded them to Claude (Opus 4.5, multimodal by default), the board crossed a threshold:
It stopped being “chat about work,” and became “work.”
Documents, drafts, screenshots, spreadsheets. Suddenly the executives could react to reality, not just to my summaries of reality.
This required some Slack permission adjustments, but once configured it worked cleanly.
Phase 12: Persona Behavior Rules
A board that talks constantly is not a board. It’s noise.
So each executive follows two behavioral rules:
If I tag them, they respond.
If I don’t tag them, they respond only when a relevance threshold is met.
This keeps the system quiet by default, and responsive on demand.
It also prevents a common failure mode: hallucinated authority. Executives stay within mandate.
Phase 13: Cost Reality
The model is Claude Opus 4.5.
The monthly cost is roughly $5.
And the most important detail, because it clarifies what “Operator” actually means:
I wrote 0 lines of code.
I designed the flow, the constraints, and the roles.
The system executed the rest.
Operator Takeaway
This system wasn’t designed in a single burst.
It was discovered, step by step, under real constraints.
The blueprint is not “Slack + Supabase + Opus.”
The blueprint is simpler:
Deliberate roles.
Deliberate constraints.
Deliberate friction.
AI becomes useful when you stop asking it to agree with you.