lock_openFree samplePrompt and Context Engineeringmedium
Field technicians ask an assistant equipment questions by pasting entire maintenance manuals into the session before typing the question. The manual set runs to thousands of pages, answers must quote the wording of the procedure step they came from, and finance has set a cost ceiling per question that the current build exceeds. The manuals are revised a few times a year. Select TWO changes that fit the stated constraints.
- AIndex the manuals in a searchable store and expose a retrieval tool, so a question pulls in the passages it needs rather than the technician pasting whole manuals ahead of it.check_circle Correct
- BCap what the retrieval tool returns for one question, returning a bounded set of passages carrying their procedure step identifiers rather than whole chapters of a manual.check_circle Correct
- CKeep the paste and rely on compaction to summarise the manual text once the conversation grows long, so that the request stays inside the available working context.
- DKeep the paste and dispatch one subagent per manual, having each subagent return its own paraphrased account of the relevant procedure to the main conversation.
- EKeep the paste and reduce the number of manuals a technician may attach to one session, asking them to judge in advance which manual the question is likely to concern.
Large reference material belongs behind a retrieval tool with a bounded result, rather than pasted into the context ahead of the question. Pasting a corpus pays for every page on every question and crowds the working context, while the question needs a handful of procedure steps. Retrieving bounded passages at question time sends only what the answer depends on, and returning each passage with its step identifier preserves the exact wording the quoting requirement demands.
Why A is correct: Correct. Retrieval replaces the paste with a fetch at question time, so the request carries the relevant passages and cost per question falls with the volume of text sent.
Why B is correct: Correct. Unbounded retrieval reintroduces the bloat it was meant to remove, and returning the step identifier alongside the passage keeps the quoting requirement satisfiable.
Why C is wrong: Tempting because compaction reclaims room, but a summary loses the exact procedure wording the answers must quote, and the full manual is still paid for on the way in.
Why D is wrong: Tempting because isolation keeps the main context small, but every manual is still read in full at cost, and a paraphrase cannot carry the exact wording that must be quoted.
Why E is wrong: Tempting because it does lower the text sent, but it shifts the lookup onto the technician and still carries whole manuals for a question that needs a few steps.
lock_openFree samplePrompt and Context Engineeringmedium
A contract analysis service builds each request by writing a short instruction that names the required output fields, then appending roughly sixty pages of retrieved clause text beneath it. Reviewers measure that 12 per cent of replies omit one of the required fields or answer in prose, and the omissions cluster on the longest requests. The clause text cannot be shortened and the field list must stay the same. Which change addresses the measured failure?
- ARaise the output ceiling on every request, since the omitted fields indicate the reply is being cut short before the later fields can be written.
- BSplit the clause text across several requests of a few pages each and combine the replies, accepting the extra calls as the price of shorter requests.
- CRestate the required output fields in a short block placed after the clause text, immediately before the model is asked to answer, so the instruction is not separated from the answer by the bulk of the material.check_circle Correct
- DMove the field list into the system prompt and leave the clause text as the only user content, relying on the system role to carry more weight than a user instruction.
Place or repeat the operative instruction next to the point of answering when a large body of reference material would otherwise bury it. When an instruction is followed by tens of thousands of tokens of reference text, the material nearest the end of the request dominates what the model attends to when it starts generating. Restating the field list after the bulk keeps the instruction adjacent to the answer, which is why the fix costs a few tokens rather than a redesign.
Why A is wrong: Tempting because a truncated reply also loses trailing content, but truncation ends mid sentence and is reported by the response, whereas these replies finish cleanly and simply ignore part of the instruction.
Why B is wrong: Tempting because smaller requests do reduce competition for attention, but the analysis needs the whole contract in view to answer, and splitting it multiplies cost while introducing reconciliation the service does not currently have to do.
Why C is correct: Correct: an instruction buried far above a large body of reference text competes with everything that follows it, and repeating it adjacent to the point of answering restores its salience at negligible token cost.
Why D is wrong: Tempting because durable rules do belong in the system prompt, but position relative to the bulk of the material is what is failing here, and a system prompt sits even further above the clause text than the current instruction does.
lock_openFree samplePrompt and Context Engineeringmedium
A triage assistant misclassifies about 12 per cent of tickets, and the team has a stored set of 300 tickets with agreed correct outcomes. Each week an engineer rewrites part of the prompt after skim-reading a handful of bad replies, and the team cannot say whether the last three rewrites helped or hurt. The stated requirement is that any prompt change be accepted or rejected on evidence a reviewer will accept. How should the team iterate on the prompt?
- ARewrite the prompt in full each week from the engineer's reading of recent complaints, then ship it and watch the following week's complaint volume for a fall.
- BAsk the model to critique its own prompt after each misclassification and apply the wording it suggests, on the basis that it can see why it went wrong.
- CAdd several extra instruction paragraphs covering each misclassification seen that week, keeping every earlier paragraph so no lesson is lost from the accumulated prompt.
- DScore the prompt against the 300 labelled tickets to fix a baseline, change one element of the prompt at a time, and rescore the same set so each change is accepted or rejected on the measured movement.check_circle Correct
Iterate prompts against a fixed labelled set, changing one element at a time, rather than rewriting on impression. A prompt change can only be credited or blamed if the same inputs are scored before and after it. A stored labelled set makes the accuracy figure repeatable, and varying one element per run keeps the movement attributable to that element instead of to an unmeasured mix of edits and traffic.
Why A is wrong: Complaint volume is a real signal, so this feels evidence-led, but it moves with traffic mix and reporting habits, arrives after customers are affected, and a full rewrite changes many things at once so no single edit can be credited.
Why B is wrong: Self-critique often produces sensible-sounding wording, which makes it tempting, but the model grading its own output is not an independent measurement and the change still ships with no before and after figure on a fixed set.
Why C is wrong: Covering observed errors sounds thorough, but an ever-growing instruction block raises cost per request, buries the instructions that matter, and still produces no figure showing whether accuracy moved.
Why D is correct: Correct: a fixed labelled set turns the rate into a repeatable measurement, and changing one element per run attributes any movement to that element, which is what a reviewer can accept.
lock_openFree samplePrompt and Context Engineeringmedium
An intake service classifies inbound emails into one of six handling queues using a tool that writes a classification record, with the queue name declared as a free-form string. Over 20,000 records, about 1.5 per cent carry a queue name outside the six the router recognises, and the router silently discards them. The stated requirement is that no email finishes unrouted. Which change best meets it?
- ADeclare the queue field as an enumeration of the six permitted names in the tool schema, and rely on that declaration to guarantee that only those six values ever arrive at the router.
- BDeclare the queue field as an enumeration of the six permitted names in the tool schema, and check the received value against that same list before routing, sending anything unrecognised to a review queue.check_circle Correct
- CWrap the router in a handler that catches the failure raised when an unknown queue name is passed, logs the record, and allows the batch to continue processing the remaining emails.
- DAdd the six permitted queue names to the system prompt with an instruction to use only those values, and keep the queue field declared as a free-form string in the tool's input schema.
Constrain a field in the schema and still validate the received value, because a declared shape is a request rather than proof of what arrived. Declaring the permitted values narrows what the model produces, but the consuming code is what decides whether a record is acted on, so an unrecognised value must be detected at the boundary and given somewhere to go. Combining the two means the common case is constrained at generation time and the residual case is caught rather than silently dropped.
Why A is wrong: Tempting because an enumeration is genuinely the right way to express the permitted set. A schema shapes what is requested rather than proving what arrived, so the router still needs its own check to stay safe.
Why B is correct: Correct: the enumeration constrains what the model is asked to produce and the boundary check decides what the router accepts, so an unexpected value is surfaced for handling rather than dropped.
Why C is wrong: Tempting because defensive handling at the boundary is sound practice and would make the loss visible. Logging a discarded record still leaves the email unrouted, which is the requirement that has to be met.
Why D is wrong: Tempting because naming the permitted values does improve compliance in practice. An instruction is guidance rather than a constraint, so occasional out-of-set values continue to arrive and are still discarded.
lock_openFree samplePrompt and Context Engineeringmedium
A quoting service streams Claude's response so a user sees text within its stated one second budget. The reply is a JSON object that the service also passes to a pricing system. The current handler attempts to parse the accumulated buffer after every chunk and forwards the first object that parses, and operations records quotes built from a half-written object whose later fields never arrived. Total generated length and the streaming display must both stay as they are. Which change corrects the reported behaviour?
- ARender the streamed text to the user as it arrives, but hold the parse and every downstream side effect until the stream reports that generation has finished normally.check_circle Correct
- BKeep parsing each chunk as it arrives, and reject any parsed object whose numeric fields fall outside the ranges the pricing system accepts before forwarding it onward.
- CStop streaming to the user and buffer the whole reply before rendering it, so the parse only ever runs against a finished response body.
- DHalve the output ceiling on the request so responses finish sooner and the accumulated buffer reaches a complete object earlier in the stream.
Stream partial output to a user for display only, and delay parsing and downstream side effects until generation has completed. A partial buffer can parse successfully while still missing fields the writer intended to emit, so an incremental parse is not evidence of a complete object. Separating the display path from the consumption path lets the interface stay responsive while every side effect waits for a finished, checkable response.
Why A is correct: Correct: display and consumption are separate concerns, so partial text can be shown while the parse and the pricing call wait for a completed response, which is the only point at which the object is known to be whole.
Why B is wrong: Tempting because a range check is a real validation step, but a truncated object can carry in-range values for the fields that did arrive, so the check passes on incomplete data and the wrong quote still goes forward.
Why C is wrong: Tempting because it does guarantee a complete object, but it abandons the one second display budget the stem states must be preserved, and the parsing fault can be fixed without giving that up.
Why D is wrong: Tempting because shorter replies do complete faster, but reducing the output ceiling truncates generation rather than saving it, and it changes the total generated length the stem fixes.