A working map
AI Engineering
When people say they want to use AI, they often start with the model. Which one is smartest or fastest? Which one has the biggest context window? Those are reasonable questions, but not yet an engineering plan.
In application-layer AI engineering, you generally do not train the model. Fine-tuning and self-hosting exist, but this essay is about building on rented, frozen models. A model provider has already done that work with enormous collections of data, computation and evaluation. You engineer around the model. You decide what task it receives, what evidence it can see, which actions it can take, how it repeats a task, and how someone can tell whether it is done.
Think of this essay as a map of those parts. The boundaries overlap. A prompt can be part of context. A tool can sit inside an agentic loop. A harness can contain all of them. The names let you point to a failure and repair the right layer instead of asking one vague question about “the AI”.
Before you continue, explain this back: if you do not train the model, what are you responsible for engineering? Then give any chat AI a task you know well and ask it to produce a result. Keep that first attempt. You will use it as your baseline.
The capability
A model is a capable engine
Imagine an engine on a workbench. It can turn fuel into motion, but it does not know whether you want to move a bicycle, a boat or a generator. The engine supplies power. The surrounding machine gives that power a useful direction.
A model is the learned system that turns input into output. For a language model, that output might be text, code, a classification, a proposed tool call or a structured object. Training gives it broad patterns and capabilities. It does not give it your current project, your definition of success or authority to change your systems.
This distinction is useful because model quality sets a ceiling, but it does not determine every result below it. A strong model with poor evidence can produce a weak answer. A smaller model with a narrow task, clear examples and a reliable check can be the better fit. Capability, cost, speed, reliability and risk all belong in the choice. The related essay Rent the capability. Retain the learning. follows what remains around the model.
Explain it back and try it: tell someone why a model is like an engine rather than a complete machine. Give your baseline task to two available chat models with the same wording. Compare the results, then write down one difference caused by capability and one difference that could be fixed by better instructions or evidence.
The model proposes; your system gives direction
Model capability is one input to useful work. The surrounding design supplies purpose, evidence and limits.
Inside the model
- Learned patterns Language, code and other relationships from training.
- Generated proposal An answer or action suggestion, not proof of completion.
useful work
Around the model
- Task definition What this run is meant to accomplish.
- Evidence and checks What it may use and how the result is judged.
The request
A prompt gives the engine a job
Picture a note handed to a colleague before they start work. “Deal with this” leaves too much in their head. “Compare these two invoices, list every difference, and mark anything that needs approval” gives them a job, an object and a useful shape for the result.
A prompt is the instruction and input for one model interaction. It can state the task, audience, constraints, sources and desired output. Good prompting is not a spell. It is the discipline of making intent visible. Say what done looks like. Name what must not happen. Give the model enough information to distinguish a careful answer from a fluent one.
Prompting still matters, even as more of its useful structure moves into standing instructions, tool contracts and evaluation. The deeper treatment is in Prompt engineering got absorbed. Here, keep the working rule simple: if a person could reasonably interpret your request in two ways, a model probably can too.
Explain it back and try it: describe a prompt as a job brief, not a magic phrase. Ask a chat AI to perform your baseline task again, first with only the original request, then with three additions: what done looks like, what evidence to use, and what uncertainty to flag. Compare the outputs. Circle the instruction that changed the result most.
The available desk
A context window is a desk with limited room
Imagine doing research at a desk that only holds so many papers. You can bring the whole filing cabinet into the room only in theory. In practice, you need to choose what sits open in front of you, what goes underneath, and what stays in the cabinet until needed.
A context window is the maximum token budget for one exchange, covering both the input sent to a model and the output it generates. It may include your instructions, the conversation, documents, images, tool results and other state. The window creates capacity. It does not guarantee equal attention to every item inside it, nor does it guarantee that a relevant fact will be used correctly.
This is why “the model can accept a million tokens” is not the same as “the model can reliably reason over every one of them”. Old instructions can compete with new ones. Sources can conflict. A long conversation can bury an important decision. A large window gives you more room, but you still need to arrange the desk.
When a long session becomes fluent but less dependable, you may be approaching what the context window is capacity, not a quality guarantee calls the dumbzone. That is a diagnostic label, not a universal token count. Compare a focused version of the task with the long version and see what changed.
Explain it back and try it: explain why a desk analogy separates capacity from attention. Give your baseline task once with a short, carefully selected context and once with a large folder of related material. Ask the model to list which sources it used. Compare accuracy, omissions and confidence, not only writing quality.
Choosing what matters
Context engineering decides what reaches the desk
If the window is the desk, context engineering is preparing the desk before the work begins. You remove yesterday's receipts, put the current specification near your hand, label the approved source, and keep the rest of the filing cabinet available without spreading it across every square inch.
Context engineering is the deliberate selection, ordering and maintenance of the material given to a model for a task. This can include instructions, source documents, examples, prior decisions, retrieved records and tool results. Its central question is not “How much can I fit?” It is “What deserves attention for this decision now?”
Use four filters. Is the material relevant? Is it fresh enough? Is it authoritative, meaning that someone owns or approved it? Is it close to the decision, rather than merely about the same broad subject? The essay Context engineering: what belongs in the window develops this method further. Notice that context is an active design choice.
Suppose you ask for a forecast explanation. The current finance memo and approved pricing policy belong near the task. A three year old presentation might belong only for comparison. A random discussion thread may add words without evidence. Leaving something out can be a quality decision.
Explain it back and try it: name the four filters in your own words. Collect five documents about your baseline task. Give the model all five, then give it only the two you judge most relevant, fresh, authoritative and close to the decision. Ask it what changed. Keep the smaller set if it produces a more checkable result.
The available actions
Tools let the model do more than describe
Think of a colleague who can read a timetable but cannot open the booking system. They can tell you what train might work. They cannot reserve a seat. A tool is the permissioned bridge between a model's proposed action and an outside system.
A tool is a defined operation that a model can request, such as searching a knowledge base, reading a file, calculating a value, creating a ticket or calling an API. The model normally chooses arguments for the operation. The tool implementation decides what is valid, what access is allowed and what result comes back. That boundary matters. A model can suggest a transfer, but the payment system must still validate the account, amount and authority.
Tool design is therefore part of safety and clarity. Give a tool a narrow purpose. Make required fields explicit. Return useful errors. Limit permissions. Log meaningful actions. Treat tool output as new context that can be stale or incomplete. A tool does not turn a guess into a fact. It gives the system a way to check, retrieve or change something under rules.
Explain it back and try it: explain why a tool is a controlled operation, not a superpower. Ask a chat AI to complete your baseline task, first without any external access and then with one tool you already have, such as file search or a calculator. Compare what the tool lets it verify. List one action that should require a human approval before it runs.
Work over several moves
An agentic loop turns one answer into a sequence of actions
Imagine a student solving a problem at a whiteboard. They inspect what is known, choose a next step, do that step, look at the result, and decide whether to continue. They do not write one paragraph and hope the whole problem solved itself.
An agentic loop is a repeated cycle in which a model observes available state, chooses an action, takes that action through a tool or other interface, evaluates the result, and either stops or continues. The model may plan, but the loop is the important idea. Work changes the state, and the next decision uses that changed state.
The essay Agentic structure goes deeper on controlled action. The short version diagnoses weak agents. Without a stop condition, the loop can wander. Without evaluation, it can repeat a bad approach. Broad tool authority can let a plausible plan create an expensive or irreversible outcome.
Start with one small loop. Read a task file, propose a change, run one check, inspect the result, and stop when the check passes or a human must decide. More steps are not automatically smarter. Each step should earn its place by reducing uncertainty or producing evidence.
Explain it back and try it: say the loop in five verbs: observe, choose, act, evaluate, stop or continue. Ask a chat AI to solve a small research task in two ways. First request its final answer immediately. Then ask it to show a short plan, identify one source, check its answer against that source, and report what remains uncertain. Compare reliability and effort.
The working environment
A harness is scaffolding around the crane
Picture a crane on a building site. The crane supplies lifting power, but the scaffolding, barriers, signals, load limits and inspection points make that power usable around people. Remove the surrounding structure and a stronger crane does not become a responsible construction method.
A harness is the system around a model that assembles context, exposes tools, manages permissions, records state, applies checks and provides stopping points. It may be a small script, chat workflow or substantial product. Size is not the definition. Coordination is.
The harness engineering essay covers how repeated failures should earn durable layers. Use that idea here: add a checkpoint because an unverified result escaped, add a permission boundary because an action was too broad, add memory because a decision keeps being forgotten. A harness should preserve responsibility, not hide it behind automation.
A useful harness answers simple questions. What is the goal? What may the model see? What may it do? What evidence says the work is complete? Who handles an exception? Can the action be reversed? If you cannot answer these, adding another model call will probably increase activity without increasing control.
Explain it back and try it: explain why the harness is around the crane, not inside the crane. Take your baseline task and write five lines: goal, allowed evidence, allowed action, completion check, human decision. Run the task again using those lines as a tiny manual harness. Note which line prevented confusion.
Delegation inside the work
Subagents split work without splitting ownership
Imagine a teacher assigning a research group three bounded jobs. One student finds sources, one compares them, and one checks the draft. The teacher still owns the final submission. More people can create progress, but only if everyone knows their part and someone checks how the parts fit.
A subagent is a separate model run delegated a bounded piece of a larger task. It should receive the context needed for that piece, a clear output contract, limited authority and a stopping condition. The parent workflow then decides whether the returned work is useful. Delegation does not transfer accountability.
Subagents are helpful when work can separate cleanly: inspect these files, gather these sources, generate these alternatives, or test this narrow claim. They are less helpful when every part depends on the same unresolved decision. In that case, parallel activity can create conflicting assumptions and make integration harder.
Give each subagent a boundary. State what it must not decide. Ask for evidence with the result, not only a conclusion. Let one owner reconcile conflicts. If one edits a shared resource while another works, the group may resolve collisions instead of making progress. Isolation is often more valuable than raw concurrency.
Explain it back and try it: explain why delegation does not transfer ownership. Ask one chat AI to act as a researcher and return three sourced findings. Ask a second to act as a critic and identify unsupported claims. You remain the owner. Compare their outputs, resolve one disagreement yourself, and write the rule that would have prevented it.
Remember the map as a chain. The model supplies capability. The prompt names the job. The context window sets the room. Context engineering chooses what reaches it. Tools connect proposals to controlled actions. An agentic loop repeats action and evaluation. The harness coordinates the environment. Subagents divide bounded work while a human keeps ownership.
Do not build all of this at once. Build a tiny loop this week. Pick a task you repeat, write what done looks like, provide only needed evidence, give it a safe action, and add one check before you call it complete. Then explain the result. If the loop helps, keep the lesson. If it fails, repair the smallest layer that caused the failure.