TL;DR: Your coding agent guesses whatever your project leaves unsaid: the test command, the folders it may change, which of two prices is current. You pay for each guess in review time. Four small files give most of those answers once, for every agent. The free Second Brain Starter ships the first three files. You add the fourth yourself.

I write Code Meet AI, the newsletter where I document how I actually use AI to ship real products, receipts included. New guides land there first.

If you run a coding agent on a project most days, this is the setup that ends the same correction every session. The last piece, How to brief an AI agent in six lines, gave every task six questions to answer before an agent starts: context, owner, effects, evidence, continuity and learning. This one moves most of those answers into the project itself, so you write them once.

Your agent forgets everything between sessions

Every session starts from zero. A project that is ready for an agent writes the answers down where the agent looks first: what the project is, how to prove a change works, what is off limits, and where each fact lives.

The method behind this is ICM, the Interpretable Context Methodology: small files point to the next file, so the agent reads only what the task needs. Jake Van Clief and David McDermott wrote it up (arXiv:2603.16021). My own second brain runs on it, and here it moves from a folder of notes to a code project.

Four small files are enough to start

Say you have a small app. It keeps its data in Supabase and takes payments with Stripe. Four files make it agent-ready.

1. One main file that every coding agent reads first, with the commands that prove a change works.
2. A one-line file for Claude Code that sends it to the main file.
3. A facts file, where each price, plan name and setting has one home.
4. A short file inside the payments folder, with stricter rules for the Stripe code.

The main file follows an open format called AGENTS.md, “used by over 60k open-source projects” according to its site. Recent versions of Claude Code read it when a project has no CLAUDE.md of its own, and when it has one, a single import line pulls it in (Claude Code docs).

1. Send every agent to the same file first

One front door saves every agent the search. My own second brain’s Claude file holds exactly one line, and so does the one in Spec Harness, my open-source kit for code projects:

@AGENTS.md

Anything only Claude needs goes below the import. Say the only Claude habit you want is a planning step before changes to the payments folder. The whole file then reads:

@AGENTS.md

Before you change anything in the payments folder, show me a plan first.

Looking after it takes almost no work. Every rule that all agents need goes in the main file, and the Claude file gains a line only when a habit applies to Claude alone. When it grows past a few lines, move the extra lines into the main file. Keep the main file short. The same Claude Code docs say “target under 200 lines per CLAUDE.md file. Longer files consume more context and reduce adherence.”

2. Give each fact one home

Two prices in two files is one price too many. The agent picks one, and you find out which in review. Name the one home, and tell the agent to check any copy against it.

Facts live in docs/facts.md. If you find a value anywhere else, check it against that file and tell me.

3. Fence what breaks quietly

Some parts of a project fail without noise: the payment webhook, the database schema, anything that emails your users. Put a written fence around them, and a rule that says stop and ask. The line below does three jobs. The two names are the places where a mistake costs the most and shows up latest. “Without my yes” makes you the gate. “Stop and show me the plan” makes the agent list what it would change before it touches anything, so you review a plan and skip the diff afterwards.

Never change the payments folder or the database schema without my yes. Stop and show me the plan.

Swap in your own folders, such as auth, migrations or billing settings, and keep the list short, because a long list gets skimmed. Say the agent is fixing a bug and finds a payment helper that looks wrong. With the fence it stops and asks you first.

The agents.md site says how a second file works: “The closest AGENTS.md to the edited file wins.” So the file inside the payments folder can be stricter than the main one. One catch for Claude Code. The docs say “By default, Claude reads AGENTS.md only when you have no CLAUDE.md in your working directory or above it”, and this project has one. I tested it: with a CLAUDE.md at the root, Claude read a file in the payments folder and never loaded that folder’s AGENTS.md. The fix is a one-line CLAUDE.md in the payments folder, and then both files load when Claude works there.

The payments folder holds two files. The first is the stricter rule:

payments/AGENTS.md
Never change a webhook handler or a price ID. Show me the plan and wait for my yes.

The second is the one-line import that makes Claude Code load it:

payments/CLAUDE.md
@AGENTS.md

4. Say what done means

An agent that guesses the test command runs the wrong one, or none, and reports done. Write the exact commands and what done looks like.

Done means: the tests pass and the app starts. Run both commands from the Commands section and paste their last lines.

5. Write down what is in flight

The next session starts blind again. One short file with the work in progress and the open questions lets the next agent pick up where this one stopped.

Before you stop, update docs/now.md: what changed, what is left, what is waiting for me.

6. Turn a repeated miss into a rule

Correcting the agent in chat fixes one session. When the same mistake comes back, write the fix into the file, with the date and the reason. My own global file has one from 3 August: read the project’s own rules before you touch it. It started as one line, added after a real violation.

When a mistake repeats, add one dated rule to this file with the reason. Leave one-off mistakes out.

How I run agentic coding: Spec Harness

Spec Harness is what I use for coding with agents. It is spec-driven development wrapped in a harness: the spec comes first, and every step after it leaves a record the next session can read. It is free and open source.

Six roles do the core work, one job each. The repo holds more agent files for other jobs. The split exists because the agent that writes the code should never be the one that checks it.

The researcher and planner prepare the work, the implementer and tester build and run it, and the reviewer checks style and scope. The verifier matters most. It is a separate agent that did not write the code, it checks the result against the goal, and its only answer is PASS or FAIL. A FAIL sends the work back to the implementer.

The files from this article sit around those roles. Rules only tighten, and a failure does not become policy automatically: when something breaks, the cause is logged first.

Spec Harness adds the same front door, a rules index and a memory folder

The four files cover the first four of the six answers: context, owner, effects and evidence. Continuity and learning need a place to write too, and a growing project needs a map of where everything lives. Spec Harness installs all of that in a code project, using other file names for the same jobs.

Install it and you get the same front door and a rules index that says where each kind of fact lives. It also adds a memory folder whose active file every session reads, and a learning log for misses. Its own AGENTS.md states that it adds no dependency and never edits your application code during install. Every rule stays marked PENDING, which means not yet written from your own code and checked, until that work is done.

your-project/
├── CLAUDE.md               @AGENTS.md, then the startup order
├── AGENTS.md               hard limits, and what done means
├── RULES.md                rules for one folder; the nearest one wins
├── ai_rules/
│   ├── globalRules.md      where each kind of fact lives
│   ├── context_map.md      the real modules, mapped after install
│   └── rules/frequent_rules.md
├── .memory/
│   ├── 40-active.md        what is in flight, read every session
│   ├── 50-progress.md
│   └── 60-decisions.md     one home for each decision
└── learning/NOTES.md       misses, before they become rules

One line from the main file it installs is worth copying into any project, harness or not:

Never invent an import, function, type, or component. Confirm it exists (grep/Read/index) before you call it.

Four checks, written before any code

Say you ask for a button that lets users register with Gmail. You first write the goal as checks that are either true or false: tapping the button opens Google sign-in, a new user gets an account, an existing user is signed in, and a cancelled sign-in changes nothing.

1. The researcher finds where sign-up lives and sees that the auth folder is fenced, so the work will stop and ask. The planner splits the goal into tasks: add the button, connect Google sign-in, create or find the user, handle a cancelled sign-in.
2. The implementer writes the button with its tests, one task at a time, and the tester runs the suite.
3. The verifier goes through the four checks. If a cancelled sign-in still creates an account, that check fails and the work returns to the implementer.
4. The reviewer checks that the change touches sign-up and nothing else, and the cause of any miss goes into the learning log. A failure does not become policy automatically.

Keep the README, and give the agent a shorter file

The fair objection: your README already explains the project. It does, for a person who can ask a colleague when a step is unclear. An agent acts on what it reads first. So its file is shorter and gives orders: run this, never touch that, stop here. Keep both, and let the agent file point to the README for the long story.

These files ask, and a hook enforces

A hook is a small script the tool runs before or after an action. The Claude Code docs put the limit plainly: “To block an action regardless of what Claude decides, use a PreToolUse hook.” So write the rule in the file, and if breaking it would cost you money or data, add a hook as well.

A file asks nicely. A hook just says no.

Make one project agent-ready this week

Pick the project you open most often with an agent, then:

• Write the main file: what the project is, the two commands that prove a change works, and the folders that need your yes.
• Add the one-line Claude file that imports it.
• Next time the agent guesses wrong, add one dated line to the file instead of typing the correction again.

The free Second Brain Starter gives you the main file, the Claude import and a facts file for each project. Builder AI OS is the paid layer for later, once one project runs well.

Start of the series: How to scale a Second Brain into a Company Brain.

The full series lives in Code Meet AI, my newsletter. The next piece goes there first.

I write Code Meet AI, the newsletter where I document how I actually use AI to ship real products, receipts included. New guides land there first.

You hand an agent a task and plenty of context, and the handoff still goes wrong. Six short questions, answered before the task starts, close the gap I kept hitting: the agent had the files and still did not know who owned a fact, what it could change, or how to prove the work. They sit on top of a method called ICM, so that comes first.

Part 1: ICM lets your folders do the navigating

ICM stands for Interpretable Context Methodology. It is how you arrange files so an AI can find its way.

My second brain fits in four files: a top file routes each task to one folder, and each folder holds one short file that says what to read and what to do. The smallest version looks like this:

Ask for an article and the agent starts at the top file, moves to the writing folder, reads one short file and begins. It never opens the code folder. Nobody pasted the whole project into the prompt.

The method comes from Jake Van Clief, who teaches it for free in his Clief Notes community on Skool and in his posts, which is where I follow it. He wrote it up with David McDermott in a March 2026 paper (arXiv:2603.16021). Their claim is that, for work that runs in steps, a folder structure can do the job of an agent framework (the extra code that coordinates several agents). You keep one agent, and the folders tell it what to read. In the paper’s abstract: “You need one orchestrating agent that reads the right files at the right moment.”

Part 2: six questions cover what folders leave out

Folders tell the agent where to go, and stop there. Nothing in them says what it may change, how to check the work, or what to leave for the next agent. Six short questions fill that gap. I made them up myself, and ICM does not include them. Each one becomes a single line you can paste into an AGENTS.md (the instruction file an agent reads first), a rule or a skill (a saved instruction the agent loads when it needs it).

1. Owner: who has the real copy?

Every fact should live in one place. When two files hold the same fact, the agent has to guess which one is right. Pick the file that owns each fact the task touches, and tell the agent to read it there.

Owner: every fact has one home. Name it before editing. If a copy exists, check it against the home.

2. Context: what must it read first?

More files in the prompt mostly add noise. Give the agent one file to read first, and let it search wider only if the answer is not there.

Context: read FACTS.md first, the one file that holds names, links and handles. Search wider only if the answer is not there.

3. Effects: what may it change?

An agent that can press Publish will press it. Write down what the task may change, and what needs your yes before it happens.

Effects: fill drafts only. Never press Publish or Send. Stop and show me a screenshot.

4. Evidence: how do you know it worked?

One passing check can be luck. Write down the check that proves the work, and a case that should make it fail, so you know the check can fail at all.

Evidence: three readers score it and I use the average (each reader is a fresh model that did not write the draft). Show the check failing a bad sample first.

5. Continuity: what does the next agent need?

A question that is answered but still marked open gets asked again by the next session. Close it in the same edit that answers it, with the date and the source.

Continuity: when a question is answered, mark it closed in the same edit, with the date and the source.

6. Learning: what changes after a miss?

Telling the agent to try harder fixes nothing, and neither does apologising to it. After a miss, change the tool or the rule, then check it again on the next few tasks.

Learning: when a miss repeats, fix the tool or the rule. Re-check on the next three tasks.

All six as one block

The lines above are mine, filled in. Here is the blank version. Paste it at the top of a task folder, or into the AGENTS.md that routes to it, and fill in one line per question.

Before any task, six lines:
Owner: <the file that owns each fact this task touches>
Context: <the one file to read first>
Effects: <what it may change, and what needs my yes>
Evidence: <the check that proves it worked, and a case that should fail>
Continuity: <what to close, link or date when done>
Learning: <what to change if it goes wrong>

Six lines are cheaper than one bad handoff

Six lines take me about two minutes per task, which is the whole cost of what looks like paperwork for a solo builder. When a question does not apply, I write N/A and the reason, and move on. A one-line pointer edit needs no review, and the payoff is a task the next agent, or the next you, can pick up without reading the whole history.

The free Second Brain Starter ships icm-architect, Jake Van Clief’s own skill for the method (MIT licence, bundled unmodified), and second-brain-icm, the skill that asks for these six lines whenever you change your own rules, skills or workflows. Builder AI OS is the paid layer for later, once one project is working.

Three earlier pieces set up this one

• Why are builders building Company Brains now?
• The four parts of a Company Brain
• How to scale a Second Brain into a Company Brain

Write the six lines for one task

Pick one AI task you run every week, then:

• Paste the blank block into its folder and fill it in.
• Hand the task to your agent with that note as the brief.
• Compare the result with last week’s run, and write down what changed.

This one came from Code Meet AI, the newsletter where I write up the setups I actually run on my own projects.

I write Code Meet AI, the newsletter where I document how I actually use AI to ship real products, receipts included. The full article is free there, and this page has the first half.

Your Second Brain works because one person trusts it. Add a second person and nobody checks the notes.

Alone, you know which note is old and which file is the real one. A teammate knows neither, and neither does their agent. Box, the file storage company, says in its Company Brain tutorial that a team needs “a shared source of truth that multiple people and multiple agents can use safely.”

My vault is the folder of notes my AI works from. I am its only reader and only owner. I have not run it with a team yet.

A folder that works for one person has no owner

With two people, each of you can believe the other one updates the pricing page.

In my vault each project keeps its facts in one file, FACTS.md, and nowhere else. A skill, my saved instructions for the AI, points to that file and never copies a fact out of it.

For a team, put a name next to each area of work. Box puts it as “assign every domain an accountable owner.”

A shared login lets the agent read what the asker may not

I have no reader rule yet.

Picture a new hire asking the company chat for the wifi password. The example is made up. The chat’s agent was set up with one shared login to all the documents, so it can read the salary sheet too.

Maxi Contieri, a developer who writes about AI coding, named this in July 2026. Naive integrations, he writes, “flatten access control when they index everything under one service account.” Access control means who may see what. Indexing reads every document in advance so the agent can search it. A service account is a program’s login.

His fix is that the step which finds documents for an answer “checks permissions against the requester’s own identity.” The agent answers only from what the person asking may see.

The other two answers are in the full article

New facts should wait before agents read them, and approved facts still age. Those two parts, plus the one step to take this week, are in the full article on my newsletter. It is free: read the full article on Code Meet AI.

This one came from Code Meet AI, the newsletter where I write up the setups I actually run on my own projects.

I write Code Meet AI, the newsletter where I document how I actually use AI to ship real products, receipts included. New guides land there first.

Last time, in How gstack, Superpowers, claude-mem and ECC handle memory, I compared four ways to give one AI agent a memory. All four, and my own Second Brain, are built for one person. The next question is what happens when a team and its agents have to share that knowledge.

When context is missing, people ask and agents guess

Say your team moved from Firebase to Supabase in March. The decision, and the reason for it, went into a Slack thread. The code still says Firebase. A README is a file at the top of a project that holds some of its decisions and rules, such as “we use Firebase for the database and sign-in”, and nobody updated it. A rule file in the codebase says the same old thing. So the team has two answers, and they disagree.

A new developer joins, reads the README and asks in the team chat. Someone answers in two minutes: “We moved to Supabase, the README is old.”

An AI agent gets the same task. It reads the README and the rule file, writes Firebase code and reports the job as done. It has no colleague to ask, and nothing it read tells it those files are out of date.

People work around missing context. An agent only knows what you hand it.

The gap itself is old. Information was always spread across tools, people left and took what they knew with them, and documents went stale without anyone noticing. A person could live with that. Once you hand real work to agents, it decides whether the work comes back right.

What a Company Brain is

Slite, a company that builds a knowledge base product, defines it in its guide: a company brain is “a persistent context layer” that “gathers knowledge from wherever a company creates it, and it makes that context usable by both people and AI agents.”

In plain words: one place where the team’s knowledge is kept current, so a new person and a new agent session start from the same facts.

That makes it something other than search. Search finds a document. A Company Brain keeps the current answer, and the date it replaced the old one.

Second Brain and Company Brain

1. Whose knowledge. A Second Brain holds what you know about your projects. A Company Brain holds what the team knows.
2. Who reads it. Yours is read by you and your AI tools. A Company Brain is read by everyone on the team and every agent they run.
3. Who can change it. In a Second Brain you are the only editor. In a Company Brain each fact needs an owner, one person whose job is to keep it true.
4. What breaks first. A Second Brain breaks when you stop updating it. A Company Brain breaks when nobody knows who should.

What goes into it

Four kinds of records do most of the work:

1. Decisions, with the reason. “We use Supabase since March, because the auth and the database live in one place.” The reason is what stops the next person, or the next agent, from undoing it.
2. How work is done. How you ship a release, how you handle a refund in Stripe, how a new client gets set up.
3. Who owns what. One name per area, so every question has somewhere to go.
4. What is true right now. Prices, versions, the current plan. Each one with a date, so a reader can see how old it is.

Most teams already have all four. They are spread across Slack threads, email chains, docs and people’s heads.

What changes when more than one person uses it

Slite surveyed 149 AI-forward teams in July 2026. The numbers are theirs: 70% knew the term “company brain”, and 19.6% said they had one that works. 56% said company knowledge lives in Slack and Teams threads. The top worry about adopting one was accuracy, named by 77%.

The same survey points at the fix, in my reading: 78% said a named human owner is what makes documentation trustworthy.

Four things change once a second person reads the record:

1. Owners. Every fact has a person responsible for keeping it true.
2. Permissions. Some records are for the whole team, some for one project, some for one person.
3. Keeping it current. Old facts get a date and a review, or they turn into the confident wrong answer an agent repeats.
4. Private and shared. Your notes stay yours. The team gets what the team needs.

Where to start

You don’t start with the whole company. You start with one person’s record, kept the way a team would need it.

I run my own Second Brain like that. Each project has one facts file. Every fact in it lives in one place and carries a date, and when a fact changes, the old line moves to a history file instead of being deleted. None of that changes when a second person reads it. The habits a Company Brain needs are habits you can build alone.

So the first step is the one from Why every builder needs a Second Brain: give each project one record that every tool reads before it starts. Then give each fact an owner and a date. That record is layer one of a Company Brain.

The free Second Brain Starter has the files to copy. Open it in Claude Code or Codex and type Set this up for me.

Next week: why builders are building Company Brains now.

This one came from Code Meet AI, the newsletter where I write up the setups I actually run on my own projects.

I write Code Meet AI, the newsletter where I document how I actually use AI to ship real products, receipts included. New guides land there first.

I run my work through a Second Brain: plain files that my AI tools read before they start. Counted on 22 October 2026, it holds 645 memory files, 119 skills, 41 commands and 640 session reports. Here is why I have one, and why you should too. Six things go wrong when AI works across several projects, and each has a small file that fixes it.

AI started as prompting. You typed a question, it typed back, and the whole skill was in how you asked.

Then it became context engineering. Same model, but now you decide what it reads before it answers: your files, your rules, your examples.

Then came tools. With MCP the model stopped only talking. It could open your inbox, read your calendar, run a command, and react to what came back.

Prompting, then context, then tools. The one thing missing is a place where the project lives.

That is a good place to be. AI is better than it has ever been, and every week a new tool does something that looked impossible last year.

So why does it still go wrong when you have more than one project?

One thing did not come with the upgrade: a place where the project lives. The model can read whatever you point it at, but it does not know what to point at. With three or four projects it forgets what you told it last week, it cannot find the file that holds the answer, and it fills the gap with something that sounds right.

The AI forgets too

When a team forgets why a project works the way it does, we call it a communication problem. With AI the same thing happens in three ways.

1. It forgets. Every new chat starts from zero, so last week’s work is gone.
2. It has no access. The answer sits in a note, a call or someone’s head, and the model never sees it.
3. It is confident anyway. This is the one that hurts.

A person who does not know says “I do not know”. The AI says the wrong thing in the same calm voice it uses when it is right. You read a clean answer, you think it is 100% true, and you have no way to check. Worse, the wrong part goes into the chat and becomes context, so the next answer builds on it. One dumb thing, said once, gets repeated as if it was settled.

You explain the same project again and again

Say it is Monday. You open a chat to get help with your app, and you spend twenty minutes saying what the product is, who it is for, what you built last week and what must be left alone. The answers are good.

On Wednesday you switch to another tool for another job, and it knows nothing. You type the whole thing again from memory, and the detail that mattered most, the one that would have stopped the bug, is the one you forget.

The easy fix is one project record. A single file at the root of the project that says what it is, who it is for, the current state and the next action. Every tool reads it before it does anything. You write the explanation once, and each chat starts where the last one stopped.

Before, three chats each hold half a copy of the project. After, one project record is read first by every chat.

Decisions get made and then vanish

Suppose you decide to use A instead of B. A is the payment provider with the fees you can live with, and B is the one your partner liked. You agree on a call, you hang up, and nobody writes it down.

Three weeks later the AI suggests B, politely, with good reasons. Your partner says “see?”, and you spend an hour on a decision you already made.

So keep a decision file. One line per decision: what you chose, what you turned down, why, who decided and the date. Write it right after the call, in the file the next session reads.

The reason is the part people drop first, and it is the part that stops the argument from coming back.

A decision line: what you chose, what you turned down, why, who decided and when.

The AI reopens what you already settled

Take the other side. You did write the decision down, in a notes app, in a doc, in a chat from last month. The AI never saw it, so it treats the question as open and argues for B again.

Writing it down is half the job. The other half is telling the model it is settled. Keep a short list of closed decisions inside the project record, each with its reason, in the part that is read first. A decision with a reason attached is much harder to reopen by accident.

Context leaves with the person

This version costs money. Take one client account. The account lead knows the client was promised a faster turnaround last spring. They know the client said no to one format, and that approvals go through one person on Fridays. None of it is in the CRM, which keeps deal values, dates and activity but has no field for the promise or the reason behind it.

Then the account lead goes on holiday, or leaves. The next person meets the client without the history, and the AI helps them no more than it helps anyone else, because it cannot read what was never written.

The fix is one client record per account. It holds the brief, the dated decisions with reasons, what the client said no to, the promises made and the next action. Whoever covers the account, person or AI, reads it first. The record outlives the person.

Before, each person and tool keeps its own copy. After, all of them read one client record.

Each tool keeps its own copy, and the copies drift

Claude, Cursor, Codex and Gemini each want their own rules file. You change a rule in one of them on Tuesday. A month later two of the four disagree, and the AI follows the old one without telling you.

Keep one rules file as the source. Give each tool a one-line file that points to it, and link one shared skills folder into each tool’s own path. The copies stop existing, so they cannot drift.

Four tool files point to one source file, so the copies cannot drift apart.

Files go stale, and the AI trusts them

Last month you moved the project from Firebase to Supabase. The record still says Firebase. The AI reads it, writes for the old database with full confidence, and the result breaks in a way that looks like a bug in your own work.

A wrong file is worse than no file, because nobody doubts it. Put a last-checked date on each section, and check the record whenever the project changes: you swap a tool, a client leaves, a decision is reversed. A rule that a script can test becomes a hook, which runs at a fixed point whether the model agrees or not. A rule that needs judgement stays in the record, as a request.

What a Second Brain is, in one sentence

A Second Brain is a set of plain files, one record per project and one per client, that every AI tool and every person reads before work starts, and that gets written back after each decision. It is a folder with a discipline attached.

The layout follows ICM, the Interpretable Context Methodology: a small routing file points the AI to the one file it needs, so it does not have to load everything.

This is mine, drawn as a graph. Every dot is a note, and the lines are the links between them. When the AI starts a session, this is what it can walk through instead of starting from zero.

My Second Brain as a graph. Each dot is a note, and each line is a link between two notes.

What to do this week

1. Count the repeats. For five working days, note each time you explain the same thing to an AI tool, and which tool it was. The count tells you which record to build first.
2. Write the decision line. After each call or chat where something gets decided, add one dated line to the project file: the decision, the reason, the owner.
3. Run the leave test on one account. Pick one client. Ask whether the next person could open one file and find the promises, the no’s and the next action. If not, that file is your first client record.

A plain Markdown starting point for all of it is in the free Second Brain Starter. For how to sort the folders once you have a few records, see how to organise your files for AI, Episode 11 of Using AI, properly.

This one came from Code Meet AI, the newsletter where I write up the setups I actually run on my own projects.

Wire AI is live and early access is open. It’s an AI-native growth engineer for mobile apps: your React Native app embeds an SDK, a LangGraph backend decides what to ask each user next, and deterministic code owns the routing while the model only generates content. On one live app, activation went from 69% to 93%. 15 early-access seats, 3 taken, free and installed by hand.

Wire AI is live today, and early access is open.

It’s the AI-native growth engineer for mobile apps: AI that replaces your growth team. It runs four versions of every step of your users’ journey, live at once, and keeps what makes them stay.

On the first app it ran on, activation went from 69% to 93%.

15 seats. 3 are already gone. Free, installed by me personally, and there’s no price attached because I haven’t set one yet.

Below: what it does, what already shipped, what’s still rough, and how to claim one of the 12 that are left.

How it works

Your users’ journey has stages. They onboard, they get a plan, they hit their first real win, they get asked for a review. Wire AI runs four versions of each of those stages, live, at the same time. Users are assigned to a version and stay in it, the funnel says which version keeps more of them, and the winner gets promoted.

Then the part a testing tool doesn’t do. Every finished journey feeds back in: Wire reads what happened and writes a sharper variant for the next round.

It isn’t a dashboard that tells you to go run a test. It’s the loop, already running.

What that looks like in your codebase

Your React Native app embeds a small SDK. When a user opens the app, the SDK talks to a backend I run, and that backend decides, one screen at a time, what to ask that specific person next. It renders as native cards. Not a webview, not a chat window bolted onto your product.

At the end it hands your app a structured plan you can save and act on, and every step streams into a funnel you can read.

So instead of writing an onboarding once and guessing for the next two years, you write a config and the AI runs it.

The part that makes it work is boring on purpose. Deterministic code controls the flow and the model only generates content. Routing is a pure function of where the session is, how many questions are left, whether the user is bailing, so the whole flow is testable without a model in the loop.

The AI writes the next question, grounded in every answer the person already gave, and writes the final plan. Everything it emits gets validated against a fixed vocabulary of components before it’s allowed anywhere near a screen.

That’s the difference between a generative UI demo and something you can put in front of paying users. Most AI UI demos let the model draw whatever it wants and hope. This one gives the model a small, checked job and keeps the state machine in code where it belongs.

What that gets you

1. A journey that adapts per user. The static onboarding asks everybody the same seven questions in the same order. Wire AI asks what follows from what the person just said, stops when it has enough, and skips what it can already infer.
2. Experiments that run without you. A/B/C/D variants across the journey, five stages, four arms, twenty combinations, without anybody sitting in a meeting deciding which to try next. This is the direction the product is built toward and I’ll be straight about where it sits today, further down.
3. A funnel you can actually read. Completion, drop by step, time per screen, and the transcript of any individual session so you can read exactly what the AI asked and what the person answered. Most apps at this stage are guessing about where users give up.
4. You find out who your users actually are. Wire AI reads every session and hands you the patterns: what people came for, which question makes them hesitate, which wording converts. Most founders are still running on a persona doc written before launch.

Our pilot client, and what actually happened

I can’t name the app, that’s a client boundary I hold. What I can tell you is what it does: it helps people find spots to hang out. Live React Native app, real users, and an onboarding people were quietly dropping out of.

Here’s the run, in the order it happened.

1. We started with an experiment, not a redesign. Three versions of the onboarding running live at the same time, users assigned stickily so nobody got a different flow on their second open, every version chasing the same goal event. Nobody sat in a room deciding which one was better.
2. The first read was wrong, and the loop is what caught it. One arm came back looking like a 17 point winner. At around fifty sessions that feels like a result, and it’s exactly the moment a human growth team ships it and builds the next quarter on top. At scale it was worth about three and a half points. Mostly noise wearing a nice hat.
3. The version that actually won was the short one. The deep, thorough discovery flow lost to a fast one of about eight screens. On a flow with no real leak in it, where every individual question converts in the high nineties, length turned out to be the only lever that moved anything.
4. Then the part I didn’t expect: we found out who the users actually were. The product context we had written assumed one kind of person, someone new to the city looking for places. The answers said something else. Younger, local, born there, social, budget conscious. My actual reaction, reading the answers: wait, these people already live here. We had spent months onboarding a user who didn’t exist.
5. So we rewrote the messaging to the real one. New product context, questions rewritten for the person who actually shows up, one question cut completely because it was seasonal noise nobody cared about, and a guard added so the AI stops asking the same thing twice in different words.
6. Three learning loops in, activation had gone from 69% to 93%, and the first movement showed up inside the first week of running live.

Two honest caveats on that number, because it’s the one people will quote. It’s activation on one app, in one category, over one window, so it isn’t a portfolio of case studies and I won’t dress it up as one.

And the winning arm’s completion rate moved by about thirteen points between generations of the experiment, which is a reminder that you read these numbers per run, never all-time. That lesson cost me a re-read of my own dashboard.

What already shipped

Not a landing page and a waitlist. These pieces exist and run.

1. The SDK is open source. wireai-rn on npm, MIT licensed, eleven built in components with validated schemas, six adapters for different model providers. Swapping providers is one environment variable, so you're not married to whoever is winning this quarter.
2. The transport is an open standard. The device and the backend speak Google’s A2A over JSON-RPC 2.0, the same contract implemented on both ends. That’s how a Python agent graph ends up driving a native React Native screen. One call, one turn, one card.
3. The backend is a real service. Python, FastAPI, LangGraph. Multi tenant, per app keys with scoped access, session state living outside the process so it scales sideways, data in eu-central-1 because GDPR isn't a Q3 problem.
4. There’s a console. Register an app, edit the config without cutting a release, read the funnel, open any session and read the transcript.
5. It’s tested like something people depend on. The drop in kit runs 630 tests on every merge, and the agent routing has its own eval suite with an accuracy gate, so “the agent got worse” shows up as a failing build instead of a feeling.

First card lands in about 130 milliseconds, against roughly three and a half seconds when I started. Onboarding is the one screen where a spinner costs you the user permanently.

What a seat gets you

If Wire AI doesn’t lift your activation, you’ve paid nothing and you still keep the teardown.

That’s the deal in one sentence. Here’s everything inside it.

1. The Activation Teardown, before you commit to anything. I put your existing onboarding through the analysis and send you a report: where people drop, which step leaks, what I would change first and why. It’s yours whether you take a seat or walk away, and you don’t need to install a single line of code to get it.
2. The install, done by me, by hand. Up to four hours on a call, in your codebase, together. Not a docs link and good luck. This is the part that doesn’t scale, and it’s exactly why there are 15 seats and not 500.
3. Your bugs jump the queue. When you hit something broken, and you will, it gets fixed that day instead of queueing behind everything else. That stops being possible the moment this cohort is full.
4. A direct line to the roadmap. What gets built next is what early-access apps need next. At this stage that isn’t landing-page language, it’s just how the queue works, because there is nobody in front of you.
5. Analytics free to 1 million events a month. Any app, not only early access, and it doesn’t expire when the beta does.

No price, and that’s deliberate. I’m not deciding what Wire AI costs until early access tells me what it’s worth, so nobody in these 15 seats gets priced by a guess.

What I want back

One thing: the truth, while you use it.

When a question the AI asks is stupid, say so. When the console confuses you, say so. When a number looks wrong, say so, and that one is worth more to me than any testimonial you could write.

That’s the whole trade. You get the teardown, the install, the queue and the roadmap line. I get the thing I can’t buy, which is honest reactions from a real app with real users in it.

If it isn’t you, it might be someone you know

All three seats that are gone came warm. Somebody knew somebody. Not one came from a cold email, and I have sent a lot of cold emails, so I’ve stopped pretending that’s the channel.

So if your own app doesn’t fit but a name came to mind while you were reading, that’s the ask. Forward this to them, or drop the name in a comment and I’ll reach out and tell them you sent me.

Anyone arriving through a referral skips the queue and goes straight to a call. And I’ll run the Activation Teardown on your app too, even if you never install anything.

Before you say yes, two things you should know

1. Only the onboarding stage is live and proven. The journey wide experimentation I described up there is the roadmap, not a shipped feature. I’d rather you hear that now than find it out in week two.
2. I have an open number I can’t explain yet. This week my own dashboard read 23% completion on an app that had been finishing north of ninety. I spent a morning on it and I still don’t have a clean answer. Best guess is the dashboard, there are two honest ways to compute a completion rate and my headline tile looks like it’s reading the wrong one, but I haven’t proven it and I’m not going to pretend I have.

Both of those are in a launch post on purpose. The product is deliberately incomplete at this stage, and the fastest way to harden it is with a few real apps inside it rather than a year of me polishing it alone. If that reads as a red flag, this isn’t the right moment for you and that’s a fair call.

Who this is for

You’re a fit if you have a React Native or Expo app that’s live, with real users going through an onboarding right now, and you’re a solo founder or a tiny team where the person who feels the activation problem is also the person who decides.

It helps if your app already has AI or personalization in it, because then I don’t have to sell you the idea and we can go straight to the mechanics.

You’re not a fit if you already have a growth team running experiments every week. Genuinely. A larger company passed on this recently for exactly that reason and they were right to. The value here is removing a person from a loop you don’t have. If you have the person, you don’t need me.

Pre launch is also a bad fit, and I say that with some regret because those are usually the most fun conversations. Without traffic there’s nothing for the loop to learn from.

How to claim a seat

Reply to this email. That’s the whole process, there’s no form and no demo request.

Tell me what your app does and roughly how many people go through onboarding in a week. Two sentences is plenty. If it’s a fit I’ll send you a time this week. If it isn’t, I’ll tell you straight instead of quietly moving you into a nurture sequence.

Not sure you qualify? Ask for the teardown anyway. Worst case, you get a report on your own funnel and we both move on.

12 seats left of 15. The cap is real, because the install is manual and I’m the one doing it.

How I make this

I draft with AI. I’ve written about my workflow more than once and it’d be strange to hide it here. The receipts, the numbers, the decisions and the opinions are mine, the sentences get a drafting partner and then a lot of editing from me. If that disqualifies me for you, fair enough. If it interests you, that’s most of what this newsletter is about.

I’m Malik, 9 years building mobile apps, React Native and Expo. I write Code Meet AI, where I show what I’m building with AI and what it costs me. Wire AI lives at getwireai.com, and the SDK is open source.

Wire AI is live: how I run AI-driven Growth Engineer in a React Native app was originally published in Stackademic on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is the builder’s half of episode 05. The plain-language version, where i wire Gmail and Google Calendar and the whole point is that they teach opposite lessons, is over at Code Meet AI.

the part nobody warns you about

Everyone’s first MCP experience is the good one. You paste four lines into a config file, restart your client, and suddenly your AI can read your inbox. It feels like magic and it takes about ninety seconds.

Then you decide your own product should have one, and you find out the protocol was never the hard part. MCP is a thin, pleasant spec. What it does is force you to answer a question you have been avoiding: what is my product, expressed as verbs a stranger’s AI is allowed to call?

That question has teeth. Every tool you expose is a promise about blast radius.

The starting problem, same for every product: the data exists and nothing that could reason about it can reach it.

why a funnel is worth the trouble

Quick justification before the code, because “make your product agent-reachable” is the kind of sentence that means nothing on its own.

• 8 in 10 people have deleted an app because they couldn’t figure out how to use it (Wyzowl’s onboarding survey, 2020).
• The average app loses most of its users in the first few days (Andrew Chen’s widely-cited Quettra data, 2015 numbers, but the shape hasn’t moved).
• A 5% lift in retention raises profit somewhere between 25% and 95% (the Bain finding Harvard Business Review keeps citing, 2014).
• 80% of features are rarely or never used (Pendo, 2019).

The data almost always exists. The reaching is what’s missing.

Onboarding is where that gets decided, which is what Wire AI does: it generates the onboarding flow per user instead of shipping one static carousel to everybody. On the app I tuned hardest, activation went from 69% to 93%. That number is the reason the MCP exists at all, because you cannot tune what your AI cannot look at.

what I actually exposed

Twenty tools. I counted the registrations rather than trusting my own README, and I recommend you do the same to yours at some point.

They group into five jobs:

1. Learn the product (2 tools, no auth). wireai_get_integration_guide returns the integration recipe an agent reads before it writes a line of code. wireai_list_components returns the 13 device components the flow is allowed to render.
2. Read the funnel (tenant). wireai_get_insights, the one tool most users ever touch.
3. Manage apps (admin). Register, list, get, and patch an app’s config.
4. Run experiments (admin). Split onboarding, the review gate, or a questionnaire into A/B/C/D arms and read the results.
5. Close the loop (mixed). Submit a learning report, list them, mark one applied.

The shape that matters: this is a control plane, not a Q&A bot. The AI does not “ask Wire AI a question.” It reads state, changes config, splits traffic, and reads results. That’s the whole product, expressed as verbs.

Connecting is the boring part, and it should be:

claude mcp add --transport http wireai https://wireai-mcp.fly.dev/mcp \
  --header "Authorization: Bearer <your-token>"

Or the config-file form, if your client prefers it:

{
  "mcpServers": {
    "wireai": {
      "type": "http",
      "url": "https://wireai-mcp.fly.dev/mcp",
      "headers": { "Authorization": "Bearer <your-token>" }
    }
  }
}

Honest note while I’m here: there is no one-click “add MCP” button in my console yet. You copy your key from the Set Up tab and run the connect command once. I’d rather write that sentence than pretend the button exists.

the auth model, which is most of the work

I’ll say the uncomfortable thing first. A remote MCP server is an authenticated API where the client is a language model that decides on its own when to call you. Every auth shortcut you have ever taken gets more expensive under that sentence.

Two scopes, and the split is not cosmetic:

ScopeMinted fromReachestenantyour wai_ keyread your own app's insights, submit and flag learning reportsadminthe operator keyapp management, config, analytics, experiments, cross-tenant reports

Four properties, and each one exists because the alternative bit somebody:

The raw key is used once, then never again. You POST /v1/auth/mcp-token with your key and get back a short-lived scoped token. That token is what rides in the Authorization header. Your actual key does not travel with every tool call, so it is not sitting in a request log somewhere waiting to be grepped.

Tokens expire in about 24 hours. When one dies the tools return a plain “run login again” message instead of a stack trace. Expiry that produces a confusing error is expiry people route around.

Rotation is the revocation story. Each token is bound to its parent key’s fingerprint. Rotate the key and every token derived from it dies instantly, with no server-side token store to purge. I like this one a lot, because “how do I revoke it” is the question that usually gets answered with a shrug and a database table.

The server refuses, not the docs. A tenant token hitting an admin route gets rejected by the backend. Not filtered in the client, not discouraged in the tool description. The description is a suggestion to a model that is free to ignore it.

For local development the fallback is stdio: node dist/index.js login writes a derived token to ~/.wireai/credentials.json, chmod 600 inside a 0700 directory. Never the raw key. And there's an env-var path for CI that I documented while saying plainly that it puts a long-lived secret in plaintext, so prefer the token.

One more, since people ask: @wireai/mcp is repo-local and deliberately not on npm. The kit's files allowlist excludes it. There is no npx wireai-mcp to typo-squat, and the hosted URL is the path I actually support.

five design decisions, four of which I got wrong first

Markdown, not JSON

wireai_get_insights doesn't return a funnel object. It hits GET /v1/insights.md and passes through a Markdown brief: the steps, the advance rate at each one, where people stall.

This felt lazy when I did it. It isn’t. A model reads a written brief the way it reads any document, and it reasons over prose considerably better than it reasons over four levels of nested keys. Raw JSON also burns your context window on punctuation. If you write exactly one MCP tool this year, make it return a page.

an empty funnel is a valid answer

A brand-new app has no data. The obvious implementation throws, or 404s, and then your AI reports that the integration is broken when it is simply new.

So an empty funnel returns HTTP 200 with a “no data yet” brief. Same shape, no numbers. A missing credential degrades the same way. The rule I ended up with: a half-configured MCP server should be inert, not loud. An angry server teaches the model to stop calling the tool.

the default that misled a real analysis

This is the one I’d want to read.

wireai_get_onboarding_analytics returns the funnel. Originally it defaulted to everything, all-time. Which is a reasonable default and also completely wrong, because an onboarding flow that has been through three experiment generations does not have "a" funnel. It has an era per generation, and pooling them averages a winning arm together with the losing arm it replaced.

The numbers were never incorrect. They were unscoped, and unscoped numbers are worse than missing ones, because they look like answers. It threw off a real analysis before I caught it.

The fix was a second tool. wireai_list_analytics_runs returns the app's eras, each experiment window plus the static and winner eras, with a default_run_id. You read the timeline first, then feed a run id back as the run param to scope every metric to one era. The tool description tells the agent to read the timeline first.

The general lesson: when your data has generations, an unscoped read is a bug, even when every number in it is accurate.

config writes, without a release

wireai_update_onboarding_app patches an app's configuration and only the fields you send. Question script, goal, product context, screen budget, the length_band (5-8, 8-13, 13-18, 18-25), allowed components, locale, the in-app review prompt, and the per-module feature switches.

That last one includes the kill switch, features.onboarding.mode: ai runs the generated flow, static serves a stored flow with zero LLM calls, off suppresses it. An agent can turn my own product off for a tenant without shipping a build. That is intentional and it is exactly why the write tools live behind the admin scope.

The thing that makes this usable at all is that none of it needs an app release. Config-only, live.

the gotcha I’d have flagged in review

Per-arm min_sessions does not inherit from the parent experiment. An arm that omits it has no min-sessions gate, so it fires immediately while its siblings wait.

It is documented, in the README and in the tool description, because a footgun a model can step on has to be written where the model reads. That’s a genuinely different documentation target than a human developer. Your tool descriptions are the API docs now.

the loop, end to end

Where it stops being a tool list and starts being useful:

1. Agent reads wireai_get_integration_guide, then writes the integration.
2. wireai_register_onboarding_app, then wireai_update_onboarding_app to seed the question script and context.
3. wireai_set_onboarding_experiment splits the flow into arms.
4. Traffic runs for a week.
5. wireai_list_analytics_runs, then wireai_get_experiments scoped to that run.
6. The learning-report skill turns the raw funnel into an aggregate analysis plus a proposed context change, and wireai_submit_learning_report stores it. summary_md is aggregates only, no user rows, no PII. share_ok defaults to false.
7. Apply the change, wireai_mark_learning_applied, repeat.

Steps 1 through 7 are one conversation. That is the actual product: not “AI generates onboarding” but a loop where the improving is reachable.

Worth separating the two halves. The skills carry the judgment: how to design a question script, how to read a funnel, what a good learning report says. The MCP carries the reach. Knowledge on disk, hand into production. Neither one is useful alone, and people building agent products keep trying to make one of them do both jobs.

the security posture, briefly

Nothing exotic, it’s the posture you already take with a service token:

• Least privilege by default. The read loop is entirely tenant-scoped. Most users never mint an admin token.
• Aggregates, never raw user rows. This is enforced in the learning-report payload shape, not left to the caller’s conscience.
• No key in any tool output. Whatever a tool returns lands in a context window you do not control, and may end up in a transcript, a log, or a screenshot in an article like this one.
• Nothing logged. Raw keys and tokens never reach the logs.
• Hosted mode stores nothing. The Fly app is stateless, single region.

Deploy is a manual fly deploy from the mcp/ folder after a merge. No auto-deploy on this package, on purpose: an accidental push should not reconfigure a live control plane.

what it does not do

Same honest limit as the rest of this series. The MCP lifts nothing. It does not improve activation, it does not fix a bad question script, and it will happily give your AI a perfect view of an onboarding flow that deserves to be deleted.

What it removes is the gap between noticing and acting. “Why do people quit at step two, and what should I try” stops being a question you answer alone in front of a dashboard, and becomes one you ask a system that can look, split the traffic, and read the result back to you.

Reachable is not good. Reachable is where good becomes possible.

grade your own app first

Before you write a server, find out whether your product has anything worth exposing. I put the checker in a pack and open-sourced it.

The mcp-readiness-audit skill runs seven checks: analytics, onboarding measurement, monetization, crash reporting, MCP-reachability, whether your AI has the context to act, and whether a reachable server is actually safe or quietly leaking. Four grades, from Flying Blind to Agent-Ready, plus the top three things to fix. A section 7 failure, a committed key, a write tool with no scope, raw PII in a response, caps you below Agent-Ready no matter how good your analytics are.

It graded my own open-source boilerplate “Instrumented but Blind.” Great data, blind AI. So it won’t flatter you either.

Seven checks, four grades, and it failed my own repo on reachability.

The second skill, mcp-server-blueprint, builds the server: read-only by default, field allowlists, no secrets in tool output, aggregates not rows, Markdown not JSON, 2 to 4 well-named tools instead of 20 vague ones, and a pre-ship checklist.

Both are here, take them: github.com/chohra-med/mcp-for-your-app

And if you want the server this article is about, it’s part of Wire AI.

Written by Malik at Code Meet AI. This is the builder’s cut of episode 05 of Using AI, properly. The plain-language cut, Gmail and Google Calendar and why they teach opposite lessons, is here. Episode 04 was context engineering.

i’m Malik, i’ve been a mobile engineer for 9 years, and everything above is running in production. The 20-tool count is counted from the registrations in src/index.ts. My own notes had it at 19, which is the kind of drift you get the moment a tool surface stops being small.

i’m Malik, i’ve been a mobile engineer for 9 years, and everything above is running in production. The 20-tool count is counted from the registrations in src/index.ts. My own notes had it at 19, which is the kind of drift you get the moment a tool surface stops being small.

How to create an MCP Server for your product was originally published in JavaScript in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

This piece is from Code Meet AI, my newsletter where i document how i actually use AI to ship real mobile work, receipts included. New guides land there first.

A few weeks ago an AI i built into an app asked a real user to name a beach-party plan. First thirty seconds in the product. The app can technically make a plan called that, so it wasn’t a hallucination exactly, it was worse: a real feature dragged to the front because the model had nothing better to go on. i had handed it a one-line description of the app and told it to get the user to a concrete first action. A one-line description is an invitation to guess. So it guessed, confidently, in front of someone i was trying to keep.

That was the moment context engineering stopped being a phrase i skimmed past and became a bug with a name. And if you ship React Native, you already own the instinct that fixes it. You just point it at code today, not at prompts. You scope a token to the one thing it needs. You write a PR description that says what changed and why. You tell the AI “wire it through the auth service, don’t touch the generated files.” That last move, telling it what to read and what to leave alone, is context engineering. This is the same muscle, aimed at a different target.

A prompt is the ask, context is the ground

The prompt is what you want. “Add the token-refresh retry.” “Draft the paywall copy.” “Clean up this feature folder.” Short, and you already know how to write one. The context is everything the model needs to answer that well and doesn’t have unless you hand it over: which auth service, which files are generated and sacred, what the app actually does and who is standing on the other side of that onboarding. The prompt points at a target. Context is whether the model can see the target or is throwing in the dark.

Most bad AI output is not a bad prompt. It is a fine prompt fired into an empty room. The model fills the empty room with the most statistically average thing, and average is exactly what makes you close the tab and call it overhyped.

The four things you are actually feeding it

When people say “context,” they mean four different things stacked together. It helps to see them apart.

A prompt is the arrow. These four are the ground it lands on.

The goal. Not the task, the outcome. “Turn this screen into a reusable component” is a task. “so the paywall and the settings row can share it without a prop-drilling mess” is the goal. Give the model the why and it makes better calls on the hundred small things you didn’t specify.

The ground truth. The real material, not a description of it. This is the one people skip. Don’t tell the AI “match our house style,” paste two components that already look the way you mean. Examples beat adjectives every time. A model shown three real things you like will out-perform any paragraph describing them.

The constraints. What good looks like and what to never do. The library you’re standing on. The generated files it must not edit. The RN version you can’t break. Constraints are not the AI’s handcuffs, they are how it knows it succeeded instead of guessing at your taste.

The boundary. What to leave out and what not to touch. This is the half nobody talks about, and it is the one that separates people who are good at this from people who just paste more.

More context is not better context

Here is the counter-move, and it is the part that surprised me.

Once you learn that thin context causes bad output, the obvious next step is to feed it everything. The whole feature folder. The entire git history. Every doc, in case it helps. It feels thorough. It is the exact opposite of thorough.

A model has a working memory, and past a point, adding more doesn’t inform it, it distracts it. The signal you actually needed gets buried under fifty files of nearly-relevant noise, and the answer gets vaguer, not sharper. i have watched a model give a worse answer to the same question after i “helpfully” pasted three more files. The good lines were in there. It just couldn’t find them anymore. It is the prompt equivalent of importing the whole SDK to use one function.

So context engineering is not “add context until it works.” It is “give it exactly what this task needs, and nothing that competes with that.” Curation, not accumulation. The test i use now is embarrassingly simple. Before i paste something in, i ask: does the model need this to answer, or am i adding it to feel safe? The second kind is the noise.

How to actually do it

You don’t need a framework. You need four sentences before the task, roughly in this order.

1. State the goal, not just the task. One line on the outcome you’re actually after. “so that…” is the most useful phrase in the whole practice, and you already write PR descriptions this way.
2. Show, don’t describe. Paste two or three real examples of what good looks like. A component you’d be happy to merge, a before, an after. This single move fixes most “it sounds generic” complaints.
3. Name the constraints and the anti-goals. The library, the version, the hard limits, and the one or two files it must never touch. Short bullets are fine.
4. Draw the boundary. Say what to use and what to ignore. “Only this feature folder.” “Don’t touch the generated types.” “The old screen is background, not a template.”

That’s it. Four sentences turns “draft the paywall copy” from a coin flip into something you’d actually ship.

Write it down once: the six files

The last move is what makes this compound instead of repeat. The first time you assemble the context for a recurring job, don’t throw it away. Put it in the repo, next to the code it describes. Next time, you point the AI at the folder and add one line for today’s task. You’ve turned a five-minute setup into a five-second one, and the output stays consistent because the ground under it stopped moving.

On a real project this is not one file, it is a few, and the names are becoming a standard any agent already reads:

• PROJECT.md: what the app is and why it exists.
• CONTEXT.md: what you are working on right now, this sprint.
• CLAUDE.md and AGENTS.md: the rules you want the AI to follow, the conventions, the files to never touch.
• README.md: for the human who lands cold.
• progress.md: the memory file from episode 02, for what happened last.

the context lives in the repo, not in your head. any AI you point at the folder reads it and knows where it is.

If episode 02 sounds like it is happening again, that is because it is. A memory folder is context that persists across sessions. A context file is the same instinct pointed at a single repo. The AI that invented a beach-party plan does not do that anymore, and the fix was never a cleverer prompt. It was a page of real product context, written once, that told it what the app is actually for and who is on the other side.

Where this breaks

Two ways, both worth knowing.

Stale context is worse than no context. A CONTEXT.md that still describes last quarter's screen flow will make the AI confidently wrong, and confidently wrong is the expensive kind. When the thing changes, change the file. It is a living note, not a monument. Treat it like a dependency you keep on the latest version.

And context is not a substitute for the check. Grounding the model dramatically raises the floor, it does not remove your job of reading the diff before you trust it. That check is its own episode later in this series, and it is the one that never gets automated away.

The punchline is small and annoying and true: most of the time the AI wasn’t wrong because it is dumb. It was wrong because it was guessing, and it was guessing because you didn’t tell it the thing you assumed was obvious. Context engineering is just the discipline of saying the obvious thing out loud, once, and then reusing it.

I put together a context starter pack: the four-line context you write before a task, the six files that give any AI your whole repo’s context (PROJECT, CONTEXT, CLAUDE, AGENTS, README, and the progress.md memory file from episode 02, each explained), and the one prompt that sets them all up for you. Comment CONTEXT and i’ll send it over. If you ship mobile and want the way i bake this into the starter i build apps from, that lives in AI Mobile Launcher.

Written by Malik at Code Meet AI. This is episode 04 of Using AI, properly. Episode 02 was give the AI a memory, episode 03 was put the AI on the work around work. New guides land there first, subscribe if this was useful.

i’m Malik, i’ve been a mobile engineer for 9 years, and i run my work and this newsletter on the system these episodes describe. Next up: how to make the AI check its own work, before you do.

Context engineering for Mobile founder, simplified was originally published in Stackademic on Medium, where people are continuing the conversation by highlighting and responding to this story.

This piece is from Code Meet AI, my newsletter where i document how i actually use AI to ship real mobile work, receipts included. New guides land there first.

If you build React Native, you already know the delegation move. You open Claude Code in the terminal, you say “add the token-refresh retry, wire it through the auth service, don’t touch the generated files,” and you go make coffee. You are not typing every step. You are handing over an outcome and reviewing what comes back. That has been your daily reality for about a year.

This Monday, Anthropic pointed that exact engine at everyone who does not open a terminal. They expanded Claude Cowork to web and mobile, and they put a number on what people run on it: more than 90% of usage is not software development. Not code. The biggest categories were business operations and content work. Reconciling the quarter’s spend and drafting the memo about it. Turning a folder of contracts into a renewals tracker with the risks flagged. Building tomorrow’s client deck from call transcripts.

They call it “the work around work.” Good name. It is the layer of the job that is real work, takes real hours, and somehow is nobody’s actual job. As an engineer you have automated your half of it. This is the same automation, aimed at the half you have been doing by hand: the filing, the status updates, the weekly report you rebuild every Monday.

what Cowork is, in one honest paragraph

You already know chat: you ask, it answers, you ask again. You are the project manager of every tiny step, same as a REPL.

Cowork is the same Claude with a different job description, and it is the terminal agent you already trust, minus the terminal. You hand it an outcome: “turn this folder of contracts into a renewals tracker, flag anything risky.” It makes a plan, breaks it into steps, works across the files and apps you have connected, and comes back with the finished thing. While it runs, you do something else. Since this week it follows you: start a task at your desk, check the status on your phone, pick up the result later with the laptop closed. Scheduled tasks run even with no device online.

Chat: you drive. Cowork: you describe, then review.

my actual Claude home. one toggle flips chat into Cowork, and “send me a daily briefing” is already sitting there as a suggestion.

One tool, two jobs, and for most people the second job is their whole day. You got the code half first because you happened to work in a terminal. Now the rest of your team gets it too.

what people actually run on it

Not moonshots. Chores. The patterns showing up again and again in the early write-ups:

Folder archaeology. Sort, rename, and deduplicate a cluttered folder. Rename 400 photos to match the product list. The task you have postponed for a year because it is three hours of mind-numbing clicking. This is the non-code version of the codemod you would happily write a script for, except now the person next to you can ask for it in a sentence.

Pile of documents, should be a list. A folder of contracts becomes a renewals tracker with dates and risk flags. A stack of receipts becomes an expense sheet. Dense PDFs in, structured table out.

The recurring report. The weekly status, the morning brief, the numbers pulled into the same format every Monday. You describe it once as a routine, in plain language: what to gather, what format, where to deliver it. It runs every morning without you. Think cron, described in English.

First drafts from your own material. Tomorrow’s client deck from the call transcripts. The variance memo from the spreadsheet. Not “write me something generic,” but “turn my raw material into my draft.”

The common shape: high effort, repeatable, and the source material already sits in your files. That is the delegation sweet spot, and it is the same sweet spot you learned to spot in your codebase.

how to start: one resented task

Don’t tour the features. Pick the one task you flinched at while reading the last section. Then:

1. Give it context first. This is the same rule i wrote a whole episode on last week: before the task, point Cowork at a short context file about what this project is, what good output looks like, what to leave alone. If you gave your AI a memory folder, you already have this muscle. Two minutes, and the difference in output quality is not subtle.
2. Describe the outcome, not the steps. “Make this folder make sense: group by client, newest first, flag anything duplicated” beats a 12-message back-and-forth. You already write PR descriptions this way.
3. Review like a manager, not a believer. It hands you a deliverable, not a truth. Open the tracker, spot-check five rows against the source. This is a code review with different file types.
4. If it worked twice, make it a routine. The scheduled kind is where the real hours come back: describe it once, in plain language, and stop doing it forever.

where this breaks

It has access to what you give it. That is the feature and the risk: connect the folders and tools the job needs, not everything you own. Same rule as the memory file, and the same rule as any token you scope in an app: least privilege, nothing it does not need.

And it is confident, including when it is wrong. A tracker with one silently wrong date is worse than no tracker. You know this from AI-generated code that compiles and still lies. The review step is not optional politeness, it is the job you keep.

the punchline

The AI didn’t take the work. It took the work around the work. You felt this first, in the terminal, when the boilerplate stopped being your problem. What’s left over is the part that needed you all along: deciding.

I am putting together a routines starter pack: three plain-language routine templates (the folder cleanup, the pile-to-tracker, the morning brief) you can adapt in five minutes. It goes out through the newsletter first. If you ship mobile and want the way i package this delegation habit into the starter i build apps from, that lives in AI Mobile Launcher.

Written by Malik at Code Meet AI. This is episode 03 of Using AI, properly. Episode 02 was give the AI a memory, episode 01 was the art of prompting. New guides land there first, subscribe if this was useful.

i’m Malik, i have been a mobile engineer for 9 years, and i run my work and this newsletter on the system these episodes describe. The delegation habit started in the terminal, moved to my second brain, and now it does the work around the work. Next up: where a single sentence stops helping, and context begins.

Before you go

• Please take a moment to like the post and follow the writer!
• Did you know that over 400,000 developers share what they’re building, learning, and discovering across our platforms every month? Learn how you can contribute here

React Native taught you to delegate to AI. Claude Cowork is the other 90% was originally published in JavaScript in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.