Joe Cook

Systems libraryKnowledge Architecture

Why Your AI Assistant Needs More Than a Good Prompt

A clever prompt helps once. Context that persists, written instructions, and repeatable workflows help every time, even for people who have never learned to write a prompt.

Joe Cook,

A lot of AI advice is about prompts. Use this phrasing, add that role, ask it to think step by step. Some of it works. But a prompt lives for one conversation, and most of the work I care about happens over months.

Think about what a good new employee needs in their first week. Nobody hands them a single brilliant paragraph and expects great work. They get background on the company, examples of past work, the house style, and someone who tells them which mistakes are expensive. Then they learn the routines that repeat every week.

An AI assistant needs the same things, and most people never give them to it.

What the model actually receives: reference knowledge, standing instructions, and a task workflow are added automatically above the short request the person types. Reference knowledgeProducts, customers, past work, preferences Standing instructionsVoice, rules, what never to invent Task workflowSteps, inputs, checks, format The request“Write Friday’s report.” Addedautomatically Typed bythe person What reaches the model is mostly context the person never had to type.

Context that persists

The first thing I’d write down is reference material the assistant should work from. Product information, past proposals, the way your customers actually make decisions, your preferences about format and length. Once it’s written, every conversation starts from it instead of from nothing.

The catch is upkeep. Reference material goes stale, and an assistant working from an outdated price list or an old org chart will be confidently wrong. Someone has to own the files.

Instructions that hold

The second thing is standing instructions. How should the assistant write? When should it push back? What should it never invent? I keep mine as versioned files with a clear order of authority, because instructions will eventually conflict. When they do, facts and safety win, my current request comes next, and style preferences come much later.

Writing this down forces a useful kind of honesty. You find out quickly which of your preferences you can actually describe and which ones you’ve only been reacting to.

Workflows that repeat

The third thing is the procedure for recurring work. If you write the same weekly report every Friday, the steps, inputs, and checks should be the same every Friday. A good prompt might produce a good report once. A written workflow produces a good report on a tired week, too.

The onboarding ramp

When I build a knowledge base for an organization, I think of it as an onboarding ramp. It starts broad at the top and gets more specific at every level until it reaches the actual request someone types on a Tuesday afternoon.

The top of the ramp covers what’s true for everyone: what the organization does, who it serves, the standards it holds, the words it uses. Below that sits each department’s procedures and systems. Below that, each role: what this person is responsible for, which decisions are theirs, how they should sound. At the bottom is the task itself, with its inputs, steps, checks, and the format the finished work has to take.

The onboarding ramp. Organization, department, role, and task levels step down in increasing detail to the request. Every level above is injected into the request automatically. OrganizationMission, customers, standards, glossary DepartmentProcedures, systems, approvals RoleResponsibilities, decisions, voice TaskInputs, steps, checks, format RequestOne plain sentence from anyone Injected into every request Built once by people who know the work. Used every day by people who don’t need to.

The point of all that granularity is who it serves. The goal is a ramp detailed enough that the newest person on the team, someone who has never read a word about prompt writing and doesn’t care to, can type “Write Friday’s territory report” and get work an experienced person would sign. Everything they don’t know how to ask for is already sitting in the levels above them, and the system adds it to their request automatically.

That changes who has to understand AI. The people who know the work well build the ramp once, carefully. Everyone else just uses it. Nobody downstream has to learn first principles of prompt construction, because the instructions they would have needed are written into the ramp at the level where they belong.

Here’s the test I use. If a new hire has to know how to prompt to get good results, the ramp isn’t deep enough yet. Find the place where they had to explain something the system should already know, and write it down one level up.

Where people still come in

None of this removes the need for review. The system makes the first draft better and more consistent. A person still decides whether it’s right, especially when the work is technical or the consequences are real.

What matters is where the corrections go. When review catches a problem, the fix shouldn’t live in one person’s memory or one conversation. It goes back into the ramp, at the level where it belongs, so the next person never sees it.

The improvement loop. A request is combined with context from the ramp, produces a draft, and goes through human review. Corrections are written back into the ramp at the right level. Requestone sentence Rampadds context Draftfrom the model Reviewby a person Corrections are written back into the ramp Each fix happens once, at the right level, and every later request benefits.

That’s the real shift. You stop treating each conversation as a fresh request and start treating the assistant as something you train, document, and maintain. It’s slower on day one and much faster by day thirty.

Talk with me about building something like this