DEV Community: Malik Chohra

Will AI assistants stop people from opening mobile apps?

Malik Chohra — Sat, 14 Nov 2026 14:33:24 +0000

TL;DR

My view: voice is the next way we talk to our devices. For many tasks you will not open an app. You will tell your AI assistant, and it will use the app for you.
AI agents reached the web first. Mobile is next: the assistant calls your app, AI runs on the phone, and agents operate apps.
I expect an app that an assistant cannot use to be skipped. This is part 1. Part 2 shows how to get ready.

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 have shipped mobile apps for 9 years. In June I wrote about what WWDC 2026 meant for apps: Apple made AI visibility mandatory and AI integration provider-agnostic. Now, in November, the first signs of it are showing.

Voice is the next way we talk to our devices

The touchscreen changed how we use almost everything. The next change is voice: you tell your AI assistant what you want, and it does the job.

Say you need a flight to Lisbon on Friday. Today you open three apps, compare prices, type your passport details again and pay. I expect you to say: "Book me the cheapest flight to Lisbon on Friday morning." The assistant picks the app, fills the form and asks you to confirm. You never open the app.

AI agents learned to use the web first

An AI agent is an AI that takes steps for you instead of only answering. On the web, it happened in steps.

Anthropic released a beta in October 2024 where its AI could look at a screen, move a cursor, click and type. That is an agent using a website the way you do. Anthropic's MCP, the Model Context Protocol, is what it calls "an open standard" for connecting AI assistants to tools and data. Add plain API calls, which programs already use to talk to services. I count three doors for agents on the web: tools they can call, services they can query, and pages they can operate.

An agent uses what it can reach. A website with none of those doors waits for a human.

Mobile is next: three signs point there

1. Assistants are starting to call apps

Siri AI is Apple's new Siri that does things inside apps for you. Apple opened a developer preview to every developer on 3 November 2026. Apple's preview page says customers get it "in a few months". Apple's rule: "Siri can only perform actions you make explicitly available".

Google's version for Android, AppFunctions is an experimental preview as of November 2026. It lets an app tell the assistant what it can do. If this pattern holds, the assistant will choose among apps, and it can only choose the ones that said what they do.

2. The phone is starting to run its own AI

Apple opened its on-device model to any app in June 2025. That is the AI that runs on the iPhone and not on a server, and Apple calls it "free of cost" and "available when users are offline". On Android, Gemini Nano, Google's small model for the phone, runs in Google's AICore service and "enables offline functionality". I read "free of cost" as no per-request bill for the app, and offline means smart features that work on a flight.

3. Agents are starting to tap through apps

Google began a beta in February 2026 where Gemini runs steps in apps for you, "in a secure, virtual window". It started with select apps in the food, grocery and rideshare categories, in the US and Korea.

Meta's September 2026 announcement of Muse describes a personal AI agent that "actually does the work". I have not checked whether it has reached your phone yet.

I predict an agent will run your booking or checkout flow. It will not care how nice your onboarding screens are. If the flow confuses it, you lose the sale.

Start with one question about your app

The direction is clear to me. The shape and the date are not.

I see this as the biggest shift since the touchscreen. So adapt early. Ask one question about your app: what does it let people do, and could an assistant find that? If you do not know, that is where to start.

Part 2 is where the homework starts: how to get your app ready, step by step.

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

Why Does Your AI Keep Guessing About Your Project?

Malik Chohra — Wed, 11 Nov 2026 18:07:42 +0000

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, a plain-Markdown workspace that gives your AI a memory it can continue across sessions, 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 Claude Code, Codex or Cursor on a project most days, this is the setup that saves you 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.

One main file that every coding agent reads first, with the commands that prove a change works.
A one-line file for Claude Code that sends it to the main file.
A facts file, where each price, plan name and setting has one home.
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.

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.
The implementer writes the button with its tests, one task at a time, and the tester runs the suite.
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.
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.

More context will not fix your AI handoffs

Malik Chohra — Wed, 04 Nov 2026 22:04:00 +0000

TL;DR

ICM is a way to organize your files so an AI can find its way around them. A few small files each say where to go next, so the agent reads only what its task needs.
Folders tell an agent where to look. Six questions cover the rest of the handoff: owner, context, effects, evidence, continuity, learning.
The free Second Brain Starter ships the two ICM skills I use for this: Jake Van Clief's original icm-architect, which I borrow, and my own second-brain-icm.

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

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.

How to scale a Second Brain into a Company Brain

Malik Chohra — Fri, 30 Oct 2026 11:43:24 +0000

TL;DR

A Company Brain is a shared notebook that people and AI agents both read. A team needs four things your notes never needed alone: an owner, a reader rule (a check on who may read what), a waiting area and a date on every fact.
The free Second Brain Starter is a one-person start.

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.

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.

New facts should wait before agents read them

Saved links land in a 06-Dump inbox first. My own /dump command sorts them into notes later. I counted 75 saved reels older than 14 days that I never processed. The waiting area works. I am the part that does not.

Box puts that wait in front of agents too: "New files land in a _staging area; only approved files move to the approved area that agents are pointed at."

Approved facts still age

When a rule in my vault changes, I add a dated note at the top that overrides the text below it.

Say you change the refund window from 30 days to 14. The old page stays approved. The agent keeps promising 30 days. Forty customers a month take it up on a 59-euro refund. With made-up numbers, the sum is 40 times 59, or 2,360 euros a month.

Facts that quietly stop matching reality are drift. Box calls it "the default failure mode of any knowledge base" and says to "pair this with a scheduled review per domain." A review-by date is the day a page stops being trusted until someone checks it again.

The why and the parts each get a longer piece

Pick one area and give it an owner and a date

Before you hand yours to anyone, do the boring step first:

Open the main note of one area, like pricing or the refund policy, and write an owner's name and a review-by date at the top.

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

The four parts of a Company Brain

Malik Chohra — Wed, 28 Oct 2026 17:53:58 +0000

TL;DR

A Company Brain is a shared notebook that an AI keeps up to date. It does four jobs. A notes app gives you two of them. You build the other two.
The free Second Brain Starter covers the storing and the answering. Collecting and clearing out are yours to add.

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.

This is the sixth piece in a chain, from one person's Second Brain to a team's Company Brain. The full list is at the end.

Every time you ask an AI about your documents, it starts from zero. In April 2026 Andrej Karpathy wrote a short file called LLM Wiki about how to stop that.

Karpathy says the AI "is rediscovering knowledge from scratch on every question. There's no accumulation."

His fix is to have the AI write a wiki, a folder of linked notes, as it reads. When a new source arrives, it notes "where new data contradicts old claims." The result is "a persistent, compounding artifact."

You do not write the wiki. You pick the sources and ask the questions.

That works for one person. A company has more people, more sources, and facts that change every week.

So what does a Company Brain actually do all day?

Slite looked inside a dozen of them in September. Slite sells one, so it has a stake in the answer. I use its split because it is the one public source that names all four parts, and I test each part against my own setup. Its finding: every company brain "breaks down into the same four components."

Getting signals. What happened today reaches the brain.
Remembering. The brain stores it so it can be found again.
Dreaming and pruning. The brain tidies up. It merges duplicates and retires old facts.
Speaking and searching. People and agents ask it questions.

An agent is an AI tool that does a task on its own, like writing code or drafting an email.

1. If it never arrives, the brain never hears

Slite calls this part getting signals. The brain has to hear what happened: calls, chats, error reports, emails. In Karpathy's version, this is you dropping a new source into the folder.

Say Sentry, the tool that reports app crashes, flags that checkout fails on older Android phones. Two people fix it in a Slack thread on Friday: checkout now needs Android 9 or newer. On Monday an agent writes the release notes. It never saw the thread, so the notes say nothing about it.

In my Second Brain. When I save an Instagram reel on my phone, a shortcut adds it to one file, reels-inbox.md. Other notes go into a 06-Dump/ folder. Later a /dump command files each one where it belongs.

30 of the 108 links in the inbox are still marked pending-evidence. That means I have not watched them yet. Collecting is easy. Reading is the work.

2. Memory needs a shape

Slite calls this part remembering. You may say your agent can already read the whole folder. It can. That is the problem. Storing and remembering are different jobs. A folder of exported chats is only storage. A fact becomes memory when it sits in a shape you can ask about: one fact, one place, a date on it. Karpathy's shape is a folder of linked text files, one topic per page. I compared how four Claude Code setups store memory in How gstack, Superpowers, claude-mem and ECC handle memory.

Say you export every Slack channel into one folder and ask your agent, "Which database do we use?" It finds forty messages. Half say Firebase and half say Supabase. It cannot tell which half is current.

In my Second Brain. My agent's memory is a folder of 666 short notes. Each note holds one rule or one fact. The file name says what kind it is, like decision_ or feedback_. An index file lists them. The agent reads the index first, then opens only the notes it needs.

So "what did I decide about the price?" has an answer. It lives in a file whose name starts with decision_.

3. Old facts have to leave

Slite calls this part dreaming and pruning. Dreaming is the brain tidying itself: a job that re-reads what was learned that day and re-links it, "the way sleep consolidates memory." Pruning is the other half: "retiring what no longer holds."

Say you raise your price from 49 to 59 euros in June. Both prices now sit in your notes. An agent writing a sales email finds the old one first and quotes 49. You lose 10 euros on every sale.

Amazon built a feature for this. Its AgentCore Memory, in an October 2025 write-up, says the system will "resolve conflicts." The newest fact wins, and the old one stays on file, marked invalid "instead of instantly deleting them." Karpathy's gist has the same idea in one phrase: "noting where new data contradicts old claims."

In my Second Brain. My rule is one line at the top of the vault: never delete a memory or a log, archive it. When a memory stops being true, the file moves to a memory/archive/ folder. There are 18 files in it so far.

A /reorg command is my manual dream. It folds what the daily logs taught me back into the rules, then archives what is finished or replaced. I run it when the vault feels messy. How to build a Second Brain that stays useful is the longer story of keeping a brain current.

A tidy brain still answers. Pruning decides whether it answers with this quarter's facts.

The limit. Pruning can lose something true. An old price is wrong for "what do we charge today?" and right for "what did we charge in May?" That is why Amazon keeps the old fact, and why I archive instead of deleting. Slite adds that the few tools that automate this "keep a human in the loop."

So the rule is short: the old fact leaves the answer and stays on file.

4. Agents need a door

Slite calls this part speaking and searching. It is the door. People ask questions in a chat. Agents need the facts delivered to them. Slite puts it this way: "Humans want a conversation. Machines want an endpoint."

An agent can read only so much at once. That limit is its context window, and it is smaller than your whole company. So this part decides what the agent reads first.

Say the record is perfect and lives in a Notion page. A new teammate's agent has no access to Notion, so it reads the code and guesses. The brain knew. Nobody gave the agent a door.

Karpathy's door is simple. He keeps the "LLM agent open on one side and Obsidian open on the other," and asks it questions. (Obsidian is a free notes app.) A team needs the same door for people and for agents.

In my Second Brain. My door for agents is a table in one file, CONTEXT.md. It has six rows. Each row is a kind of task, like content or weekly review, and names the first file to read. An agent starting a content task reads one row and opens one file. It does not load the whole vault and hope.

Each piece answers the question the last one left open

The chain so far:

Why every builder needs a Second Brain. One person, one brain.
How to build a Second Brain that stays useful. Keep it current.
How gstack, Superpowers, claude-mem and ECC handle memory. Four ways to remember.
What is a Company Brain?. The same idea for a team.
Why are builders building Company Brains now?. Agents now do real work, and work needs context.
This one. What a Company Brain does all day.

Which part is missing from yours

A notes app and a chat window already give you remembering and searching. Collecting and tidying up are the two you build yourself. Without them, news arrives by luck and old facts stay until someone gets annoyed.

So here is the one decision for this week:

Pick the one of the four that is missing from your setup.
Fix that one.
Today, open your notes, find one fact that is out of date, and write today's date next to it. Now the next reader can see how old it is.

If you picked remembering or searching, the free Second Brain Starter is a small, one-person start. It has no dreaming or pruning job. If you picked that one, copy my /reorg habit.

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

Why are builders building Company Brains now?

Malik Chohra — Mon, 26 Oct 2026 18:51:08 +0000

TL;DR

AI agents now do real work instead of only answering questions. When the context they read has a gap or an old fact, the result is finished, confident, wrong work, and nobody stops to ask.
The fix starts small: one dated record, with owners, that every person and agent reads first. The free Second Brain Starter is that first layer.

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 hand real tickets to a coding agent, you have probably watched it ship clean code with green tests that still breaks a rule your team agreed on. The rule lived in a call or a chat, and the agent never read it.

Last time, in What is a Company Brain?, I said what one is: the shared, current record of what a team knows, read by people and AI agents. So why are so many builders making one right now?

An agent is an AI tool that does a task on its own: writes the code, drafts the email, files the ticket. Context is everything it reads before it starts. Until recently, most of us used AI to answer questions, and a wrong answer cost you a raised eyebrow. Now it does the work, and a wrong fact in its context costs you the work.

The gap in what a team knows was always there. What changed is who falls into it.

The gap nobody can see

Say your team takes payments with Stripe. Last month, on a call, you agreed that any refund over 500 euros needs a second person to approve it. Everyone on the call nodded. Nobody wrote it down.

A new teammate asks an agent to build a refund button in the admin panel. The agent reads the code, reads the docs, builds a clean refund button with no approval step, and the tests pass. It did exactly what its context said. Its context just never heard about the call.

A person in the same spot would probably have asked "anything I should know about refunds?" and heard about the rule. An agent cannot ask about a gap it cannot see. For an agent, what is missing from its context does not exist.

A person knows when they don't know something. An agent fills the hole and keeps going.

The fix. Write decisions down in the place every tool reads first, with the reason, the date and one owner. For most projects that place is a README, the file at the top of a project that tells people and tools how it works, or a decision file it points to. "Refunds over 500 euros need a second approver, decided 12 September, owner: you" is one line. It is the line the agent needed.

The plan that was already wrong

On 31 July 2026, I split one piece of engineering work into five small tasks and gave each to its own agent. I wrote the five task notes from a plan I had written the day before, so it felt fresh.

Three of the five agents came back with the same kind of problem. My notes described the code correctly as it was when I wrote the plan. The code had moved since.

One note said a feature was missing. It already existed. The real bug sat inside that existing code, and it was worse than what I had described. If that agent had trusted my note instead of opening the file, it would have built a second copy of something we already had, passed every test, and left the real bug in place.

The plan was one day old. That was enough.

The fix. Treat every note about the work as a claim about the work, and give it a date. Then add one standing line to every note you hand an agent: "If this note and the source disagree, the source wins. Say so in your report." My agents caught the problems because they opened the files. Now I ask them to.

The handoff that was six days old

On 8 August 2026, I pasted a handoff note into a new session, a short summary of where the last session had stopped, and typed "continue this." The session checked the date and got the wrong one: its clock said 2 August. It was 8 August, and two newer handoff notes already existed.

So it took a six-day-old note as live and started rebuilding work that had already shipped. That included email drafts to people who had already been emailed, with the same subject lines. Nothing was sent. That part was luck.

A stale fact in front of a person is one wrong sentence. A stale fact in front of an agent is a starting point. It builds on it, and what it builds becomes context for the next task.

The fix. Before an agent acts on any note, it checks three things: today's date, read from the files instead of a clock; whether a newer note exists; and whether what the note says is still true. In a Company Brain the same idea becomes a rule: one current status per project, with older versions moved to a history file instead of left lying around. The newest note is then the only one an agent can find.

What changed this month

The tools noticed too. In the last few weeks, "shared context for agents" stopped being a blog idea and became a product line.

Notion, 13 October. Its 3.8 release is called "Context for your agents" and opens with "Your agents and teams run on context."
Notion again, 19 October. It rebuilt the connector that lets outside agents read and write Notion, "so your favorite agents can use Notion as a shared brain."
Neo4j, 20 October. The graph database company launched a Context Engine, which a StorageReview report described as "a shared, reusable knowledge layer" for agents.

Earlier this year, two of the biggest work-tool companies set this up:

Atlassian, 6 May. It opened its Teamwork Graph, the map of who works on what across its tools, to outside agents: "Every AI tool your team uses can now run on the collective context you've already built."
Microsoft, 2 June. It announced Work IQ APIs so "agents can work from the most relevant and continuously updated context."

When the company behind your notes app and the company behind your ticket tracker ship the same idea within months, you can stop wondering if the problem is only yours.

Where the evidence gets awkward

The best measurement so far cuts against the easy story.

On 5 October, VentureBeat reported that 64% of 130 enterprises had traced a confidently wrong agent answer back to their own company data in the past six months. Those 130 chose to answer, so the number says the problem is common among teams who care about it. It says nothing about the whole market.

Then the twist. In the same report, firms already running a governed context layer (a shared, managed record their agents read from, roughly what a Company Brain is) reported these failures more often: 78%, against 37%. The report does not show why. Maybe teams with a shared layer look harder and find more. Maybe a shared layer spreads a bad fact further. I can't tell from the numbers, and I won't pretend a Company Brain cuts errors.

There is a second risk. A shared record is something many people and agents write to, and researchers have shown in lab tests that text planted in an agent's memory can steer what it does later. I looked for a named company hurt this way in 2026 and found none. No named case is still a long way from safe.

So what makes a shared record worth trusting is the boring part from last week:

An owner per fact. One person whose job is to keep it true.
A date on every fact. So a reader, human or agent, can see how old it is.
A history instead of a delete. Old facts move out of the way, so nobody reads them as current.

Where to start

You don't start with the company. You start with one person's record, kept the way a team will need it: one facts file per project, every fact with a date and an owner, old lines moved to history. Then you tell every agent to read it first and to trust the source over the note.

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

Agents will keep getting better at doing the work. They will never get better at knowing what you forgot to write down.

Follow for more, I write up the things I actually run.

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

I compared four Claude Code memory tools, and why I still keep a Second Brain

Malik Chohra — Sat, 24 Oct 2026 17:48:22 +0000

TL;DR

Four memory tools for AI coding agents, compared on where memory lives, what it costs in tokens, how hard each is to set up and change, and how stale entries get caught. gstack and Superpowers teach the AI how to work, claude-mem records what happened, ECC stores memory files and treats them as unreviewed.
A Second Brain answers a fifth way: it keeps what is true about your project right now, with a date on every fact. The free Second Brain Starter has the files to copy.

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 to build a Second Brain that stays useful, I built one from five records and a fresh-session test. Four memory tools for coding agents keep showing up on builders' feeds. Here they are side by side, and next to it.

Four ways to compare memory tools

A new AI session starts empty. Everything it knows about your project comes from what gets loaded in the first seconds.

Developers gave the AI a memory by hand long before these four existed. The best-known version was the Memory Bank: a folder of structured Markdown files that the assistant reads at the start of a session and updates as it works. Cline's documentation describes it that way. I wrote about it for Cursor in How to Enhance Cursor AI Memory Bank and about the habit itself in Give the AI a memory.

Three things made it spread:

No tooling. The memory is ordinary Markdown files, so any assistant that can read a file can use it.
Visible. You open a file and see what the AI knows about the project.
Editable and versioned. The files live in the repo, so you correct a wrong line by hand and git keeps the history.

Memory handling is more than the start of a session. The tools below are compared on where the memory lives, what loads at the start and what waits until it is asked for, what it costs in tokens, and how a wrong or old entry gets found.

gstack: a team of roles

gstack is Garry Tan's open-source pack of Markdown slash commands. Each command turns Claude Code into one member of a small team: a CEO who challenges the plan, a designer, an engineering manager, a QA tester, a release engineer.

It has about 137,000 stars and an MIT license.

You install it by cloning the repo into ~/.claude/skills/gstack and running ./setup. It needs Bun.

Memory

/learn. Lets you review, search and prune what gstack picked up about your codebase.
Design taste. A profile of what you approve and reject that fades by 5% a week.
GBrain. An optional add-on with a separate knowledge base, which the README calls the memory your agent keeps between sessions.

Superpowers: a method the AI follows

Superpowers is a skills framework and a development method by Jesse Vincent and the Prime Radiant team. It has about 304,000 stars and an MIT license.

On Claude Code you add it with /plugin install superpowers@claude-plugins-official.

Its skills trigger on their own. Before a task, the agent checks whether a skill applies: brainstorming before building, a plan before code, a review before done.

Memory

Session start. A short startup skill, called the bootstrap, is loaded at the start of each session so the agent knows the other skills exist.
Store. The README describes no memory store. What Superpowers carries from session to session is a way of working.

claude-mem: record everything, replay what matters

claude-mem is Alex Newman's plugin. It has about 103,000 stars and an Apache-2.0 license.

Install is npx claude-mem install. The installer asks you to sign in.

The README says sign-in unlocks a 30-day free trial of its hosted memory provider, and afterwards memory runs on your Anthropic plan unless you subscribe or bring your own key.

Memory

Capture. Hooks fire at six moments in a session: start, prompt, before a tool, after a tool, stop and end. They send what the agent did to a small local service.
Storage. The service compresses it with AI and stores it in SQLite, with a vector index for search (a database index that finds notes by meaning as well as by keyword). A <private> tag keeps a passage out of storage.
Replay. At the next session start, relevant past context is put back in.

ECC: memory as unreviewed files

Everything Claude Code, now at affaan-m/ECC, is Affaan Mustafa's bundle of skills, rules, hooks and memory for Claude Code, Codex and others.

It has about 288,000 stars and an MIT license.

Install is npx ecc-universal@2.2.3 setup, the pinned form the README gives, or through the plugin marketplace.

Memory

Where it lives. A Memory Vault stores plain Markdown documents, in .ecc/memory/ for a project and ~/.ecc/memory/ for you.
Session hooks. A session-start hook loads context and a session-end hook saves it. A small set of learned patterns, called instincts, is injected at the start up to a cap.
Trust. The README calls memory unreviewed context, and it says a human promotes accepted knowledge into the project's own documents.

What a Second Brain does differently

This part is my approach. Here is how I read the gap each setup leaves:

gstack. The roles are the center of its pitch and memory is the smaller part. If the AI plans without being challenged, the roles are aimed at that.
Superpowers. It teaches the AI how to build. Your project's facts still have to come from somewhere else.
claude-mem. Say you spent Monday moving a login flow from one Supabase project to another. By Thursday it can hand the new session a summary of Monday, which is a strong answer to forgetting. The summary is a history written by a model, so if Monday's plan changed on Tuesday, the history holds both and the new session has to work out which one is current.
ECC. Someone has to decide which saved note is true, and it leaves that step to you.

A Second Brain keeps current facts in plain files you own, and it makes the review step part of the system instead of leaving it open.

The shape from Article 2 is five records per project. Rules name the route the AI follows. A facts file holds current values, each with a checked date. A decisions file holds one line per choice with its reason. A roadmap holds open work with evidence. A progress log ends with a Next line.

The AI reads rules and facts first and the rest on demand. I run a fresh-session test to prove it recovers a decision from the files alone.

At the last count, on 22 October 2026, my own vault had 645 memory files, 119 skills, 41 commands and 640 session reports. It stays usable because the project records are small, dated and reviewed weekly.

The four answers side by side

Setup	Where memory lives	Loads at session start	How a stale entry gets caught
gstack	Per-project learnings, optional gbrain knowledge base	Roles load when you call them	`/learn` lets you review and prune
Superpowers	No memory store in the README	A bootstrap skill, then skills as tasks need them	Not a memory feature
claude-mem	SQLite plus a vector index, local service	Relevant past context, injected by hooks	No stale-entry check; `<private>` only keeps passages out of storage
ECC	Markdown files in `.ecc/memory/`	Hook-loaded context and a capped set of instincts	You review and promote into project docs
Second Brain	Five Markdown records per project	Rules and facts first	Checked date on every fact, weekly review

The last column is the one I weigh most, because an old entry read with confidence is the failure that costs me the most time. Each of the four rows solves a different problem.

Tokens and answer quality

Each setup spends tokens in a different place. What follows is what the READMEs say about their own design. Measured token use and answer quality are a separate test.

gstack. It ships gstack-context-bill, a read-only audit of what an installed skills tree costs in tokens: the always-on frontmatter every session pays, against the skill text that loads when you call one.
Superpowers. The startup bootstrap loads each session and skills load when a task triggers them. The README has a diagnosing skill for sessions that burn more tokens than you expect.
claude-mem. Search works in layers: a compact index first, at about 50 to 100 tokens per result, then full details only for the results you pick, at about 500 to 1,000 each. The README claims about 10 times fewer tokens from filtering first. That figure is the author's claim.
ECC. Skills load on demand and rules are always loaded, so the README says to install rules selectively. Injected instincts are capped at 6 by default, with a minimum confidence of 0.7.
Second Brain. Rules and facts load first and the rest on demand. The records stay small because each holds one kind of thing and gets reviewed.

Which one fits which problem

The AI plans without pushback. gstack's roles are built for that. Start there.
The AI skips steps or builds before it plans. Superpowers makes the steps a habit.
The AI forgets what happened last week. claude-mem replays history automatically.
You want portable memory files across tools. ECC's vault is plain Markdown.
The AI is confident about a fact that stopped being true. A dated record makes each fact's age visible. The other setups catch stale entries through manual review or pruning.

You can run more than one. A skill pack for how to work and a Second Brain for what is true is a combination I would choose before any single one of these.

Setup and personalization

The same five, compared on how much work it is to start and how much you can change.

Tool	Setup	Personalization
gstack	Clone the repo into `~/.claude/skills/gstack` and run `./setup`. It needs Bun. Team mode adds a command that commits the setup into the repo.	The commands are Markdown files and the README says to fork it and make it yours. Model choices per host are settings, and some hooks are opt-in.
Superpowers	One plugin command on Claude Code.	The README points to forking the repo for changes and gives one opt-out setting, for telemetry.
claude-mem	`npx claude-mem install`, a browser sign-in, and a local background service with its own database.	A settings file controls the AI model, worker port, data directory and what context is injected. A `<private>` tag keeps a passage out.
ECC	An `npx` command or the plugin marketplace, across several coding tools. The README warns against stacking install methods.	A `/ecc:configure-ecc` skill reconfigures it, and a setting caps how many instincts are injected. Memory has a project scope and a user scope.
Second Brain	Copy the plain Markdown files of the free Second Brain Starter. The assistant shows the setup plan before it writes anything. The initializer needs Node.js 22 or newer.	Everything it loads is a Markdown file you open and edit. The rules file decides the route, and you add the facts and decisions yourself.

The free Second Brain Starter is plain Markdown. Open it in Claude Code or Codex and type Set this up for me.

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

Why I keep a Second Brain for Claude Code, and why you should too

Malik Chohra — Fri, 23 Oct 2026 12:44:52 +0000

TL;DR

AI forgets, cannot see what lives in your notes and calls, and answers with full confidence anyway.
The fix is a Second Brain: plain files, one record per project and one per client, that every tool and person reads before work starts. The free Second Brain Starter is where to begin.

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 use a Second Brain every day: plain files that Claude Code and my other AI tools read before they start work. Counted on 22 October 2026, it holds 645 memory files, 119 skills, 41 commands and 640 session reports. This is why I have one, and why I think you should too: six places AI goes wrong across projects, and the file that fixes each.

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.

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.

It forgets. Every new chat starts from zero, so last week's work is gone.
It has no access. The answer sits in a note, a call or someone's head, and the model never sees it.
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.

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.

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.

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.

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.

What to do this week

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.
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.
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.

Second brain 101: what your AI loads at session start, and what it drops

Malik Chohra — Thu, 20 Aug 2026 08:27:19 +0000

TL;DR

An operating system for your AI is one folder it reads before it works and writes back to when it learns. The folder takes an afternoon. The write-back is the part that makes it a system.
Not all of it loads. One short index file loads at session start, and a detail file gets opened only when something in the index points at it. Past 200 lines or 25 KB the rest of the index is dropped, quietly, with nothing in the transcript to tell you.
CLAUDE.md is read first and in full, and the runtime walks up the folder tree from wherever you launched. Put it one folder down and it is not there at launch. It gets read later, on demand, the first time your AI opens a file in that folder. Mine is 41,480 bytes and lives in 00-Meta/, so 8 of my 31 commands pull it in by name and the other 23 do not.
Rules are read. Hooks are run. Anything that has to happen every time, and not most times, is a hook.
The receipt after a few months of this: 465 memory notes, 474 entries in my own decision log, 454 in both places under the same filename, 441 carrying the write-back footer. I typed none of it.

This piece is from Code Meet AI, my newsletter where I document how I actually use AI to ship real products, receipts included.

AI for techies · 10. Last time I went through how to create your own commands, which is one saved job you run again by typing one word. This one is about the place all those jobs run inside.

By now you have the pieces. An instructions file. A skill or two. A command you actually use. Maybe a second agent you hand the boring half of a job to.

Each one works. None of them is broken. And you still open a new session by explaining where things are, which project, what you settled last week, why that folder is named that.

This is mine. Every dot is one file, every line is a link between two of them, and the folders down the left are the whole filing system.

the pile of parts problem

The pieces do not know about each other.

What your AI worked out on Monday is not in the file it reads on Tuesday. It found the answer, you moved on, and the answer stayed in a chat window that is closed now. Next week you ask the same question and it starts from nothing.

So you pay for the same thing twice. Once to work it out, and once to hold it in your own head well enough to say it out loud again.

A pile of good parts is not a system. What makes it a system is that the end of one session is the start of the next one.

an operating system is one folder and one loop

One folder your AI reads before it works, and writes back to when it learns.

That is the whole sentence. The folder is the easy half and you can build it in an afternoon. The loop is the thing: read, work, write back, and the next session opens on what the last one learned.

A folder is a one way trip. The loop is what sends the next session back in.

the eight parts

Most of these you already run one at a time.

The folder. Files on disk, sorted by what you are doing with them. That is all it is.
The memory. Your AI writes its own notes and keeps them in its own folder, not in yours, which is how you give it a memory. Mine holds 465 of them.
The rules. A CLAUDE.md is the file that gets read first, in full, before any work starts, and what you write down once is most of the job.
The skills. One kind of job, saved as a folder. It costs you nothing until it is used: your AI sees the name and one line about when to reach for it, and opens the body only when a job matches.
The agents. A second AI with an empty head. It does not get the main session's memory, and that is the one that catches people out. What it needs goes in the prompt you send it, or it works blind. Six of these sit in my personal agents folder.
The hooks. Rules are read, hooks are run, and this one is where I went through them properly. A hook is a small program the tool itself runs at a fixed moment, whatever the model decides. I have seven, on four moments: before a tool runs, after a tool runs, when I send a prompt, and when the session stops.
The commands. A prompt you saved in a file, so you type one word instead of ten lines.
The write-back. At the end of a session, what was learned gets written back into the folder it was read from. Nobody writes about this one, and it is the part that turns seven good pieces into a loop.

what actually loads, and what does not

This is where the tidy version is wrong, and being exact here saves you an afternoon of wondering why your AI ignored a note you can see on disk.

Pointing it at your notes folder does not mean it reads your notes.

One short index file loads at the start of every conversation. A detail file gets opened only when something in the index points at it. So the index has a budget, and it is a hard one: past 200 lines or 25 KB, the rest is dropped. Quietly. Nothing in the transcript says a word about it. Mine sits at 117 lines and 22,252 bytes, which is closer to that ceiling than I am comfortable with.

Skill bodies behave the same way. Name and trigger line up front, body on request.

Hooks sit apart from both, because a hook is the only one of the three that is not a suggestion.

The folder holds 465 files and the index is one of them, so the detail files are 464.

where your CLAUDE.md really sits

The runtime walks up the folder tree from wherever you opened the session and reads every CLAUDE.md it finds on the way. In full, before any work starts.

So placement is load-bearing. Put it where you start, not one folder down.

Mine is 41,480 bytes and it lives in 00-Meta/. There is no CLAUDE.md at the top of my vault. When I open a session at the top, that file is not loaded at launch.

It is not invisible either, and this is the part that gets stated wrong in both directions. It gets read later, on demand, the first time my AI opens a file in that folder, which is after the work has already begun. Eight of my 31 commands pull it in by name, so those eight get it up front. The other 23 do not.

If a rule has to be in the room from the first token, the file has to sit at the level you launch from. Otherwise you are relying on the work happening to walk past it.

three ways in

The effort climbs with each one.

It already does some of this. Auto memory is on by default, and any CLAUDE.md above your working folder is read in full when you launch.

You ask for it in plain words. Say "remember that". Say "add this to CLAUDE.md". Say "save that as a skill". It writes the file, in the right place, and you never have to learn the folder layout. /init will write you a first CLAUDE.md from the project you are sitting in.

You set it up so it is always there. The docs are blunt about the difference: "Settings rules are enforced by the client regardless of what Claude decides to do. CLAUDE.md instructions shape Claude's behavior but are not a hard enforcement layer." So anything that must happen every time is a hook. Not a line of instructions.

A rule is read. A hook is run. That is the whole difference between rows two and three.

the loop on my own disk

My /endSession command has a phase 3, and it is a few lines of plain English. New facts about how to work with me or my projects go to memory files, plus one line in the index, plus a stub in the vault's decision log.

Here is what those few lines produced.

The memory folder holds 465 notes. My own decision log holds 474. 454 of them exist in both places under the same filename, and 441 carry the same footer line saying they were written out from the memory bank.

I did not type any of that. The session that learned the thing wrote it down on the way out, and the next one opened on it.

That is the loop. The folder my AI read from is the folder it wrote to.

where to start

Do not build the whole thing. Pick the one thing you explained to your AI twice this month.

At the end of your next session, say: write that into CLAUDE.md so you have it next time. Then open a new session tomorrow and check whether it did.

If it did, you have a loop, and everything after that is filling it in.

If you would rather not start from empty, the prompt that builds the whole folder is in my guide, Build a second brain with Obsidian and Claude Code. Paste it in and it writes the files for you.

This one came from Code Meet AI, the newsletter where I write up the setups I actually run and the numbers come off my own disk. Next episode is how to keep this working once the folder gets big.

Wire AI Is Live: Beta tester open

Malik Chohra — Thu, 30 Jul 2026 16:19:58 +0000

TL;DR: 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.

This article is part of my Code Meet AI newsletter: https://codemeetai.substack.com

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

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.
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.
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.
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.

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.
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.
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.
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.
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.
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.

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.
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.
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.
There's a console. Register an app, edit the config without cutting a release, read the funnel, open any session and read the transcript.
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.

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.
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.
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.
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.
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

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.
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.

Fable 5 vs Opus vs GLM: I had a cheaper model grade the audit of my own code

Malik Chohra — Tue, 21 Jul 2026 09:43:04 +0000

i'm building Wire AI, and the next piece i have to build is the learning loop. It's the self-improving core of the engine: it takes each user's journey inside the app, generates variations of that flow, tests them, and keeps whatever makes people activate and stay. Real implementation work, a big pile of it, and the kind you'd rather not write by hand at frontier prices every single time.

so i wanted to do that build with a cheaper Chinese model, GLM 5.2, instead of reaching for a frontier model on reflex. one problem. cheap-and-wrong is the most expensive thing there is, and i was not about to let a model i hadn't vetted write production code inside my own engine. so before i trusted it with anything, i gave it a hard, real technical challenge: audit the actual codebase behind Wire AI and tell me where it breaks. not a benchmark, my own code, the files i'd opened a dozen times and thought i understood.

and i didn't just point GLM at it and hope. i ran the same audit through three models to see where the cheap one really lands: GLM 5.2, the candidate i actually wanted to hire for the build; Opus 4.8, my daily driver and the reference i already trust; and Fable 5, the ceiling. cheap, reliable, frontier, same job, and i'd grade every finding myself.

Here is what happened, with the receipts, because a feeling is not evidence.

Most model comparisons you read are benchmark charts on tasks neither you nor the author care about. i wanted the other thing. One real task, my own codebase, the actual numbers off the runs instead of vibes. So i gave three models the identical job inside Claude Code: audit the architecture of this SDK and tell me where it breaks when i build on top of it. Same prompt, same files, same instruction to cite every claim with a real file path. Then i read every output against the source and counted what was actually true.

a quick aside on what the codebase even is

The code i audited isn't a side project. It's the engine behind Wire AI, the thing i'm building, and it helps to know what it does before you watch three models take it apart.

Wire AI finds your app's winning formula. The one-breath version of how: it runs the experience inside your app, the first session a user gets, the moment they finally get it, the parts of the app they find, what they tell you back, then tests the variations itself and keeps the ones that make users stay. You set the goal. The AI runs the loop.

Here's the part that's easy to miss, and it's the reason i keep testing this thing against real code. Changing the app with no release isn't the trick, plenty of tools do that now. The difference is who's holding the pen. In the usual setup a person sits in a no-code builder and drags the new flow together by hand. In this one there's no builder and nobody in the middle: the AI writes the variants, runs them, and promotes the winner. That's the whole bet, and it only works if the engine underneath is right.

The part i keep pointing models at is exactly that engine, the piece that generates and renders those flows at runtime, the server deciding what a given user sees and the app drawing it without a new binary. It's the code with real users behind it, so it's the code i actually need to be right. Which is why i handed it to three different models and read every word back against the source.

the audit, scored

GLM 5.2, the cheap one. Opus 4.8, the one i run every day. And Fable 5, the frontier model, the most capable one i have access to. Same job for all three.

GLM and Opus found the same five problems. Not similar problems. The same five, down to the files.

They both caught that my component types get sealed into the bundle at startup, so an agent can't define a component at runtime. They both caught that streaming is dead on the agent path because the adapter never implemented it. They both caught the drift between what my SDK can render, what my server allows, and what my model actually gets told about. They both traced the coupling between the SDK and the agent backend to the same leaky spot. And they both landed on the same fix, make the registry the single source of truth.

i verified the citations on both. Zero hallucinations, every file path checked out. GLM even found one extra thing Opus missed: a comment in my backend claiming it runs the latest Claude while the code underneath quietly calls a cheaper OpenAI model. The kind of lie your own codebase tells you.

So on those two it was a tie. One costs roughly ten times less than the other and it found the same five things. If the story ended there the headline writes itself, run the cheap one for audits, go home.

Then i gave Fable 5 the identical prompt, and it found eleven.

Not five. Eleven distinct architectural problems, plus three smaller ones it flagged separately as lower severity. The same five the other two found are in there. Then six more, and i checked those against the source the exact same way. The streaming path advertises a sixty second timeout in its own docstring while a hidden thirty second poll cap kills the request first. The mechanism the SDK exports to tell an agent what components exist is built, tested, and wired into nothing. The registry silently ignores a component swap if you keep the same name. The agent card reads a private Zod internal that a supported version of Zod no longer has, so it degrades to typeless without ever throwing an error. Real, cited, reproducible. Zero hallucinations again, and it rated its own weaker findings as medium confidence instead of overselling them.

Later i ran the inverse experiment, because trusting a frontier model on my own code without a check is exactly the mistake i tell everyone else not to make. i had a cheaper model independently re-verify all eleven findings, line by line, plus the three secondary ones. Fourteen confirmed, zero refuted. The frontier model found the problems, the cheap one confirmed the homework.

Take one of them, the sixty-versus-thirty-second one. My agent path promises sixty seconds right there in its own docstring, and underneath it a hidden thirty second poll cap kills the request first. i would have built onboarding flows on top of that, watched a perfectly legitimate agent run die at thirty seconds, and burned an afternoon blaming my prompt or the network before i found the real thing. Fable found it by reading. That's the one that landed for me, because it's the exact kind of bug you only ever meet in production, on a user's screen, at the worst possible time.

That's the finding that reframes the whole comparison. It's not that Fable is a better model on a leaderboard. It's that on a genuinely hard read, depth is not free, and the cheaper models stopped at the obvious layer.

the numbers behind the runs

This is the part i actually care about, pulled from the session logs, not estimated.

	GLM 5.2	Opus 4.8	Fable 5
Distinct problems found	5 (+1)	5	11 (+3)
Hallucinations	0	0	0
Turns / tool calls	69	64	40
Fresh input tokens billed	644,000	88,000	62,000
Wall clock	6.0 min	18.1 min	~8 min
Cost	$0.59	~$6	~$14

A few things jump out.

Token consumption runs the opposite direction from price. GLM billed six hundred and forty four thousand fresh input tokens for the job. Opus billed eighty eight thousand. Fable billed sixty two thousand, the fewest of the three, and it did the deepest read. The two expensive models lean hard on context caching, reusing what they've already read at a steep discount, and that's most of why they can cost more per token and still not blow up on input. You're not just paying for the weights, you're paying for how few fresh tokens the model needs to hold the whole codebase in its head at once.

But few tokens is not cheap. Fable billed the fewest fresh input tokens and still cost the most, because the frontier price sits on top of every token and its denser output is expensive to generate. GLM is a tenth of that. So the cost curve and the depth curve run in the same direction: you consume more, you get more, and the more here is real problems in real files, not padding.

Speed didn't track price either. GLM was fastest at six minutes. Fable came in around eight. Opus, on maximum reasoning effort, took eighteen, because i deliberately run it slow and thorough. Fast and cheap didn't mean shallow on the five, and slow and expensive wasn't the deepest. The deepest was the frontier model, at a middle speed. None of the tidy stories hold.

then i made one of them build

A read tests reasoning. It doesn't test whether a model can do unattended work. So i ran a second round, GLM only, on a real build: take the drift bug from the audit and fix it properly. Single source of truth, generated manifest, a test that fails if anything drifts again.

It worked. Ninety two tests passing when i ran them myself, a drift guard that failed correctly when i sabotaged it on purpose, two previously unreachable components wired through end to end. A clean, verified, tested refactor.

And the build burned nearly seven times what the audit did. Same model, same codebase, one fix. Not because the fix was large, because building unattended means iterating, and iterating burns tokens. Three hundred and seventeen turns. A hundred and twenty seven tool calls, more than half of them just running tests and reading the errors. On a read the cost gap is enormous and it's in GLM's favor. On a long build it closes fast, because the cheap model pays for its discount in extra steps.

what each model actually gave back

All three earned a job. That's the real conclusion, and it's more useful than a winner, because it tells me what to do on Monday.

Opus is the daily reliable read. It found the same five things GLM did, cited clean, no drama, on the everyday work where the answer sits at the obvious layer. It's the one i trust without babysitting it, and on a long autonomous build the token efficiency i pay for stops being a luxury and becomes the reason the job finishes cheaper than the sticker suggests.
GLM is the cheap different lens. It found the same five, at six hundred and forty four thousand tokens of brute-force reading instead of clever caching, and it surfaced the one comment the frontier model didn't. i don't care how it got there when the output is right and the run comes in an order of magnitude under the one i trust. For volume reads it's the pick, and even on a build it finishes, it just pays in turns.
Fable is the surprising deep finder. It found six real problems the other two walked straight past, in the exact files, with honest confidence about the ones it was less sure of. That's the model you point at the thing before you commit six months to building on top of it. One deep read to not ship on top of a broken assumption is the cheapest line item in the project.

None of them replaced the others. Cheap for volume, efficient for endurance, frontier for depth. Better outcome than a leaderboard.

where this actually went

Here's the part that isn't abstract. Those findings didn't sit in a doc. They went back into the engine, and the first tenant running it in production felt the difference.

The sixty-versus-thirty-second bug and the drift bug were the exact kind of thing that shows up as a mystery failure on a real user's phone. Hardening them was the point of the audit. Around the same stretch i chased the first-card latency on the onboarding and it dropped from about 2279ms to 71ms, because i prefetch the adaptive card while the user answers the fixed questions instead of after, so the first screen a user sees is close to instant now.

And the loop holds. On the live tenant it runs about 88.5% completion with zero server language-model fallbacks, on real production traffic. When the AI tested the flow length itself, the short version, roughly eight screens, won at 92.8% on its arm. Earlier in that tenant's life the same loop found the message that actually resonated and daily installs went from about 100 to 1,000, because it landed on the exact problem users showed up to solve.

i want to be honest about what that is. It's a set of real receipts, not one clean before-and-after conversion number. i don't have a single "we lifted X%" figure and i'm not going to invent one. What i have: a hardened engine, a first card that went from a beat-and-a-half to instant, a live flow completing in the high eighties to low nineties with nothing falling back to a language model on the server, and an acquisition number that moved because the loop found the words. That's the improvement, stated as the numbers i can actually stand behind.

That engine is Wire AI, and here's the one line that matters if you build apps. You put AI in your product, a feature, a chatbot, a recommendation. i let AI run mine, the loop above is the AI operating the product's experience, not sitting inside it as one more feature. Same instinct you already have, pointed one layer up. The easiest way in costs you nothing. Analytics free to 1M events/month. Forever. Any app. Wire it up and watch where your own funnel actually leaks before you commit to a thing. If you want the loop itself running your product, i'm taking 10 founders into a free founding cohort right now, and the deal is plain: don't pay if we don't improve your activation. i set it up with you hands-on and stay in it with you month to month, no invoice attached. If you just want to see where your app leaks first, i'll run you a free Activation Teardown, one AI report on your real users, ending in "here's what to fix", no strings. If you ship React Native and you've already got AI somewhere in the app, you're exactly who i want in that cohort. Reply and i'll run your teardown.

the honest caveats

Four, so nobody quotes this out of context.

This is one task type on one codebase. Strong evidence about reading and reasoning over real code. On building it's exactly one data point, GLM only, not a verdict.
The depth result is one audit. Fable finding eleven where the others found five is a real, verified result on this codebase. It is not a promise the frontier model always doubles the count. Run your own hard task before you trust the pattern.
The provider matters. i pinned GLM to its first-party host at full precision. The cheaper resellers serving the same model name can be quantized and worse, and then you're measuring the host, not the model.
And the telemetry isn't perfectly symmetric. The Opus and GLM numbers came from the original run transcripts. Fable's came from a clean re-run of the identical audit, and i've flagged every number that's measured slightly differently instead of smoothing it over.

If you want the raw data, the full audit from each model, the telemetry table, and the config i used to run all three, reply RECEIPTS and i'll send the breakdown.

context engineering, simplified

Malik Chohra — Tue, 21 Jul 2026 09:43:04 +0000

TL;DR

A prompt is the ask. Context is the ground it stands on: who this is for, what good looks like, the real material, and what to leave alone.
When the AI gives you generic or wrong output, the reflex is to write a cleverer prompt. Usually the prompt was fine and the context was thin.
More context is not better context. Dump everything in and the model loses the thread. Curation is the actual skill, and the boundary (what to ignore) is the load-bearing half.
Write the context down once, in a small set of files next to the code, and every future task starts from ground instead of a guess. Stale context is worse than none, so treat it like a dependency you keep current.

This piece is from Code Meet AI, my newsletter where i document how i actually use AI to ship real products, 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 here is the part that should get a senior dev's attention: the failure looked exactly like AI code that compiles clean and still ships a bug. Confident, plausible, wrong. The fix was never a better prompt.

a prompt is the ask, context is the ground

The prompt is what you want. "Write the migration." "Refactor this service." "Draft the onboarding." Short, and you already know how to write one. Context is everything the model needs to answer that well and doesn't have unless you give it: which service owns this, which files are generated and off-limits, what the system actually does and who is on the other side of it. 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 these contracts into a tracker" is a task. "so i can see at a glance which renewals are risky this quarter" 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 "our style is terse and functional," paste two modules that already read that way. 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 format. The interface it has to satisfy. The generated files it must not edit. 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 coming next, because 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 everyone gets wrong.

Once you learn that thin context causes bad output, the obvious next step is to feed it everything. The whole repo. The entire 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.

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. Telling the model what to ignore is as load-bearing as telling it what to read. This is the same discipline as scoping a service token: you grant the access the job needs, not everything you own, because blast radius is real whether the risk is a leaked secret or a distracted model.

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.

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.
Show, don't describe. Paste two or three real examples of what good looks like. A before, an after, a module you'd be happy to merge. This single move fixes most "it sounds generic" complaints.
Name the constraints and the anti-goals. The format, the interface, the hard limits, and the one or two things it must never do. Short bullets are fine.
Draw the boundary. Say what to use and what to ignore. "Only this package." "Don't touch the generated types." "The old implementation is background, not a template."

That's it. Four sentences turns a coin flip into something you'd actually ship.

write it down once

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. A five-minute setup becomes 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 for what the thing is and why. CONTEXT.md for what you are working on right now. CLAUDE.md and AGENTS.md for the rules and conventions you want followed. README.md for the human who lands cold. And 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.

where this breaks

Two ways, both worth knowing.

Stale context is worse than no context. A context file that still describes last quarter's architecture 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, and it belongs in code review like anything else that drifts.

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. A non-engineer has no compiler and no test suite to catch a confident lie, but neither does your prose. The review step is the job that does not get automated away, and it is its own episode later in this series.

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 set of files that give any AI your whole project'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 up for you. It goes out through the newsletter first.

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.

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.