Most mornings for about a year, I started work by explaining my own business to a machine.
Not all of it. Just whatever was needed for the next hour. Who the audience is. What we settled on pricing last month. Why we stopped using a particular phrase in public. Which of the four things on my desk was actually urgent and which one only felt loud.
The assistant was good. The answers were useful. And every session began at zero.
You have probably done a version of this. You open a chat, paste in the same background you pasted yesterday, and somewhere in the fourth paragraph you realize you have typed this before. The work does not accumulate. Every conversation is a first day on the job, and you are the one doing the onboarding, again.
This is how I fixed that. What it cost, how to set up the same thing, the part I got wrong, and - more useful than any of it - how to tell whether you should bother yet.
The fix everybody reaches for first
When people hit this wall they reach for a bigger prompt.
Longer custom instructions. A fatter project description. Whatever memory feature the tool offers, switched on and hoped at. I tried all three and each bought me a few weeks before the same problem came back wearing a different shirt.
The reason is not a limitation of the tool, which is why a better model does not fix it.
Think about how an actual organization holds what it knows. A company with forty people does not run on one person's recall. It runs on contracts, policies, a CRM, meeting notes, and an employee handbook nobody loves but everybody can point at. When a new hire asks why we do it this way, somebody sends a link. The knowledge sits outside any individual head, which is exactly what lets it survive when that head takes a vacation.
A longer prompt is still one head. A better head, but one head, holding everything, forever, and getting quietly annoyed when it drops something.
The problem is filing, not memory
Once I stopped treating this as a memory question, the answer got boring in the way correct answers often do.
My AI teammates needed somewhere to write things down that any of them could read later. Not a smarter assistant. A filing cabinet.
I use Notion. Not because it is the only thing that works - a wiki, a shared drive, or a folder of well-named markdown files would all do the job - but because it does two things I needed. It holds databases my crew can query instead of skim, and it is reachable from inside the tool where the work actually happens.
One idea, repeated everywhere: if a decision matters past today, it goes in the cabinet, not in the chat.
Why the seats have call signs
I should explain the vocabulary before it gets confusing, because I organized my business around Apollo-era mission control and the names stuck.
That was not a theme I picked for fun. Mission control had solved a problem I recognized. A room full of specialists, each responsible for one system, each able to call go or no-go on their own piece, all reporting to one person who owned the final decision. Nobody in that room needed the whole picture. They needed their piece, the rules governing it, and a clear line to whoever decides.
So my AI teammates have seats, and the seats have call signs.
I am FLIGHT. Flight Director. Every seat reports to me and I hold the final call on anything that ships, sends, or publishes - that is rule one, and it is written where all of them can read it. CLU is my Assistant Flight Director, a staff seat that helps me design and manage the other seats, argues with me, and commands nothing. PAO handles anything published to a room. CAPCOM handles anything addressed to a person by name, which in the real mission control meant one voice to the crew and no others. GUIDANCE plots the content trajectory three to six months out. BOOSTER runs the sales pipeline. EECOM watches the site.
Here is the definition underneath all of it, and it matters more than the names:
A Digital Crew is a governed team of AI agents with named roles, defined jobs, a human manager, and decision rights that stay with people. The crew takes the busywork. Your best people get back to the work only they can do.
Read that again and notice how much of it is paperwork. Named roles. Defined jobs. A human manager. Decision rights that stay with people. Not one word of that is a model capability. All four are things somebody has to write down.
Which is why the filing cabinet is not an accessory to the crew. It is what makes it a crew instead of a pile of prompts.
Flight Rules, and why written beats clever
During the Apollo 11 lunar descent, the guidance computer threw a 1202 program alarm. An error code nobody in the room expected, minutes from the surface. The go/no-go call fell to Steve Bales, the 26-year-old Guidance Officer. He called go, the landing continued, and Armstrong and Aldrin walked on the Moon.
The part most people do not know happened weeks earlier. Dick Koos, the Simulation Supervisor, threw a program alarm at that same team during a training sim. They blew the call and aborted a landing they should have saved. Afterward, Bales went back and wrote the rules: which alarms were survivable, which were not, what to check before calling go.
When the real 1202 fired he was not improvising brilliantly under pressure. He was executing a decision he had already made.
That is the first thing in my cabinet and the first thing I would build if I started over. Flight Rules are standing decisions, written down with the reasoning that produced them, before anybody needs them.
Some of mine are dull operations. Nothing publishes without my click. A seat is only staffed when it has a written role file that needs no re-briefing. Others are scar tissue - rules that exist because something went sideways once and I never want that argument again. That is the honest origin of most good rules, in a spacecraft or a small business.
What a rule buys you is the end of relitigation. My crew does not need permission to think, but it does not get to reopen a settled question at six in the morning either. And because the rule carries its reasoning, a teammate can read not just what we decided but why, which is what lets it apply the rule to a situation the rule never anticipated.
What else lives in the cabinet
Four more things earn their place. Each exists because something was living in a chat window that should not have been.
Squawks. In aviation, a squawk is a defect you log the moment you find it, whether or not you can fix it now. Mine work the same way. Anything unresolved gets filed when it opens rather than when someone remembers it - a blocked decision, a risk somebody spotted, a loose thread. Closing one requires a resolution and a rationale, both. Before this existed my open items lived in whichever conversation surfaced them, which meant they were perfectly visible right up until that conversation ended.
Mission logs. What happened, when, and what we judged at the time. I resisted this one longest and use it most. Six weeks later nobody remembers why a reasonable-looking decision got made, and reconstructing it costs more than writing it down would have.
Procedures. The portable methods. How a sourcing session runs. How a testimonial gets permission-gated before it can appear anywhere. A procedure is written for a stranger, which is the test of whether it is genuinely written or only described.
Databases. The state of things, in rows instead of prose. My content pipeline, my speaking calendar, the earned-media placements with their exclusivity terms attached. My crew queries these rather than remembering them, and that difference is the whole game. A teammate reading a database is working from what is true now. A teammate working from what it was told last Tuesday is working from a story about last Tuesday.
If you have run a team you have built some version of all five already. The move is putting them somewhere your AI can read without you pasting anything.
Seat, project, procedure
I got this wrong for months, and it is the mistake I see most often when somebody shows me their setup.
A seat, a project, and a procedure are three different objects. Mashing them together is why most people's AI system eventually becomes one enormous prompt nobody wants to touch.
A seat is an accountability. A role with a name, a defined job, a human who owns it, and at least one decision it never makes alone. GUIDANCE plots the trajectory. It does not write posts and it cannot publish anything.
A project is standing context. The desk the seat works at - background, files, history that does not need re-explaining every time.
A procedure is a portable method. It travels between seats.
Keep them separate and you can change one without breaking the others. I can rewrite a procedure without touching the seat that runs it. I can stand up a new seat and hand it three existing procedures on day one. Collapse them and every small change becomes a rewrite of everything, which is what makes people quietly abandon the system they spent a weekend building.
What Notion MCP actually is
Here is the piece that makes all of the above work, and it is newer than most people realize.
Anthropic published an open standard called the Model Context Protocol, MCP for short. Think of it as a common plug shape. Before MCP, getting an AI assistant to work with a service like Notion meant somebody building a custom integration for that specific pairing. With a shared protocol, a service publishes one connector and any assistant that speaks the protocol can use it.
Notion publishes one. You connect it once, authorize the workspaces or pages you want reachable, and your assistant can read and write there directly.
The practical difference is bigger than it sounds. Without the connection, you copy things out of Notion and paste them into a chat, which is the re-briefing problem with extra steps. With it, the assistant reads the actual pages and queries the actual databases at the moment it needs them. When my content seat reads my speaking calendar, it is reading today's calendar rather than a summary I pasted in March.
Which assistant? I run Claude, and I will be straight about why. But MCP is an open protocol, not a Claude feature, and both ChatGPT and Copilot connect to Notion too - I checked. One caveat worth knowing before you plan around it: Copilot’s connection is read-only at the moment. Everything in this post still works on a read-only connection, because the cabinet’s job is to be read; the crew reads its rules at the start of every session. What you give up is write-back. The assistant cannot file the squawk or update the row for you, so those stay manual. Claude does both, and the seats I have built live in Claude Projects where each one gets its own standing context. The architecture is the same whichever you choose. The vocabulary and the filing discipline are what matter; the assistant is swappable and will keep changing.
How to build this
This took me a weekend. Knowing what I know now, it is an afternoon.
1. Get a Notion account, and yes, the free plan works
I am still on the free plan and it covers everything described here. Is Notion MCP free? The connector itself does not cost anything - what varies is your Notion plan and whatever your AI assistant costs. I have not hit a wall that made me upgrade, and I would tell you if I had.
If you need an account, here is my affiliate link. I earn a commission if you eventually move to a paid plan. It costs you nothing and does not change the recommendation - I was using and recommending Notion well before there was a link.
2. Connect Notion to your assistant
One-time setup. Find your assistant's connector settings, add Notion, authorize it, and choose which pages or workspaces it can reach.
Grant it narrowly at first. Give it one page, confirm it can read that page, then widen. Connecting your entire workspace on the first attempt and then wondering why the answers are vague is a common and avoidable afternoon.
Two different scopes are worth separating, because the settings screen shows both. Page scope is which pages the assistant can reach. Tool scope is what it is allowed to do once it is there - read, write, delete - and the two are set independently. Start narrow on the first and conservative on the second. You can always widen; you cannot un-delete.
3. Research the baseline before you build anything
This is a habit I run for almost every build, and it is the step that separates a structure that works from one you invented on a Saturday.
Before I built my CRM, I had my assistant run a research pass on how good CRMs are actually structured - what stages real pipelines use, which fields earn their place, what people consistently regret adding. Then I used that as the baseline and argued with it from there.
The point is not that the research is authoritative. It is that you start from established practice instead of from your own blind spots, and when you deviate you are deviating on purpose. My pipeline stages do not match the textbook, and I can tell you exactly why for each one, which I could not have done if I had never looked at the textbook.
Ask for the baseline, ask where practitioners disagree, and ask what is commonly included that usually gets abandoned. That last question is worth the whole exercise.
4. Let the AI build the structure
People skip this, and skipping it is why most Notion setups die half-built.
Do not design the databases. Describe the job and have your assistant build them.
I did not draw up my CRM. I told Claude what I needed to track, what I actually do with that information on a Tuesday, and what decision I wanted to be able to make from it. It proposed a structure, I pushed back on about a third of it, and then it created the databases, the properties, the relations between them, and the views. Same with my content pipeline. Same with the tracker holding my trade bylines and their exclusivity terms.
The request shape that works:
Here is a job I do repeatedly. Here is what I look at when I do it. Here is the decision I am trying to make. Here is what goes wrong today. Here is the baseline research from our last pass. Propose a database structure, tell me what you would leave out and why, then build it.
That "what you would leave out" clause matters. Ask for it and you get a leaner structure. Skip it and you get every property anyone could conceivably want, in a database nobody maintains past week three.
Two things I would insist on. Have it explain each property before it builds, because a property you do not understand is a property you will not fill in. And start with one database rather than six - the relations between them only make sense after you have lived in one for a week.
5. Write one page before you write a system
Open a page. Title it Flight Rules. Write one rule.
Not a framework. One decision you have already made and are tired of re-explaining, written as a sentence, with a second sentence saying why. Mine started with the publishing rule and grew from there, one argument at a time.
The temptation is to architect the whole cabinet on day one. Everyone who does that abandons it, because you end up with beautiful empty structure and no habit. The habit is the thing you are actually building.
6. Brief the seat like a new hire, using PRICE
A seat is staffed when it has a role file that needs no re-briefing. Until then it is a chat you keep re-explaining, which is where you started.
I use PRICE to write that file, because a seat's role file is an onboarding packet and PRICE is what goes in one.
- Persona - the role and the level. Who is sitting in this seat.
- Resources - the onboarding packet itself. Brand voice, audience, the canon pages it should read. Not proprietary or personally identifiable information, just the shape of who you are.
- Instructions - the playbook. What the job is, what it works from, what it hands back.
- Constraints - the working agreements. What it does not do, and what it never decides alone.
- Examples - what good looks like in your shop. The single most-skipped element, and the one that moves output quality most.
Written once into a Notion page, PRICE stops being a prompting exercise and becomes a personnel file. The seat reads it at the start of every session. You never brief it again.
Then run four questions against it, which are worth running against any AI assistant you already use:
- Does it have a named role?
- Does it have a defined job - what it works from, and what it hands back?
- Does a human own it by name?
- Is there a decision it never makes?
Four yeses and it is a seat. Anything less is a subscription with ambitions. The fourth question is the one people skip and the one that does the most work, because writing down what an agent never decides is how you find out what you actually believe about the job.
7. Build the reconciliation before you need it
Read the next section for why. The last step is deciding what checks whether the cabinet is still true, and it belongs in the build rather than bolted on later after it bites you.
Where this goes wrong
I do not want to sell you a tidy machine, so let me tell you how I broke mine this week.
I asked GUIDANCE to plan out September. It came back with a sequence built around a hard deadline it had read from my speaking calendar - a note saying the social queue had to be refilled by a certain date or the conference week would run dry.
That note had been wrong for weeks. The queue was refilled. It had been refilled well past the date in question, and the person who refilled it had no idea a note in a different database was still telling everyone otherwise. A second row sat marked not-started for work that was finished. My seat planned a month around two facts that were confident, well-organized, and dead.
Writing things down does not remove failure. It swaps one kind for another, and the new kind is quieter. When knowledge lives in somebody's head and that person leaves, you find out immediately. When it is written down and goes stale, nothing announces it, because an out-of-date row looks exactly like a current one.
So the cabinet needs a second discipline nobody enjoys. Something has to reconcile it against reality on a schedule. In my case that meant two changes: programming details do not live in event notes where the people doing the programming will never see them, and there is now a standing pass that checks what the databases claim against what actually shipped.
That pass is unglamorous and it is the difference between a knowledge base and a museum. Budget for it from the start. It is the part I underbuilt.
What it cost
Less than you would guess, and not where you would guess.
There is no code in any of this. No automation platform, no integration anyone had to wire up, no developer. It is databases and pages, set up the way you would set up a project tracker, plus one connector you authorize once.
What it cost was writing. Every rule in that cabinet is a decision I had to actually make and then defend in a sentence, and that is the real work. Most of the time I was not stuck on where something should go. I was stuck because I had been running on an unexamined preference for two years, and writing it down forced me to find out whether I believed it.
That is the return I did not expect. I set out to give my AI teammates a memory and came away with the first written account of how my business actually operates.
What this looks like inside an agency
If you run an insurance agency you already know where your version of this lives, and it is not in a wiki.
It is in the AMS, the shared drive, and one producer's head. A renewal goes smoothly because Sharon knows that carrier's quirks. A certificate request does not blow up because somebody remembers what the client's contract actually says. That knowledge is real and valuable and completely undocumented, which is why onboarding takes six months and why Sharon cannot take a real vacation.
Now put AI into that agency. The Big "I" ACT 2026 Tech Trends Report found that 55% of agencies have no written AI use policy. Not a thin one. None. So the agency's AI is held the same way Sharon's knowledge is held: informally, individually, invisibly.
That is not a technology gap. An agency's AI cannot be governed if nothing is written down, because governance is a written artifact or it is a feeling. The agency version of a Flight Rule is a written AI use policy - what client information never goes into a personal AI account, what always gets human review, and whose name is on the answer when the machine gets it wrong. That is also the first step out of Shadow AI and into something you can defend at renewal.
Research out of Boston University and BCG makes this uncomfortable rather than optional. When organizations frame AI as an employee without clear oversight attached, managers catch fewer of its errors. Putting AI on the org chart makes things worse if you skip the part where somebody owns it. The written rule is what closes that gap, and it is the cheapest item on this entire list to produce.
Start with the briefing, not the filing cabinet
I would rather be useful than sell you my setup.
If you finished this thinking you should go build a knowledge base this weekend, you are a step ahead of yourself. Nobody needs a filing cabinet before they have files. I built mine because I had seats doing real work and their decisions kept evaporating, and that is the only reason it was worth the weekend.
The cabinet is where a briefing goes to live permanently. So write the briefing first, for one job, and see whether it changes what you get back. That is what PRICE is - five things to hand an AI before you hit enter on anything that actually matters. Run one real task through it this week.
If the difference is obvious, you will know why the rest of this exists. And you will have your first page.
