Build1 publisher2 min readPublished
A holiday-let operator trims agent context to nine typed fields per request
Writing on dev.to, Ben McCarthy describes rebuilding the guest-messaging agents across his 23 holiday lets around a typed per-request view of state, with world facts held apart from the policy about what the agent may promise.
The Engineer · Build desk
What happened
- A guest asking whether a second car can be parked forces an answer that depends on the property, the booking, whether the guest is checked in, and something a team member said twenty minutes ago.
- The first design passed the agent eight sources at once, including the property description, all amenities, house rules, the entire conversation, internal notes and host instructions.
- That blob was replaced by a GuestContext type exposing nine leaf fields across three groups: property, booking and recent conversation messages.
- World facts now sit in one object and permissions in another, so mayGuaranteeAdditionalSpace: false lives in application code instead of a sentence in the prompt.
- The stale-value case is a wifi status that read working yesterday and still reads working after the router died overnight, because the database holds a fact rather than a live check.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- cost Provenance is paid on the write side. Every stamped value needs three stored fields instead of one, and whatever updates a wifi status has to record whether the host, a channel, a system job or the agent supplied it.
- decision Once the refusal is a policy field, the code can block a promise about a second parking space without the model needing to remember not to make one.
- constraint The 72-hour staleness limit is a hand-set constant, so anyone copying the pattern is adopting one operator's tolerance for an out-of-date wifi status.
- contradiction The headline claim about context hurting answers is experiential. Without a comparison on the same question set, the size of the improvement cannot be transferred to another domain.
The post's last example is a timing problem. At 10:00:00 a guest asks for early check-in. At 10:00:02 the agent reads availability. The next line is 10:00:08 and a cleaner, and the text breaks off mid-word there [21]. Six seconds separate the read from the next event in the sequence [22].
Freshness is where adoption gets expensive. The wrapper is ContextValue<T>, holding value, updatedAt, and a source drawn from host, system, channel or agent [17]. One boolean becomes three fields [18]. The source enum is the harder half: something on the write path has to know whether a wifi status arrived from a host edit, a channel message, a system job, or the agent itself. The property database has to change to carry it. The one threshold in the post is 72 hours on wifi.updatedAt, past which the application calls requireVerification() [19]. How that number was chosen is not stated.
Two other conversions turn a listing sentence into typed fields. The listing sentence "Parking is available for guests" becomes parkingAvailable: true, guaranteedSpaces: 1, extraSpacesRequireApproval: true [14]. "Early check-in may sometimes be available" becomes a standardCheckIn of 15:00, an earliestPossibleTime of 13:00, and requiresTeamApproval: true [15]. Both read the same to a human and differently to software [14]. "An agent can have a very good model and still make a bad decision because you gave it the wrong state," McCarthy wrote [5].
He also wrote: "Agent context is not knowledge. It is a snapshot." [20]
The trim transfers on one condition. Guest messaging has a narrow object graph, because a message arrives against a booking and the booking names one property, so the request itself identifies the rows to fetch [3]. Where the incoming question does not identify its rows, something has to choose the view before the agent runs, and the post does not describe a router. The case against the blob rests on McCarthy's observation that important information gets buried among things with nothing to do with the current question [7], over 23 lets [2]. He never puts the eight-source blob and the typed view side by side [23].
The narrow version of the finding is well supported: a parking question does not need the wifi password, the boiler instructions or six months of pricing history [25], and the fetch that skips them is cheaper on tokens whatever it does to answer quality. The wider claim, that more context makes answers worse, is one operator's experience written up as design guidance.
What to watch
- Whether the cut-off timeline resolves into a write-time recheck, so the agent re-reads availability before committing an early check-in.
- Whether anyone publishes an evaluation comparing blob context with a scoped typed context on the same question set.
- Whether the "agent" value in the source enum is ever used to discount agent-written facts on a later read.