Why Giving AI Agents More Context Can Make Them Worse

A holiday-let operator running 23 properties built AI agents into daily operations and found that giving agents more context often degrades their decisions, because large context blobs bury relevant information. The operator's project, Zugrow, now supplies agents with the smallest useful view of reality, separating mutable facts from policy, converting human-oriented listing copy into structured state, and tracking context freshness. The operator reports that structuring context this way made a bigger difference than expected and lets the application enforce rules the model might otherwise forget.

Most AI agent demos start with the model. We ended up spending far more time thinking about what gets put around the model. I run 23 holiday lets and have been building AI agents into the day-to-day operation. Guest messaging sounds like one of the easier problems: That works brilliantly right up until the guest asks: Can I park a second car? Now the answer depends on the property, the booking, the parking arrangement, whether they're currently checked in, whether anything has changed since the listing was written and potentially something a member of the team said twenty minutes ago. The model is suddenly the easy bit. While building Zugrow https://zugrow.com/ , one of the lessons that kept coming back was this: An agent can have a very good model and still make a bad decision because you gave it the wrong state. So we stopped treating context as a giant blob of text and started treating it like application data. My instinct initially was simple. More context = better answer. So if a guest messaged about a booking, why not give the agent: It feels sensible. It also produces a mess. Important information gets buried amongst things that have nothing to do with the current question. Instead, the agent should get the smallest useful view of reality . Something closer to: type GuestContext = { property: { name: string; checkInTime: string; checkOutTime: string; parking: ParkingPolicy; }; booking: { arrivalDate: string; departureDate: string; guestCount: number; status: BookingStatus; }; conversation: { recentMessages: Message ; }; }; If somebody asks about parking, the agent doesn't need the Wi-Fi password, the boiler instructions and six months of pricing history. Give it what it needs to answer the question in front of it. That sounds obvious. In an agent system, it is surprisingly easy to forget. This made a bigger difference than I expected. Consider: Parking is available behind the building. Guests should normally use Bay 14. Sometimes another space may be available. Do not guarantee a second space. There are two completely different things happening here. The first three sentences describe the world. The last sentence describes what the agent is allowed to do. Mixing those together makes the prompt harder to reason about. We now think of them separately: js const facts = { parkingType: "allocated", primaryBay: "14", additionalSpacePossible: true }; const policy = { mayGuaranteeAdditionalSpace: false }; The distinction matters because facts can change. Policy usually changes much less often. It also means the application can enforce some rules without relying on the model remembering them. Listings are written for humans. Agents need structured state. Suppose the listing says: Parking is available for guests. Perfectly reasonable marketing copy. But the agent needs to know: { parkingAvailable: true, guaranteedSpaces: 1, extraSpacesRequireApproval: true } Those two things communicate roughly the same information to a human. They are very different inputs for software. The more agents we added, the more I found myself converting vague property information into explicit state. Instead of: Early check-in may sometimes be available. Store: { standardCheckIn: "15:00", earlyCheckInAllowed: true, earliestPossibleTime: "13:00", requiresTeamApproval: true } The agent can now reason from something much closer to reality. And more importantly, our application can stop it making promises it shouldn't make. There is another problem. A fact can be correct and still be wrong. Yesterday: wifi.status = "working"; Today the router has died. The database technically contains a fact. It is just stale. So useful agent context needs some idea of freshness: type ContextValue<T = { value: T; updatedAt: Date; source: "host" | "system" | "channel" | "agent"; }; That opens up much better behaviour. The application can say: if hoursSince wifi.updatedAt 72 { requireVerification ; } Or the agent can respond cautiously rather than stating something as certain. This became an important mental model for me: Agent context is not knowledge. It is a snapshot. Snapshots age. This matters even more once agents can act. Imagine this sequence: 10:00:00 Guest asks for early check-in 10:00:02 Agent reads availability 10:00:08 Cleaner changes schedule 10:00:11 Agent confirms early check-in The model made the right decision using the information it had. The system still made the wrong decision. That is a normal software concurrency problem wearing an AI hat. The fix is boring: js const suggestion = await agent.decide context ; const latestState = await bookings.getCurrent bookingId ; if stillValid suggestion, latestState { return requireHumanReview ; } return execute suggestion ; We use the model to decide what it would like to do. The application checks whether it is still allowed to do it. That second check matters far more than making the prompt another 500 words longer. Conversation history causes the same problem. It is tempting to keep throwing every previous message into the context window. But imagine a guest has sent 70 messages during a two-week stay. Most of that conversation is irrelevant when they ask: What time is checkout tomorrow? Instead of treating history as one enormous transcript, you can reduce it into state and recent events. Something like: js const context = { booking: currentBooking, property: relevantPropertyFacts, recentEvents: { type: "guest message", text: "What time is checkout tomorrow?" }, { type: "late checkout request", status: "not requested" } }; The model gets much less information. But the information it does get matters more. That is usually the trade I want. This is the part I would build earlier if I started again. When an agent gives a strange answer, knowing the output is not enough. You need to know: What did it believe was true at the time? So every decision should have a trace. interface AgentTrace { agent: string; contextVersion: string; input: unknown; decision: unknown; model: string; timestamp: Date; } Then when somebody asks: Why did the agent tell this guest they had two parking spaces? you don't have to guess. You can inspect the exact state supplied to the model. A surprising number of apparent "AI mistakes" turn out to be ordinary software mistakes upstream. Wrong property. Old data. Missing field. Incorrect booking state. The model simply gave a perfectly reasonable answer to the reality we accidentally handed it. Our agent flow increasingly looks like this: Guest message ↓ Intent / task ↓ Context builder ↓ Relevant current state ↓ AI decision ↓ Deterministic validation ↓ State recheck ↓ Human approval or action ↓ Audit log The LLM sits in the middle. It isn't the application. That distinction seems obvious written down, but a lot of agent prototypes blur it. They build: data → enormous prompt → model → action Then try to improve reliability by making the enormous prompt even larger. Eventually you are asking a probabilistic model to compensate for missing application architecture. That doesn't scale particularly well. If I were building an agent system from scratch now: The strange thing about building AI agents is that the longer I work on them, the less time I spend thinking about the model. The model is important. But most of the reliability comes from fairly ordinary software engineering around it. And honestly, I think that is good news. I built Zugrow https://zugrow.com/ , an AI-first property management platform, and use the same systems across the holiday lets I operate. I'm particularly interested in how other people are handling context construction, stale state and pre-action validation in agent systems.