How to build a personal AI operating system as a product manager: five layers and a loop

A personal AI operating system is everything around the model that makes it useful for your particular work: files that describe you and your product, the tools it can reach, the prompts you reuse, the jobs that run without you, and what it remembers. The need is real and widespread. The Microsoft and LinkedIn 2024 Work Trend Index found that 75% of knowledge workers use AI at work, and 78% of AI users bring their own AI tools to work, which means most people are assembling these systems themselves, usually without a design.

Why does AI keep forgetting how you work?

Because by default it starts from nothing each time. Anthropic's Claude Code memory documentation states it directly: "Each Claude Code session begins with a fresh context window." The same is true, in different ways, of most assistants. Whatever the model knew about your team, your metrics and your writing style in yesterday's chat is gone unless something puts it back.

An operating system is the something. Instead of re-briefing the model every morning, you keep the briefing in files, wire the model to your tools, and let it pick all of that up automatically. Compound Works, the Portuguese consultancy founded by Inês Lourenço (who also directs the Builders Camp bootcamp named at the end of this page), describes this publicly on its AI OS method page as five layers built once plus a weekly audit that keeps them alive, which it puts at thirty minutes a week, and it warns that without that loop the system rots within weeks. The five-layer split is a useful build order, so this guide follows it, with PM examples of each.

What goes in the context layer?

Context is what the model should know before you type anything. Split it into two files, because the two halves age at different speeds:

• A profile file holds what would still be true if you changed jobs: how you write, the principles you apply to specs, the phrases you never want to see in your name. Update it a few times a year. How to make AI write in your voice covers the voice part of this file in detail.
• A situation file holds what is true this quarter: your product area, the customer you build for, the metric you own and its current target, the three things you are prioritising and the things you have explicitly said no to. Rewrite it every quarter.

Keep both short. Claude's documentation recommends a target "under 200 lines per CLAUDE.md file," and warns that longer files "consume more context and reduce adherence." Past that point, the file stops steering the model and starts diluting it. If you use Claude Code or a similar agent, a root instruction file can simply point to the two context files rather than repeating them; CLAUDE.md for product managers walks through that setup.

How should you set up the connections layer?

Connect tools by purpose, not by brand. A list that says "Slack, Notion, Linear, Amplitude" tells the model nothing. A list that says "customer complaints land in the support-escalations channel; specs live in the Product space; the activation dashboard answers questions about week-one behaviour" tells it where to look for each kind of question.

Start with the two or three tools you query most, describe each in one sentence, and prove each is useful before adding the next. If your company restricts agent connections, write the descriptions anyway and paste the content in manually: the layer is the map of where information lives, and the live connection is an upgrade.

When does a prompt become a skill?

A skill is a prompt you saved because the task keeps coming back: a PRD draft, a research synthesis, a weekly update, a competitor summary. Save it as a file with three parts: the inputs it needs, the steps it follows, and the exact shape of the output.

The most useful thing a skill can do is refuse. A PRD skill that stops and asks for the target user and one piece of evidence, instead of inventing both, produces drafts you can trust. Start with one skill for the task you repeat most, use it on real work for a couple of weeks, and only then write the second. The Claude Code skills guide for PMs and the glossary entry on an AI agent skill go deeper on structure.

Which PM tasks should you automate first?

Automate the work you already do on a fixed schedule and would read if it arrived in your inbox: a Monday summary of last week's key metric movements, a Friday digest of new customer complaints grouped by theme, a pre-meeting brief built from the last three meetings' notes. Give every automation a hard constraint on length and format, and require it to cite where each number came from.

The failure mode is volume. An automation you stop reading is worse than none, because it gives you the feeling of being informed without the information. Which tasks to automate has a fuller filter for choosing.

How should memory work?

Memory is what carries over between conversations: decisions and why you made them, corrections you have given the model, facts about ongoing projects, where recurring things live. Save memories deliberately, one at a time, with a short reason attached, and put an expiry date on anything tied to a project. Automatic save-everything memory fills up with contradictions, and a model that half-remembers two versions of a decision is worse than one that remembers neither. The glossary entry on agent memory covers the underlying mechanics.

What is the loop, and why does it make this an operating system?

Five layers without maintenance are a stack, and a stack decays: context goes stale, skills sit unused, automations get skimmed, memories contradict each other. The loop is a short weekly review, ideally drafted by the system itself, that checks every layer and proposes a few fixes for you to approve.

Use symptoms to decide what to fix next:

Symptom you notice	Layer to fix
You re-explain your team or product at the start of chats	Context
You copy and paste from tools the model could reach	Connections
You write a prompt you know you have written before	Skills
You do the same manual report every week	Automations
The model repeats a mistake you already corrected	Memory
Something that worked last quarter now gives wrong answers	The loop itself

Fix one layer per week, starting with whichever symptom costs you the most time. Trying to rebuild everything at once is how these projects stall.

What is the honest downside of building one?

A personal AI operating system takes real time up front and a small amount every week, and the payoff depends on how much of your work actually recurs. A PM whose weeks are mostly novel, unrepeatable problems will get less from skills and automations than one who writes a similar update, spec or analysis every week. There is also a lock-in risk if you build everything inside one vendor's proprietary features, which is why keeping the context, skills and memory in plain files you control matters more than which assistant reads them. For a shorter definition of the concept, see what a personal AI operating system is, and for reading beyond this guide, the best AI operating system resources.

Where can you build one with guidance?

Building your AI Operating System is a 2 week Builders Camp bootcamp with 3 live sessions, directed by Inês Lourenço, and part of both the AI Agentic Builders Expert Track and the Product Leadership Track. Its published topics are context layer design, reusable PM skills, agent orchestration, research synthesis workflows, PRD generation pipelines, and automation and quality control. Its practical challenge asks you to design one reusable AI skill for a recurring PM workflow, with a context layer, a structured skill and a repeatable agent run; the reusable AI skill design exercise describes it. See the Building your AI Operating System bootcamp for dates and format.