Assume our team has no technical experience with this. Here is exactly
where we are and what we're seeing: [DESCRIBE OR SCREENSHOT]. Tell us
exactly what to do next, one step at a time, in plain language.

Phase 0 — Executive alignment & the pilot problem

Leadership only. Nothing else starts until this is done. Budget: one 2-hour session.

0.1 — Get actual leadership in the room. Not delegates.

0.2 — Run the honest constraints conversation. What AI costs (subscriptions, tokens, compute), what it risks (data leaving the building), and the two levers this method teaches — smart routing and local models. Write the company's top three fears on the board.

0.3 — Choose the pilot problem. One real, recurring, cross-department pain point:

Act as an operations consultant. Here are [3-5] recurring problems our
company faces: [LIST THEM, with rough frequency and cost of each].
For each, assess: (1) is it truly recurring or a one-off? (2) does
solving it require crossing at least two departments? (3) could a
written, AI-executable process plausibly reduce its cost? (4) can
success be measured in one number leadership feels?
Recommend ONE as our pilot, and state the single metric that would
prove it solved.

0.4 — Write the pilot problem statement. One page, filed where the whole program can see it:

PILOT PROBLEM STATEMENT — [COMPANY NAME]

THE PROBLEM: [What happens, in plain language]
FREQUENCY: [How often it recurs]
CURRENT COST: [Time and/or money per occurrence — estimate honestly]
DEPARTMENTS INVOLVED: [At least two]
WHAT "SOLVED" LOOKS LIKE: [The observable change]
THE ONE METRIC: [The single number that proves it]
CHOSEN BY: [Names] ON: [Date]

0.5 — Appoint the program owner. One named person accountable for momentum. Without an owner, enterprise programs dissolve into calendars.

0.6 — Decide scope and cohorts. Start with the departments the pilot touches. Weeks, with practice gaps — never a single offsite.

0.7 — Send the staff communication — promotion, not threat. This message determines whether you get adoption or quiet resistance:

Draft an internal announcement of our AI program for staff. Requirements:
- Honest about what's changing: we are writing our processes down so AI
  can execute the repetitive parts.
- Explicit about what is NOT changing: judgment, relationships, and
  accountability stay with people. Nobody is being trained for
  replacement; everyone is being trained to OWN processes rather than
  just perform them.
- Name the pilot problem we chose and why solving it helps everyone.
- Plain language, warm tone, no corporate AI hype.
Company context: [PASTE PILOT STATEMENT + anything cultural that matters].

✅ Phase 0 complete when: the pilot statement is filed, an owner is named, cohorts are scheduled, and staff have been told the truth about what's coming.

---

Phase 1 — The company backbone

The standard skeleton everyone builds inside. Half a day; uses the drive you already own.

1.1 — Create the company folder skeleton on your shared drive:

/company-ai/
  /_index.md            ← the master router
  /pilot/problem-statement.md
  /departments/
    /[dept-name]/
      /_node-index.md
      /skills/          ← instruction files (.md)
      /data/            ← reference material the skills point at
      /outputs/         ← finished work products
      /people/[person-name]/
  /handoffs/            ← cross-department protocols
  /governance/
    naming-conventions.md
    data-classification.md
    routing-policy.md

1.2 — Write the naming conventions: lowercase-hyphenated, verbs for skills (draft-weekly-report.md, not report.md), ISO dates, no "final-v2-REAL". Boring on purpose — legibility is what makes the network machine-navigable.

1.3 — Set baseline permissions. Each department's folder writable by that department. Tighten later; don't over-engineer now.

1.4 — Stub the master index — the file that tells any agent (and any human) what exists and where to look.

✅ Phase 1 complete when: the skeleton exists, conventions are written, and every participant has a workspace inside their department's folder.

---

Phase 2 — Foundation cohorts: the personal AI OS

All participating staff, per department. This is the AI Work OS method applied to each person's real role. ~16 hrs per cohort across several weeks.

2.1 — Process capture. Three recurring tasks from each person's actual week:

TASK: [name it]
TRIGGER: [what makes this task start — a day, an email, a request]
INPUTS: [what I need before I can start]
STEPS: [numbered, as I actually do them — including the annoying parts]
STANDARDS: [what "done well" means — the checks I run before it ships]
OUTPUT: [what exists at the end, and who receives it]
TIME IT TAKES ME: [honest estimate]

2.2 — Prompt fundamentals. Role, task, context, constraints, output format, examples — one prompt built through 3–4 deliberate iterations.

2.3 — Folders. Instructions / data / outputs, inside the company skeleton — not on a desktop, not in a personal drive.

2.4 — First skills. Two processes become working skill files the AI executes:

# SKILL: [verb-phrase name, e.g., draft-weekly-sales-summary]

GOAL: [what this skill produces and for whom]
WHEN TO USE: [the trigger]
INPUTS REQUIRED: [files, data, or answers — and where they live in /data/]
STEPS:
1. [instruction to the AI, written as you'd brief a capable colleague]
STANDARDS: [the quality bar — tone, format, what must always/never appear]
OUTPUT: [exact format and where it's saved in /outputs/]
CHECK YOU DID IT RIGHT: [2-3 verifiable checks the AI runs on its own
  output before presenting it]

Where the output disappoints, fix the file, not the chat — the improvement is now permanent.

2.5 — Personal index. A short router file listing each person's skills and when to use each.

2.6 — The cold handoff. The Foundation exam: a colleague runs one of your skills with no explanation. If it runs for someone else, it's real — and the company just gained documentation, onboarding material, and continuity insurance in one artifact.

2.7 — Identify champions by observation. Whose skills come out cleanest? Who do colleagues naturally ask? One champion per department — chosen by evidence, not seniority.

✅ Phase 2 complete when: every participant has ≥2 skills that passed a cold handoff, everything lives in the skeleton, and each department has a named champion.

---

Phase 3 — Departmental nodes

Champions consolidate their department's output into one governed library.

3.1 — Merge and deduplicate. Three people's versions of "draft the client update" become one skill with the best of each.

3.2 — Enforce one source of truth:

Read every skill file in /departments/[DEPT]/skills/. Identify:
(1) duplicates or near-duplicates describing the same process,
(2) skills that restate information that lives in a /data/ file
    instead of referencing it,
(3) naming convention violations per /governance/naming-conventions.md.
Propose the merged, deduplicated skill list. Do not delete anything
yet — output the plan for my review.

3.3 — Install the review gate. Nothing enters /skills/ without the champion's pass.

3.4 — Write the node index — what the department does, its skills, its data, what it receives and hands to others, and its owner.

3.5 — The node handoff test. Someone from a different department uses only the index to have an AI run one of the department's skills cold.

✅ Phase 3 complete when: each node has a deduplicated library, a working index, a named owner, a review gate — and passed a cross-department cold run.

---

Phase 4 — Linking the nodes: the work network

The jump from departments-with-AI to an AI-native company.

4.1 — Complete the master index. An agent given only this file should know where to look for anything.

4.2 — Write the handoff protocols — cross-department interfaces as files:

# HANDOFF: [from-dept] → [to-dept]: [what's being handed]

TRIGGER: [what causes this handoff]
THE SENDER PROVIDES: [exact artifact, format, and required fields]
QUALITY BAR: [what the receiver may assume is already true]
THE RECEIVER DOES: [which of their skills consumes this input]
RETURNS: [what comes back, in what format, by when]
IF THE INPUT IS INCOMPLETE: [named fallback — who gets asked, not
  silent guessing]

The handoff now runs the same way regardless of who — or what — executes either side.

4.3 — Map permissions to the network. HR and finance usually seal first; enforce with your drive's own sharing settings.

4.4 — Run one real cross-department workflow end to end with an agent. Where it snags, fix the files — the fix is permanent.

4.5 — The adaptability check. If we reorganised team X tomorrow, what breaks? The correct answer is now "we re-point some references." If the answer is still "we'd lose how things are done," find what's still living in heads and file it.

✅ Phase 4 complete when: the master index is truthful, the pilot-relevant handoffs are written, and one real cross-department workflow has run end to end.

---

Phase 5 — Data privacy & governance

Sorting before securing. Most enterprise AI fear dissolves once this sorting is explicit.

5.1 — Classify your data into three lanes:

| Lane | Definition | May touch |

|---|---|---|

| GREEN | Public or harmless if seen | Any model, cloud or local |

| YELLOW | Internal; needs contractual cover | Cloud models under business terms, with care |

| RED | Never leaves the building — personal data, health, payroll, legal, anything regulated | Local models only |

5.2 — Research your regulatory floor:

Our company operates in [COUNTRY] in the [SECTOR] sector. List the data
protection and sector regulations that govern us (e.g., NDPR in Nigeria),
each with a one-paragraph plain-language summary of what it requires of a
company our size, and flag anything that constrains sending data to
cloud AI services. This is research guidance, not legal advice — we will
verify with counsel.

5.3 — Write the routing policy. Every skill touching YELLOW or RED data gets a DATA LANE: line at the top — the routing travels with the skill.

5.4 — Audit the existing network against the policy and clear the fix list.

Rules that never change: the lane is written in the file, not remembered; reclassification is a governance edit, not an improvisation; and "just this once" to the cloud with RED data is how companies end up in the news.

✅ Phase 5 complete when: every data type has a lane, the routing policy is written, and the audit's fix list is cleared.

---

Phase 6 — Local models: private AI on your own hardware

The lane that makes RED data workable. Free software; hardware you already own.

6.1 — Inventory the hardware. RAM, GPU, free disk. Rules of thumb: 8 GB RAM runs a small quantised text model (~3–4B) — enough for structured skill execution on RED data; 16 GB runs a mid model (~7–8B) plus a small vision model; a dedicated machine left on overnight is your free batch-processing engine.

6.2 — Install the runner:

Assume no technical experience. We're on [WINDOWS/MAC/LINUX] with [X GB
RAM, GPU: yes/no]. Give exact step-by-step instructions to install
[Ollama / LM Studio], verify it works, and download a quantised model
appropriate for this hardware — recommend the specific model and size,
and tell us what response speed to realistically expect.

6.3 — Set expectations. A small local model is not the cloud frontier model — it is sufficient for structured skill execution on RED data, which is its whole job.

6.4 — Point it at the same files. The portability payoff: the local model reads the identical skill files the cloud model reads. Run a RED-lane skill with the network cable out, to prove it to yourselves.

6.5 — If your pilot involves media, pull a small local vision model too — the free labelling engine the systems designs depend on.

6.6 — Write the local model runbook: which machine, which model, who owns it — and the rule: RED skills run here, no exceptions, no "just this once."

✅ Phase 6 complete when: a RED-lane skill has run correctly on a local model, offline, and the runbook exists.

---

Phase 7 — Systems thinking under constraints

The keystone. The reframe: don't bring AI to your problems — bring your problems to the shape AI can eat.

7.1 — Learn the shape on the worked example. You need to search 10,000 video files. The naive design runs an expensive vision model over video every time anyone searches — ruinous, and it recurs per query. The systems design: extract one frame every 30 seconds (free, mechanical), label those frames once with a free local vision model into text descriptions — and from that day on, every search is a cheap text query. One preprocessing pass converts an expensive recurring problem into a free recurring one.

The shape to memorise: expensive-per-query → cheap-once-then-free. People who see this shape stop asking "which AI tool should we buy?" and start asking "what's the expensive operation, and can it be precomputed?"

7.2 — Learn the storage lever. Large content lives on the drive you already pay for; your platform's database holds only links and searchable text. Ask of every storage decision: what's the cheapest place this can live while staying retrievable?

7.3 — Run the decomposition sheet on a real problem — five questions, one page: (1) name the expensive operation, (2) what can be precomputed?, (3) cheapest sufficient model per step, (4) where should the data live?, (5) the costed before/after — naive versus smart, with payback period. And the human anchors, named.

7.4 — Pressure-test the designs:

Here is our systems design for [PROBLEM], produced with our decomposition
sheet: [PASTE COMPLETED SHEET]. Act as a skeptical infrastructure
engineer: (1) check our cost estimates for the naive and smart versions,
(2) find the hidden recurring costs we missed, (3) identify any step
where a cheaper or local model would suffice, (4) flag anything that
violates our routing policy. Then output the corrected sheet.

7.5 — File the completed sheets. They are reusable case studies — and the habit of writing them is the culture change.

✅ Phase 7 complete when: every participant has produced one costed decomposition of a real problem, pressure-tested and filed.

---

Phase 8 — Designing AI-native processes

Redesigning as if AI existed when the process was invented.

8.1 — Pick one existing process and redesign it:

Here is one of our current processes, as documented in our node:
[PASTE THE SKILL/PROCESS FILES]. Redesign it as if AI had existed when
it was invented:
- Which steps collapse or disappear entirely?
- Which become skills, and in which department's node do they live?
- Which steps route to a local model (check the DATA LANE) vs cloud?
- What can be precomputed once instead of done every time?
- What MUST stay human — judgment calls, relationship moments,
  accountability points? Mark these explicitly; they are load-bearing.
Output: the redesigned process as skill files, plus a one-page
before/after with time and cost per run for each version.

8.2 — Mark the human anchors visibly. "OWNER REVIEWS AND APPROVES before send" is a written step, with a name attached. This is what owning a process looks like on paper.

8.3 — Present the before/after to leadership with the metric they feel.

✅ Phase 8 complete when: one process runs in its redesigned form and every human anchor in it has a name.

---

Phase 9 — The pilot

The graduation. Everything built so far aims here.

Decompose the pilot problem with the full sheet. Build it across at least two linked nodes via their handoff files, every data touch obeying the routing policy — RED on local, provably. Test on real inputs from a real recent occurrence. Rehearse once. Then demonstrate live to leadership: the problem stated from the Phase 0 one-pager, the solution running end to end, and the one metric — before and after.

The pilot's design document then enters the master index as the company's first case-study skill: the template for every problem after it.

✅ Phase 9 complete when: leadership has watched the pilot problem run through the network, the metric moved, and the case study is filed.

---

Phase 10 — Sustain & scale

The unglamorous phase that decides whether this was a transformation or an event.

• Skills get fixed the moment an output disappoints — file, not chat. Node owners sweep their index monthly.
• Onboard through the nodes. Every new hire's first week: read the department's node index, run two of its skills. The network is now the onboarding.
• Keep the review gate alive. The day it slips, the library rots.
• Re-run the decomposition quarterly on the current most expensive recurring problem.
• Revisit the routing policy when models change — what needed the cloud last quarter may run on your own hardware now.
• The honest annual question: if our best person left tomorrow, what walks out the door with them? File whatever the answer surfaces.

---

Where to go from here

Want this delivered inside your company? This checklist is the implementation guide behind 2nd Brain Training — the PxLabs enterprise program, on-site or remote: executive briefing, Foundation cohorts for staff, the Advanced network track, and a live pilot solved as the graduation. Bring your hardest problem.

Want the personal version first? The Foundation track is our live course 0 to 1 with AI — the same personal AI operating system method, taught from zero, September cohort open now. The build-your-own-product path is Product Development, with its own free Complete Build Checklist.

Don't do it alone. The PxLabs community is where these methods get sharpened — the builders' forum, every template in this post in the copy-paste prompt library, a project showcase, Thursday Vibe Sessions and meet-ups across Nigeria. ₦30,000/year.

The pilot ships, the sheets get filed, the network stays yours.