“Please fix the approval workflow” sounds like a clear instruction until an AI has to choose between two documents. One says managers may approve orders up to 50,000 baht. An older example uses a different limit. Which one should it follow, and how would it know that a sample file is not the policy?
In our hypothetical purchase-order project, the hard part is no longer getting an agent to start editing. It is giving it the right basis for a decision. More documents can make the answer worse if their authority, purpose, or age is unclear. A short prompt can fail for the opposite reason: it omits the rule that makes the requested change meaningful.
Context engineering means selecting and organizing the information an agent needs to work. That includes instructions, reference material, examples, current state, tools, and limits. The goal is a usable basis for action, not the shortest possible prompt or the largest possible collection of files.
Start with who owns the rule
Our example continues to use a hypothetical final order total in baht after discounts and tax. Up to 50,000 baht follows the department-manager route; an amount above that follows the purchasing-director route. An edit to the total invalidates the previous approval. These are invented business rules, not Odoo defaults or a recommendation for every organization.
I would put the approved rule in one named document with an owner and a version. A worked example should point to that rule, rather than quietly becoming a second authority. If an agent finds a conflicting example, its task is to report the conflict. Guessing which document “looks newer” is a poor substitute for an identified owner.
A useful assignment might say: “Change the approval-route calculation to match policy version P1. Use synthetic test data only. Do not change live records, permissions, or the policy. If P1 does not settle a case, stop and identify the missing decision.” That is specific enough to expose uncertainty without describing every line of implementation.
Approved policy P1
Its owner and version are identified
Use it as the authority for this task
An older conflicting example
Shows a past approach, not current policy
Report the conflict; do not adopt its rule
If authority is still unresolved, stop and ask the policy owner to decide.
Separate standing rules from the task packet
Some information matters whenever an agent works on the project: where the code lives, which checks are required, what it must not change, and who reviews the result. Other information matters only for this assignment, such as the approval policy and the files implementing the route calculation. Keeping these layers separate makes it easier to review both.
The source figure separates persistent context from information retrieved for a task. Core rules need to be available; task documents need version and authority checks. Retrieval on demand does not guarantee lower total cost. This is a conceptual arrangement: making rules available does not guarantee that an agent will remember or follow them. Actual behavior still needs checking.
Figure reproduced from The New SDLC With Vibe Coding, Addy Osmani, Shubham Saboo, and Sokratis Kartakis (May 2026). Document design: Michael Lanning. Figure reuse offered by Addy Osmani. Source and reuse permission · Full public paper
An AGENTS.md file is one convention for project instructions. Other tools use other conventions. The filename itself does not enforce a permission boundary. A clear rule file helps an agent understand the work; the surrounding system must still enforce access limits. We will examine that distinction in the next article.
| Layer | Content | Who maintains it |
|---|---|---|
| Standing instructions | Project layout, mandatory checks, no live writes, review route | Project maintainer |
| Authoritative rule | Approved policy P1 and unresolved questions | Business process owner |
| Task evidence | Relevant code, synthetic orders, expected results | Assigned developer and reviewer |
| Current state | Changes already made, failed checks, next decision | The person or agent handing off the work |
I would keep the standing instructions brief enough to inspect, but would not remove a necessary constraint to hit an arbitrary length. If a rule governs money, permissions, or irreversible actions, it needs to be available when the relevant decision occurs. Material loaded later also needs a way to be found reliably.
Retrieve what the task needs, then check what arrived
Instead of attaching every purchasing document, give the agent a map: where the approved policy is, where route calculation happens, and where reviewed tests live. Let it retrieve the relevant material as the work develops. This can reduce irrelevant information, but retrieval is not automatically correct. A search result can be incomplete, stale, or from the wrong module.
For the approval change, I would ask the agent to state which policy version it read and which code path it believes applies before editing. If it only found a screen label but not the server calculation, that gap should be visible immediately. A concise understanding of the task is useful evidence that the right material was found.
Skills can package a repeatable procedure, such as checking an approval change: locate the authoritative rule, inspect the current implementation, build boundary cases, run the relevant checks, and report differences. They should include when the procedure applies and when to stop. A large skills library is not useful if several procedures disagree or nobody maintains them.
Concepts informed by The New SDLC With Vibe Coding, Addy Osmani, Shubham Saboo and Sokratis Kartakis (May 2026). Author’s article · Full public paper
Leave a handoff that another session can use
Long conversations accumulate decisions, experiments, and abandoned ideas. If we simply preserve everything, the next person or agent must work out which statements still hold. I would maintain a short handoff record: the current goal, approved decisions, changed files, checks performed, unresolved issues, and the next action.
Suppose the boundary tests pass but the organization has not decided what happens when an approver loses their role while an order is pending. The handoff should say that the role-change question remains open. It should not compress the work into “approval workflow complete.” Memory is useful only if it preserves uncertainty as well as progress.
Do not paste secrets, unnecessary personal data, or whole transaction histories into a task packet merely because they are convenient. Synthetic orders can explain a routing rule without exposing a supplier's bank details. The right context includes enough to do the job and respects the data boundary chosen for it.
Before the next agent run, I would check four things in the packet: the rule's owner, the source of authority, the allowed scope, and the evidence expected at handoff. If a conflict cannot be resolved from those materials, the agent should ask for a decision rather than invent one.
Choose one repeatable task and prepare its packet before writing a longer prompt. Which document settles a disagreement? Which example demonstrates the rule? What should the agent do when the two conflict? Those answers usually matter more than polishing the wording of the request.
Reading and scope
The context categories and standing-versus-dynamic distinction build on The New SDLC With Vibe Coding by Addy Osmani, Shubham Saboo, and Sokratis Kartakis, May 2026. Anthropic's Effective context engineering for AI agents provides a primary technical discussion of selecting relevant information and retrieving it as needed. The purchase-order packet, policy P1, amounts, and ownership choices here are original hypothetical examples. They do not demonstrate measured cost savings or prescribe a specific tool.