AI Foundations and How-To

What Should I Automate With AI First?

By Arjita SethiAugust 26, 2026
Direct Answer

Not the task you dislike most. Build a context brain first, because every system you build afterwards reads from it. Takes about thirty minutes.

Build a context brain first. That is one structured place holding your positioning, your voice, your customer's actual words and your past decisions, including what you rejected. Every system you build afterwards reads from it, and the systems built without it produce output that is technically correct and sounds like nobody. The first version takes about thirty minutes, and it is the highest-leverage half hour available to someone who does not write code.

Almost nobody starts there. The instinct is to automate the task you dislike most, and that instinct is reasonable and it produces a system that works for about three weeks.

Why the annoying task is the wrong starting point

The task you resent is usually the one with the most exceptions in it, because that is often why you resent it. It is fiddly, it changes shape depending on who is involved, and it requires you to know six things that are not written down anywhere.

So you automate it, and the output is plausible and generic, and you spend more time correcting it than you saved. Then you conclude that AI is not there yet for your kind of work, which is a reasonable conclusion from the evidence you gathered, and it is the wrong one.

The problem was not the tool. The problem was that it did not know anything about you, and the task you picked required it to know almost everything.

The context brain, and what goes in it

A context brain is a persistent workspace holding documents. Not a chat window. Something that stays available and that every later request draws from, so you are not starting over each time.

Five things go in it, and the order matters less than the fact that all five are there.

Your positioning. What you sell, who to, what problem it solves, and what you have deliberately decided not to be. Plain language, no marketing polish. The polish is the problem, which I will come back to.

Three real customer emails or transcripts. Unedited. This is the highest-value input and the one people skip, because it feels like less work to describe your customer than to paste in what your customer said. Your customer uses words you would never have chosen, and those words are what should end up in your copy. A persona document is a guess and a transcript is evidence.

Ten voice rules, including the negatives. What you never say matters more than what you always say, and almost nobody writes the negative ones down. Mine include no em dashes, no emojis, and never opening with "I am excited to share."

A decision log. The last twelve months of real decisions, and the options you rejected and why. The rejected options do quiet, important work. They stop a system proposing something you already ruled out eighteen months ago for reasons you no longer remember but that were good at the time.

Your pricing history. What you charged, what you changed it to, and what happened.

If you want the mechanics of building this rather than the reasoning behind it, we have already covered them: what a context file is and why your AI needs one, how to write a business context document, and what documents to upload to a Claude project.

The Context Playbook

This is the first of six playbooks we teach, and a playbook is different from a prompt or a template in a way that is worth being precise about.

A prompt is a sentence. A template is a document. A playbook is a system that runs on a schedule, produces a named artifact, and works when you are not watching it. Most people collect prompts for a year and wonder why nothing compounds, and nothing compounds because a prompt produces one answer once and then you are back where you started.

The Context Playbook produces one artifact: a project brain. It is the only one of the six you have to build yourself rather than adapt from someone else, because it is made entirely of things only you have.

The build, in six steps.

  1. Open a persistent project workspace rather than a chat.
  2. Add your positioning document.
  3. Add three real customer emails or transcripts, unedited.
  4. Write ten voice rules, at least four of them negative.
  5. Add your decision log with rejected options.
  6. Test it by asking for something you would normally write yourself, then find the two or three places the output clearly drew on your context. If you cannot find any, the context is too thin, and the fix is almost always more real customer language.

The trap, which is boilerplate

The predictable way this gets built wrong is filling it with the About page, the mission statement and the brand deck.

All of that is public-facing language that has been sanded smooth by several rounds of editing, and it is exactly the material that produces generic output, because generic is what it was made to be. It has to work for everyone, so it says nothing about anyone.

The useful content is the unsanded material. The email where you explained a price increase to a customer who was unhappy about it. The decision not to build the feature three people asked for, and the actual reason. The two positioning lines you tried in the spring and dropped.

There is a second trap, quieter and slower. Building it once and never updating it after the business changes. A context brain describing a business you no longer run is worse than having none, because it is confidently wrong and you will not notice for months.

Why this is the moat

Anyone can write the prompt you wrote. Prompts are copyable and they are being copied constantly, and the good ones circulate within days.

What nobody else has is two years of your decisions, your customer's exact language, your voice including the things you refuse to say, and your list of what did not work. That is the asset. The model is a commodity that gets replaced every few months, and the context does not.

Which is also why this is the first thing to build and not the fifth. Everything downstream of it is better or worse depending entirely on whether it exists.

Frequently asked

What should I automate with AI first? A context brain, not a task. It is one structured place holding your positioning, voice, real customer language and past decisions, and every later system reads from it.

Why does AI give me generic answers? Usually because it has no context beyond your prompt. A well-written prompt with no context still produces something that could have been written for any business in your category.

How long does it take to build a context brain? The first version takes about thirty minutes. It gets more useful over the following weeks as you add real decisions and real customer language.

What should not go into an AI context document? Brand boilerplate. About pages, mission statements and marketing decks have been edited until they say nothing specific, which is the opposite of what you need.

Do I need technical skills to build one? No. It is documents and written instructions. The skill in use is specification, which is a management skill rather than an engineering one.

Should I automate the task I hate most? Not first. The task you resent usually has the most exceptions and requires the most unwritten knowledge, so it is the worst possible test of a system that does not know anything about you yet.

Frequently Asked Questions

What should I automate with AI first?
A context brain, not a task. It is one structured place holding your positioning, voice, real customer language and past decisions, and every later system reads from it.
Why does AI give me generic answers?
Usually because it has no context beyond your prompt. A well-written prompt with no context still produces something that could have been written for any business in your category.
How long does it take to build a context brain?
The first version takes about thirty minutes. It gets more useful over the following weeks as you add real decisions and real customer language.
What should not go into an AI context document?
Brand boilerplate. About pages, mission statements and marketing decks have been edited until they say nothing specific, which is the opposite of what you need.
Do I need technical skills to build one?
No. It is documents and written instructions. The skill in use is specification, which is a management skill rather than an engineering one.
Should I automate the task I hate most?
Not first. The task you resent usually has the most exceptions and requires the most unwritten knowledge, so it is the worst possible test of a system that does not know anything about you yet.
Build With AI Club

Ready to build with AI?

Join as a Pro Fellow -- live sessions 4 times a week, five structured paths, and a full playbook library.

Apply to be a Fellow →