M.L. Sebastian is now br8n.

Context Engineering

Context engineering for a small business

Prompting is how you ask. Context engineering is what the tool already knows about your business when you ask. Most of it fits in five short files.

The discipline

Write down what the business knows.

Context engineering is the practice of writing down what your business knows — how the work gets done, what has been decided, where the exceptions are — so an AI tool can read it before it answers. Prompting shapes one request. Context engineering shapes what every request stands on.

When that material exists, ordinary language produces informed work, because the tool starts from your reality instead of a general one.

A strong model over thin context still guesses. The context is what changes the answer.

The full answer

What is context engineering in plain terms?

Here is the complaint it answers: the AI doesn’t understand the context of what I’m doing. The answers are fluent, general, and wrong in the specific ways your business is specific. So people re-explain — the client, the pricing, the history — every single session, from scratch.

Context engineering fixes that by moving the explanation out of your typing and into files. You write down, once, the things you keep saying: how the work gets done here, what was already decided, which clients are special cases. The tool reads those files at the start of the work. From then on it answers like someone who has been at the company for a while, not someone who walked in this morning.

The observation this page rests on: most AI disappointment in a small business is missing written context, not a weak model. The models are already capable. What they are missing is what only you can write.

What files does an AI actually need about a business?

Five, to start. Each is a page or two of plain text, written by someone who knows the business, updated when reality changes.

FileWhat it holdsOne worked example
how-we-workThe way things actually get done: approvals, standards, what finished looks like.“Every proposal is reviewed by Dana before it leaves. We never quote a price on the first call.”
decisionsCalls already made, with the reasoning, so they stay made.“March 2026: we stopped offering rush delivery. The margin data showed it lost money at any price.”
exceptionsWhere the rules bend, and for whom.“The Hendersons stay on 2024 pricing until their contract renews — agreed by phone, honored in writing.”
handoffsWhat the next person needs to pick up a job cleanly.“A closed sale hands to operations with the signed scope, the promised date, and any nonstandard terms flagged.”
voiceHow the business sounds when it writes.“Plain sentences. Prices stated up front. No exclamation marks, no manufactured deadlines.”

Notice what is not on the list: your whole document archive. Dumping everything into an AI tool buries the five files that matter under a thousand that don’t. The craft is selection — writing down the load-bearing knowledge and leaving the rest in the filing cabinet where it belongs.

How is this different from prompt engineering?

Prompt engineering improves one request. Context engineering improves every request, because it changes what the tool knows before any request arrives. A well-crafted prompt over empty context produces a confident, articulate guess.

There is a second difference people feel before they can name it. Without your decisions written down, an AI tool is a yes-man: it agrees with everything, because it has nothing of yours to check a new idea against. Give it your decisions and exceptions and it can finally push back — poke holes in a plan that contradicts a call you made in March, or flag that the discount you are about to offer breaks your own pricing rule. The file is what gives it permission, and material, to call you out.

Prompts are still worth writing well. They just cannot carry knowledge they were never given. Why sessions lose that knowledge in the first place is covered in why AI forgets.

How do we start this week?

Start with one file, not five. Pick the question your team answers most often — for most businesses it is some version of how do we handle X — and write the one page that answers it. That is usually the how-we-work file.

Then run the comparison. Ask your AI tool a real question from this week’s work without the file, then again with the file loaded. The difference is the argument, and it is usually visible on the first try. Add one file a week after that: decisions next, then exceptions. Five weeks in, the tool has stopped guessing about your business.

Keep every file in plain text you own, not inside any one product’s memory — that keeps the work portable across models and vendors, which is the same principle behind a personal AI brain. And if the honest problem is that nobody can name what is missing, that mapping is a bounded job with a fixed price: the Working Intelligence Audit.

The three layers

Know. Remember. Reach.

  1. Retrieval

    Pull the right source

    Find the current contract, decision, project history, or operating rule at the moment of work.

  2. Memory

    Carry state forward

    Keep decisions, client history, and project state available after a chat session ends.

  3. Governance

    Bound the reach

    Write down which roles, sources, vendors, and actions are allowed, then log what happens.

Prompting vs. context

One improves an ask. One improves the system.

ComparePrompt engineeringContext engineering
ScopeOne requestEvery request
ShapesHow you askWhat the tool knows before you ask
Lives inA person’s phrasingFiles the business owns
AccumulatesA prompt libraryDecisions, exceptions, and how the work gets done

At org scale

The context belongs to the operation.

The company owns the knowledge, the obligations, and the decisions about access. An outside builder can create the layers and transfer them. That is the context work inside an AI capability installation.

  • Sources are selected instead of dumped in wholesale.
  • Memory has an owner and a maintenance rhythm.
  • Access and exclusions are agreed before data moves.

Find the thin layer

Make the next answer stand on something real.

The audit maps where your knowledge lives, what repeats, and which file to write first. You keep the map either way.

FAQs

What is context engineering?

The practice of writing down what your business knows — how the work gets done, what has been decided, where the exceptions are — so an AI tool can read it before it answers. Prompting decides how you ask. Context engineering decides what the tool is standing on when you ask.

What files does an AI actually need about a business?

Five short files cover most of it: how-we-work (the way things actually get done), decisions (what was chosen and why), exceptions (where the rules bend), handoffs (what the next person needs), and voice (how the business sounds). Each is a page or two of plain text.

How is context engineering different from prompt engineering?

Prompt engineering tunes the wording of a single request. Context engineering builds the standing material underneath every request: the files the tool can read, the memory that carries across sessions, and the rules about what it may touch. A good prompt over empty context still produces a confident guess.

How do we start context engineering this week?

Pick the question your team answers most often and write the one-page file that would answer it: usually how-we-work or decisions. Load that file into your AI tool at the start of a session and compare the answers. Add one file a week; five weeks in, the tool stops guessing.

Is RAG the same thing as context engineering?

Retrieval-augmented generation is one layer of the discipline. RAG answers what documents the system can pull in right now. Context engineering also covers memory, which persists between sessions, and governance, which controls who and what the system may reach.

How do you keep sensitive data out of the context?

Set boundaries before anything moves: which sources enter the files, which roles can read what, which vendors process which data under which agreement, and what the audit trail records. Exclusion is a design decision made in writing ahead of time.

Do bigger context windows make context engineering unnecessary?

No. A larger window changes how much you can load per request. It does not decide what should be loaded, what persists after the session ends, or what the system is permitted to reach. Selection and ownership still matter as windows grow.

Can't find what you're looking for? Talk with us