I built an AI board of advisors for my business. It consists of five distinct personas I can talk to individually, in subgroups, or as a full panel. They can even have discussions among themselves. This project is all very new, but so far the results have been fascinating.
I often use Claude as a sounding board and thought partner. This has proven to be an interesting and valuable practice, but I was encountering some limitations. Despite asking a wide variety of questions, I’d routinely get a predictable perspective and similar ideas, to the point where I could often guess what Claude would say before I asked. I wanted something more faceted, with a more diverse set of perspectives. This is closer to how I actually seek counsel from real mentors in my network. I approach different people with the same problem, take in their unique perspectives, and synthesize what comes back with my own thinking.
This project also served several purposes as a tech demo:
- Testing if I could get an LLM to speak consistently from multiple perspectives within the same Cowork project
- Building a memory system for multiple personas that functioned as designed and kept each persona and their stored memories properly isolated from one another
- Applying the new Open Knowledge Format (OKF) recently published by Google, more on OKF below
- Architecting this project for a quick port to other LLMs outside of Claude, such as ChatGPT or Gemini. This would give me an apples-to-apples test between models.
Open Knowledge Format (OKF) is a standard Google published a few months ago for structuring markdown files so an AI can read them predictably. Every file carries a short block of front matter at the top, a simple set of key-value pairs, like this one pulled from the Operating Protocol file:
type: Run Instructions
title: Board of Advisors — Operating Protocol
description: Command reference and loading, memory, and file-editing rules for running consults with the board. Written as instructions to follow.
In my build, one index file lists every file in the bundle and what it contains, so the AI can figure out which files actually matter for a given question before opening all of them and pulling in more context than it needs. I used this mechanism to keep each board member’s knowledge separate instead of pooling it into one file.
The technical build itself is fairly simple on the surface. Each persona gets its own bundle of OKF-structured markdown files: one for identity and voice, two for memory that updates as the board actually gets used (short term and long term memory), and a shared file that holds basic common knowledge about me, my business, and the role of the board. Talking to the board just means typing a command that opens a session with one persona, or all five at once, and that session stays open until I switch it to something else. No custom code, just a set of detailed markdown files per persona, plus a few more that govern how they work together.
There are five personas on my virtual board of advisors. I used AI to come up with a name for each, and some of their personalities are even based loosely on some of my real-life mentors. A description of each persona is below.
- LOID is the people-first advisor, asking who a decision actually touches before asking what it pays.
- GRAMPS is the plainspoken pragmatist, no frameworks, no jargon, just whether a decision pencils out financially, whether it can actually get executed, and whether it grows the business with the right clients.
- WIZE takes the long view, asking whether a decision holds up in five years and whether it’s actually controllable or a reaction to something that isn’t.
- INNOVI is the bold one, always hunting for the angle nobody else is arguing for.
- RADAR argues from pattern, what’s actually happened in comparable situations, and says it flat, with no hedging.
In addition to the markdown files for each persona, there is also a markdown file that contains instructions on how the board operates. It defines a small set of commands that each open a mode and keep it open until I issue a different command. Typing @ and a name, like @GRAMPS, opens a one-on-one session with that advisor, and @all opens the full panel. Adding “discuss” to a prompt, like the example below, has the personas respond to each other instead of just to me. There’s no separate command to close a session, issuing any new command just replaces whatever’s currently active. This governing instruction file is loaded each time the Cowork project is open, and functions as the operating instructions for the board. So far the behavior has been very consistent, and the AI has done a good job of following the instructions and sticking to the format I outlined.
A key technical aspect of this project is that each advisor’s convictions, voice, and memory live in their own set of files instead of one shared document. My hypothesis is that separating knowledge this way keeps each one distinct instead of blurring together the longer you use it.
Before I started asking the board questions, I committed the entire file structure to git and tagged that first version, so I have a fixed baseline to check against later. I’m also building a flat version, with all the personas in one file instead of five, as a control, to test whether the file-separated version actually behaves differently. None of the individual pieces here are new or novel on their own. What I think was a good design decision was building in that kind of auditability from the start, a fixed baseline and a real control group, so when I eventually run this on other models, any difference I see is actually coming from the model and not from something I changed along the way.
I’ve already put the board in front of real decisions for the business. Some of those are sensitive enough that I don’t want to share them here. They named real prospects, real contacts from my network, and real financial numbers. Below is one I’m comfortable sharing, lightly redacted, where I asked the full panel how to balance building versus networking over the next 60 days.
PROMPT: @all how do I balance skill building and networking over the next 60 days? Discuss
RADAR: Without a protected split, the time-boxed activity crowds out the discretionary one. Meetings have deadlines, building doesn’t unless you impose one. Also worth weighting the threads differently: [redacted, referenced specific contacts by name].
GRAMPS: Put a number on it. Three unmovable mornings a week for building, the rest handles follow-ups and meetings. And give [the app I’m building] a real date, “demoable by mid-October,” not “eventually.” Don’t spread even effort across all six threads, that’s the same momentum-versus-progress mistake from before.
INNOVI: Don’t split time between two calendars, that’s the safe answer. Collapse them. Every networking touch from here should include showing the actual build, not just talking about it. [Redacted list of contacts], whoever’s next, bring the work. That turns networking into distribution for what you’re building instead of a competing use of the same hours.
LOID: Whatever split you land on, some people are already mid-thread. [A contact] is waiting on an update, [another contact] is mid-introduction. Prioritizing building shouldn’t mean those go quiet, that’s a different kind of debt than a missed hour of coding. And watch that [the app I’m building] doesn’t drift from being built for your friend into being purely a networking prop.
WIZE: Sixty days is an external clock, not the thing to organize around. What’s yours to control is whether you protect the building time and follow through with people already in motion, not whether [company A] or [company B] turns into anything. Fix the non-negotiable block for building first, let networking fill in around it. Left unprotected, networking will always expand to take whatever time it’s given.
The initial build is not completely without downsides. The multi-file read/write structure does mean that it can take a minute or two to render a response from all five personas. I’m sure there are structural adjustments I could make to improve the overall speed. Sometimes it fixates a bit too much on recent memories as opposed to thinking more broadly. The core aspects of the design, the board instructions and multi-layered memory system, do function as intended. So overall it is performing well for a first version.
For now, the board is running, and it’s already influencing how I think through a wide variety of business decisions. It’s proving to be more useful than I expected. The original intent was really just a tech demo and a test of OKF, model portability, and memory isolation. I do think I’ll keep using it as a regular part of how I run the business.
This is the first of a series of posts on this project. In the next one, I will dive deeper into the technical aspects of the build and the two-tiered memory system, as well as provide more detail on some of the design decisions and problems I encountered during the build process. If you would like a more individualized deep dive into the technical weeds of this, I am happy to share. Feel free to reach out to me via email or on LinkedIn.