Field Notes
Prompt Engineering was about turning a vague request into a clear job.
The Prompt Before the Prompt was about letting AI interview you before it writes the final prompt.
That sequence matters.
Prompting helps you describe the work.
Meta-prompting helps you discover the missing shape of the work.
Context engineering makes the work easier to repeat.
The better your context is engineered, the less pressure you have to put on every single prompt.
Prompting still matters. It may always matter. But the goal is not to become a person who can write a 900-word instruction every time you need help.
The goal is to build a system where the instruction, the sources, the examples, the rules, and the memory are already in the room.
Think about a restaurant kitchen.
You can hire a world-class chef.
Put them in a kitchen during dinner service.
Then hide the labels on half the ingredients.
Leave yesterday's menu on the counter.
Scatter the tickets across three printers.
Keep allergy notes in the owner's head.
Mix the clean knives with the dirty ones.
Give no one the authority to say which order is next.
That chef may still be talented.
Dinner is going to be a mess.
The chef did not forget how to cook. The kitchen cannot support dinner service.
That is what happens when we ask AI to operate inside a business with scattered context.
The model may be strong.
The prompt may be solid.
The interview may pull better questions.
But if the answers live in your head, an old email, a call transcript, a half-updated CRM note, a Drive folder, and one decision nobody wrote down, the model is working in a bad kitchen.
It can still produce something polished.
Polished is not the same as prepared.
Context engineering sets up the station.
It labels ingredients, keeps the current menu visible, puts tickets in order, marks allergies, and separates yesterday's prep from today's service.
It gives the chef the room, tools, and rules needed to do good work under pressure.
This is why prompts and skills are connected.
In the beginning, you prompt your way toward clarity. You ask the model to interview you. You answer the questions. You find the edge cases. You decide where the stop signs are.
Then you codify that.
The prompt becomes an instruction. The instruction becomes a reusable skill. The skill carries the right context, source hierarchy, examples, boundaries, and receipts.
Now the experience gets easier over time.
You can talk to the model more like a person because the system already knows the room it is standing in.
You do not have to explain the whole business every time.
You can say, "draft the follow-up," and the agent knows which project note to read, which client promise is current, what tone belongs here, what needs approval, and what proof it owes you.
That is the real upgrade.
Context engineering is about giving the model the right information, arranged in a way that makes the work legible.
This is why serious agent builders keep circling back to context. Anthropic has a useful piece on effective context engineering for AI agents. Dex Horthy's 12-Factor Agents frames one version as owning the context window. Anthropic's Building Effective Agents makes the same practical point: reliable systems come from clear patterns, not magic.
For operators, the plain-English version is simple: stop asking the chef to remember the entire restaurant. Build the kitchen.
Playbook
The practical version is mise en place.
Before dinner service starts, the station gets set: ingredients prepped, tools in reach, menu clear, tickets on the rail, house rules understood.
Do that for AI.
1. Label the ingredients
A transcript is source material. A meeting summary is interpretation. A signed agreement is source material. Your takeaways are interpretation. A client email is source material. Your plan for responding is interpretation.
AI gets messy when those layers blur.
If the model cannot tell the difference between the raw receipt and your current working opinion, it may treat both as equally true.
That is how old notes come back from the dead.
Raw transcripts go in one place. Decisions go in another. Current project state has its own page. People notes carry the relationship context. Workflow notes explain how the work moves. Examples show what good output looks like.
Then the instruction can be lighter:
"Use the source material, but follow the current decision record if anything conflicts."
That one sentence can save you from a lot of polished nonsense.
2. Put active tickets on the rail
A kitchen runs on active tickets.
The chef needs to know what is open, what is handled, what is urgent, and what order matters.
Businesses need the same thing.
Every serious project should have a current-state note:
- what is true now,
- what decision was made,
- what is open,
- who owns the next move,
- which source is current,
- and what would make the work unsafe to continue.
That page does not need to be fancy.
It needs to be current.
The model can read a hundred documents and still miss the point if none say what matters now.
3. Write the house rules
One of the easiest upgrades is a README.
Every important folder, project, or workspace should explain itself.
What belongs here? Which files are receipts? Which files are current state? Which examples shape the output? Who needs review? What is stale? What is next?
That README becomes the sign on the kitchen wall.
The model does not have to infer the rules from a pile of documents.
That is why I like the company brain idea. Obsidian, Notion, a repo, Drive, a database, or something custom can all work. The tool matters less than the principle: agents need a structured context layer they can read, reference, and respect.
If your context only works when you personally remember where everything is, you have built storage.
You have not built context yet.
4. Keep taste files
AI learns the job faster when it can see what good looks like.
Keep the email that sounded right, the report that landed well, the owner update that translated numbers into meaning, and the support reply that solved the problem without creating a new one.
Then keep the misses: the stiff draft, the overpromised response, the summary that skipped the decision, and the automation that moved too fast.
Examples are context.
Counterexamples are also context.
They give the model taste and boundaries.
Without examples, the model has to average the internet. You do not want that voice running your business.
5. Decide which source wins
Conflicts are guaranteed. The CRM says one thing. The call transcript says another. The email thread has the latest promise. The old SOP says something stale.
If you do not define the hierarchy, the model chooses for you.
That is a bad handoff.
Write the hierarchy down.
For example:
- signed agreements beat notes,
- current project status beats old meeting summaries,
- direct client emails beat internal guesses,
- today's decision record beats last month's plan,
- and missing information should trigger a stop, not a confident assumption.
Context engineering gives the model more information and clearer rules for using it.
It also tells the model what to do when the information is incomplete.
6. Make proof part of the service
Ask which source it used, which file it changed, which call it drafted from, what evidence supports the recommendation, and what it could not verify.
Receipts turn AI work into auditable work.
And auditable work is the only kind I trust at scale.
No external messages without approval. No pricing changes without human review. No invented financial numbers. No treating unverified names as confirmed contacts. No continuing when the sources conflict.
Those rules need to be built into the station.
The agent should know what proof to bring back and when to stop the line.
Orientation
A company brain is more than a prettier archive.
The goal is to make your business legible to agents.
That is a different standard.
An archive stores information.
A context layer explains how information should be used.
It tells the model what matters, what changed, what source wins, what good looks like, what risky looks like, what proof is required, and when to stop.
Once that exists, the prompt gets lighter.
You do not have to paste the entire business into every chat.
You can point the agent at the room: read the README, use the current status note, check the source receipts, follow the decision record, draft the output, bring back citations, and bring me the conflict if the sources disagree.
That is the beginning of operating lift.
The operator is no longer carrying the whole company in their head.
The company starts carrying its own context.
Then the agent can work inside it.
If AI keeps guessing, inspect the kitchen before blaming the chef.
The next engineering layer is the operating wrapper: the instructions, permissions, tools, memory, and review gates that decide what the agent is allowed to do once it understands the room.