Photorealistic Open Stack masthead with three connected modules on a dark personal workstation.
Open Stack
Open Stack.
Most AI stack advice starts in the wrong place. It asks which tools to install before it asks where your work is leaking time, so people end up with impressive demos and generic systems they never actually use.
Open Stack flips the order. Diagnose the bottleneck first: capability, context, or work movement. Then use the primitive that fixes it: Open Skills, Open Brain, or Open Engine. The primitives are reusable. Your edge comes from making them personal.
The primitives are the stack. Start with the smallest one that solves the real bottleneck, and do not buy the fake one-click setup story.
3 primitives skills, brain, engineSkills first default starting pointJuly 1, 2026 last updated
Where should you start?
Pick the bottleneck. The right starting point is the place where your current setup is already leaking time.
01 / MapThe stack is the sequence of missing pieces.If the agent cannot do the job, give it a skill. If it keeps losing context, give it a brain. If work disappears between chats, give it an engine.
Open sectionSection open
Use this page as a router. Diagnose the bottleneck, choose the primitive that fixes that bottleneck, then follow the source-of-truth setup path instead of copying a generic stack by reflex.
The one-click magic button is the trap.
The pitch is tempting: click once, get a personal AI operating system, never think about setup again. But a system cannot be personal if nobody asks what your work is, what your agent may do, what context matters, or where the human approval line sits.
That is the part the demo skips. It is also the part that creates the advantage. The work of choosing what your agents know, how they act, where memory lives, and how work moves is the work that unlocks the superpowers.
The red flag is pretending the personal decisions do not exist.
You do
Bring your actual workflows, accounts, judgment, taste, and boundaries.
The AI does
Maps those inputs into skills, memory, and work-routing primitives without pretending the personalization can be skipped.
Show the full prompt
<task>
Help me choose where to start with the Open Stack.
</task>
<context>
Open Skills are reusable agent primitives.
Open Brain is the durable memory/context layer.
Open Engine is the work movement layer for tasks, limits, approvals, receipts, and handoffs.
</context>
<instructions>
Ask me one question at a time about the work I want AI to help with, what already repeats, where context gets lost, and where tasks get stuck.
Classify my bottleneck as capability, context, work movement, or a mix of those three.
Then recommend the first primitive to set up, the second primitive to add later, and the one primitive I should not touch yet.
</instructions>
<constraints>
Do not sell this as a one-click setup.
Keep the recommendation grounded in my actual work, not a generic stack diagram.
</constraints>
<deliverable>
A short route: start here, do this first, avoid this for now, and why.
</deliverable>
Personalization is the edge.
The primitives are reusable. The application is personal. Two people can start from the same Open Skills library, the same Open Brain architecture, and the same Open Engine queue pattern and end up with completely different systems because their work, taste, files, sources, and judgment are different.
That is the point. You are learning the principles well enough that your AI setup fits your work better than anyone else's generic clone.
Start from the need. The primitive choice follows from the bottleneck.
You do
Choose the real workflows, private context, and approval boundaries that make the stack yours.
The AI does
Turns those choices into install prompts, local docs, source maps, and verification checks.
Show the full prompt
<task>
Interview me for the personal layer of my Open Stack.
</task>
<inputs_to_collect>
<input>The workflows I repeat every week.</input>
<input>The context I keep re-explaining to AI tools.</input>
<input>The decisions I never want an AI to make without me.</input>
<input>The files, tools, accounts, and knowledge bases I actually use.</input>
</inputs_to_collect>
<deliverable>
Give me a personal stack profile with:
1. Three likely Open Skills.
2. The first durable context Open Brain should remember.
3. The smallest Open Engine queue worth building.
4. Human-only boundaries.
</deliverable>
02 / Start with skillsOpen Skills first: make the agent capable at one job.Open Skills are reusable operating procedures that teach an agent how you want a specific kind of work done.
Open sectionSection open
Start here because one useful skill can pay off before you build a database, a queue, or a full operating system. Pick one job, make it repeatable, test it on real work, then come back for the next primitive.
What Open Skills is for.
Use Open Skills when the agent is close, but not yet reliable: transcribing media, building a testing runbook, generating images through your chosen gateway, packaging dense output as HTML, drafting in a specific voice, or running a workflow the same way every time.
A good skill is an operating procedure with triggers, inputs, tools, boundaries, verification, and enough local taste to change the agent's behavior.
The right first skill comes from an interview, not a generic bundle install.
You do
Pick a specific repeated job and decide what good output looks like.
The AI does
Creates or adapts the smallest skill that makes that job repeatable.
Show the full prompt
<task>
Help me choose my first Open Skill.
</task>
<interview>
Ask me which recurring tasks I want help with. Offer examples only after I answer:
media transcription, current-information search, heavy file ingestion, HTML artifacts, frontend taste, testing runbooks, stakeholder updates, session-to-skill extraction.
</interview>
<selection_rule>
Recommend the smallest skill that improves a real workflow this week.
Do not recommend a full stack setup if one skill solves the current pain.
</selection_rule>
<deliverables>
1. The skill to start with.
2. Why that skill earns its place.
3. What information you need from me before installing or adapting it.
4. A verification task that proves it works.
</deliverables>
When not to start with skills.
Do not start with Open Skills if the agent already knows how to do the work and the real failure is somewhere else. If it keeps forgetting who you are, that is Open Brain territory. If it cannot tell what task is next, who owns it, what is blocked, or what needs approval, that is Open Engine territory.
Skills make agents more capable. Capability does not replace memory, and it does not replace a work loop.
You do
Name the bottleneck honestly: capability, memory, or work movement.
The AI does
Routes you away from a skill install when a memory layer or queue would solve the real problem.
Show the full prompt
<task>
Decide whether my problem is a skill problem.
</task>
<symptoms>
I will describe a frustrating AI workflow.
</symptoms>
<classification>
Classify it as:
- Skill: the agent needs a repeatable procedure or tool use pattern.
- Brain: the agent lacks durable memory or personal context.
- Engine: work state, ownership, approvals, or handoffs are breaking.
</classification>
<deliverable>
Give me the classification, the evidence, and the smallest next step.
</deliverable>
How Open Skills combines with the rest.
A skill gets stronger when Open Brain remembers which skills you trust, what defaults you chose, and what changed after real tests. Open Engine gets stronger when its runner can call approved skills during queue work.
That is the first composition: Skills make the agent capable. Brain remembers when and how that capability should be used. Engine moves real work through it with receipts.
You do
Approve which skills are allowed to run automatically and which require a fresh ask.
The AI does
Records the approved skill list and wires it into memory or queue rules without expanding authority silently.
Show the full prompt
<task>
Create a safe Open Skills adoption map.
</task>
<requirements>
List the Open Skills I already have or want.
For each one, classify it as:
- Manual only.
- Agent may use after asking.
- Agent may use automatically inside a specific workflow.
</requirements>
<constraints>
External actions, account changes, secrets, publishing, billing, and destructive changes always need human approval.
</constraints>
<deliverable>
A table I can paste into my Open Brain context or Open Engine private setup issue.
</deliverable>
03 / Add memoryOpen Brain second: stop re-explaining yourself.Open Brain is the durable memory and context layer: a place for your AI tools to read and write useful knowledge through one open protocol.
Open sectionSection open
Add Open Brain when repeated context is the bottleneck. Point your coding agent at the OB1 repo and let it walk the maintained setup path one step at a time.
What Open Brain is for.
Use Open Brain when the same context keeps getting re-explained: goals, contacts, working preferences, project facts, source notes, meeting outcomes, decisions, and useful memories that should survive the current chat.
But durable does not mean unquestioned. Treat agent-written memory as evidence by default. Promote it to instruction only when a human confirms it or it comes from a trusted import.
Open Brain can be built agent-first: the agent reads the setup docs, the human handles accounts and secrets.
You do
Decide what is worth remembering, what is private, and which memories can guide future behavior.
The AI does
Helps stand up the database, MCP connection, capture flow, search, and review patterns from the OB1 source docs.
Show the full prompt
<task>
Help me decide what my Open Brain should remember first.
</task>
<interview>
Ask me about the context I repeat, the projects I want continuity for, and the sources I trust.
</interview>
<policy>
Separate memories into:
- Evidence: useful context, not binding.
- Instruction: can guide future agent behavior.
- Private or excluded: should not be stored or recalled automatically.
</policy>
<deliverable>
A first-memory plan with five starter memory categories and the human review rule for each.
</deliverable>
Where the setup source of truth lives.
The Open Brain source of truth is the OB1 repository. Its README points new builders to the full setup guide and the AI-assisted setup guide. This page should not duplicate those docs because duplicated setup docs become stale the moment the real repo changes.
Use the AI-assisted route if you are building with Codex, Cursor, Claude Code, Windsurf, OpenClaw, or another agent that can read files and run commands.
You do
Create accounts, copy secrets into your private credential tracker, approve browser-only settings, and verify final behavior.
The AI does
Reads docs/01-getting-started.md and docs/04-ai-assisted-setup.md, runs local commands where allowed, and diagnoses setup errors from logs.
Show the full prompt
<task>
Walk me through building Open Brain from the OB1 source docs.
</task>
<source_of_truth>
Use the OB1 repository. Read docs/01-getting-started.md and docs/04-ai-assisted-setup.md before giving instructions.
</source_of_truth>
<workflow>
Go step by step. Do not improvise setup code when the guide provides source code or SQL.
Tell me exactly when I need to use a browser, create an account, copy a secret, or approve an auth flow.
</workflow>
<verification>
After each major part, tell me the expected test, the actual result, and the next fix if it failed.
</verification>
How Open Brain combines with the rest.
Open Brain can remember which Open Skills are installed, what defaults you chose, what the last verification proved, and which boundaries are human-only. Open Engine can read that context before claiming a task, then write back compact receipts after work finishes.
That is the useful version of memory: it supports the work without silently expanding the agent's authority.
Not every memory deserves the same authority. That distinction keeps durable context useful.
You do
Approve what memory can be used as instruction and what stays evidence only.
The AI does
Builds recall and write-back rules so future work starts with relevant context without smuggling in unreviewed authority.
Show the full prompt
<task>
Draft my Open Brain use policy for agent work.
</task>
<requirements>
Define what agents may recall before work, what they may write back after work, and what requires human confirmation before it becomes instruction.
</requirements>
<boundaries>
Do not store raw secrets.
Do not let agent-written memory become binding policy without review.
Keep private project context scoped to the projects where it belongs.
</boundaries>
<deliverable>
A short memory policy I can paste into my agent instructions.
</deliverable>
04 / Move workOpen Engine third: stop losing work between chats.Open Engine is the work movement layer: tasks, context, limits, status, approvals, receipts, and handoffs.
Open sectionSection open
Build Open Engine after you know which capabilities matter and what context should persist. It earns its ceremony by making ownership, blocking, review, and receipts visible.
What Open Engine is for.
Use Open Engine when agent work has started to disappear into chat threads: no clear owner, no claim lock, no status ledger, no approval boundary, no blocked state, no receipt, no clean handoff.
Do not start here if you only need one personal skill or one memory experiment. A queue adds ceremony. It earns that ceremony when work gets lost without it.
The ledger is the boring part that makes the exciting part operable.
You do
Choose the task system, own approvals, answer blockers, and decide what gets reviewed.
The AI does
Sets up the issue statuses, labels, private context, queue runner, ledger, receipts, and smoke tests from the Open Engine guide.
Show the full prompt
<task>
Decide whether I am ready for Open Engine.
</task>
<interview>
Ask me what work is currently getting lost, whether I use Linear or another issue tracker, how many agent runtimes I use, and what approval boundaries matter.
</interview>
<decision_rule>
Recommend Open Engine only if visible task state, handoffs, receipts, or recurring runner behavior would solve a real problem.
</decision_rule>
<deliverable>
Tell me: build now, wait, or steal only the concepts. Include the smallest useful version.
</deliverable>
Where the setup source of truth lives.
The Open Engine setup path already exists as a full guide at /open-engine. Use that page when you are ready to build the queue, connect Linear MCP, create statuses, write private setup context, install optional Standing Skills, and smoke-test the loop.
This page routes you there. It should not restate every status, template, and receipt because the setup guide is the source of truth.
You do
Handle Linear account choices, auth flows, browser-only settings, final approval, and destructive or outward-facing actions.
The AI does
Reads the Open Engine guide, turns the templates into your exact names, and verifies each queue behavior before moving on.
Show the full prompt
<task>
Walk me through the Open Engine setup guide.
</task>
<source_of_truth>
Use https://unlock-ai.natebjones.com/open-engine or the local Open Engine guide source if you are inside the repo.
</source_of_truth>
<workflow>
Go one step at a time.
Ask me before creating or changing Linear statuses, labels, projects, automations, or public/customer-facing workflows.
</workflow>
<verification>
Prove the basic queue smoke test, blocked/resume behavior, human-hold behavior, and optional skill directory behavior before calling setup complete.
</verification>
How Open Engine combines with the rest.
Open Engine can point agents at approved Open Skills and require them to check Open Brain context before work. Then it can require receipts after work: what changed, what was verified, what got blocked, and what should be remembered.
This is the full loop: Skills make the agent capable, Brain makes context durable, Engine makes work visible and resumable.
The full loop is capability plus memory plus visible work movement.
You do
Define which skills are approved for queue work and which memories are allowed to influence task execution.
The AI does
Writes those rules into the runner and leaves receipts when it uses them.
Show the full prompt
<task>
Draft the integration rules for my Open Engine runner.
</task>
<rules_to_define>
1. Which Open Skills the runner may use automatically.
2. Which Open Brain context the runner must recall before task work.
3. Which actions require human approval every time.
4. Which receipts the runner must leave after work.
</rules_to_define>
<deliverable>
A runner policy I can paste into a private setup issue or local agent instruction file.
</deliverable>
05 / Choose your pathYou do not have to adopt the whole stack.Use all three, any two, one alone, modified versions, or only the concepts. The operating principle matters more than cloning the surface.
Open sectionSection open
The recommended order is Open Skills, then Open Brain, then Open Engine. Break that order when your bottleneck gives you a better answer.
The default order: Skills, Brain, Engine.
Start with Open Skills because one useful primitive can improve real work immediately. Add Open Brain because durable context makes every future run better. Build Open Engine because a queue is most useful after you know which capabilities and context should move through it.
Treat that order as a recommendation. If your current pain is lost tasks, start with Engine. If your current pain is repeated context, start with Brain. If your current pain is a missing capability, start with Skills.
You can adopt the primitives in pieces. Composition is optional until the work demands it.
You do
Pick the bottleneck you actually have today.
The AI does
Turns the bottleneck into a first-step plan and refuses unnecessary ceremony.
Show the full prompt
<task>
Make me a 30-day Open Stack adoption plan.
</task>
<order>
Default order: Open Skills, then Open Brain, then Open Engine.
</order>
<adaptation_rule>
Change the order if my bottleneck makes another starting point more practical.
</adaptation_rule>
<deliverable>
Week 1, Week 2, Week 3, Week 4.
Each week should have one concrete setup or adaptation task, one verification step, and one reason it matters.
</deliverable>
It is fine to steal only the concepts.
You can use the Open Skills directory but write your own skills. You can use Open Brain's memory pattern with a different database. You can use Open Engine's receipt vocabulary in GitHub Issues, Notion, Trello, or a local markdown queue. The stack is open because the ideas travel.
Keep the discipline when you change the surface. A queue without receipts is a prettier inbox. Memory without review becomes folklore. Skills without verification become vibes in markdown.
You do
Keep the principles that fit your tools and discard the parts that add more burden than clarity.
The AI does
Adapts the primitives to your current stack while preserving the job each primitive is supposed to do.
Show the full prompt
<task>
Adapt Open Stack principles to my existing tools.
</task>
<inputs_to_collect>
Ask what I already use for notes, tasks, source control, chat, automation, and AI agents.
</inputs_to_collect>
<mapping>
Map each Open Stack job to my existing tool:
- Reusable capability.
- Durable context.
- Work movement.
- Approval boundaries.
- Receipts and verification.
</mapping>
<deliverable>
A practical adaptation map. Tell me which Open Stack pieces to use directly, which to modify, and which to ignore.
</deliverable>
Agents get you most of the way there. Humans still own judgment.
Agents can read docs, inspect repos, write setup files, run local commands, draft skills, create templates, diagnose logs, and verify many behaviors. Humans still handle accounts, auth, secrets, browser-only settings, billing, external publishing, destructive changes, customer-facing actions, and final judgment.
A serious setup writes that boundary down. A fake magic setup blurs it because the pitch sounds better when nobody asks who approved the dangerous parts.
The boundary is part of the system. Write it down before automation gets interesting.
You do
Own secrets, approvals, account choices, billing, publishing, deletion, and final go/no-go judgment.
The AI does
Prepares exact steps, runs safe local work, stops at approval gates, and records what was verified.
Show the full prompt
<task>
Write the human-vs-agent boundary for my Open Stack setup.
</task>
<requirements>
Create a two-column policy:
- The agent may do.
- The human must do or approve.
</requirements>
<must_include_human_only>
Accounts, auth, secrets, browser-only settings, billing, destructive changes, public posting, publishing, customer-facing actions, and final judgment.
</must_include_human_only>
<deliverable>
A concise policy I can paste into AGENTS.md, CLAUDE.md, or a private Open Engine setup issue.
</deliverable>
Ready to build? Source routes, not duplicated manuals.
This page helps you choose what to build and why. When the route is clear, use the maintained setup paths below instead of a pasted install manual that will drift out of date.
