{"slug": "why-giving-ai-agents-more-context-can-make-them-worse", "title": "Why Giving AI Agents More Context Can Make Them Worse", "summary": "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.", "body_md": "Most AI agent demos start with the model.\n\nWe ended up spending far more time thinking about what gets put **around** the model.\n\nI 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:\n\nThat works brilliantly right up until the guest asks:\n\nCan I park a second car?\n\nNow 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.\n\nThe model is suddenly the easy bit.\n\nWhile building [Zugrow](https://zugrow.com/), one of the lessons that kept coming back was this:\n\n**An agent can have a very good model and still make a bad decision because you gave it the wrong state.**\n\nSo we stopped treating context as a giant blob of text and started treating it like application data.\n\nMy instinct initially was simple.\n\nMore context = better answer.\n\nSo if a guest messaged about a booking, why not give the agent:\n\nIt feels sensible.\n\nIt also produces a mess.\n\nImportant information gets buried amongst things that have nothing to do with the current question.\n\nInstead, the agent should get the **smallest useful view of reality**.\n\nSomething closer to:\n\n```\ntype GuestContext = {\n  property: {\n    name: string;\n    checkInTime: string;\n    checkOutTime: string;\n    parking: ParkingPolicy;\n  };\n\n  booking: {\n    arrivalDate: string;\n    departureDate: string;\n    guestCount: number;\n    status: BookingStatus;\n  };\n\n  conversation: {\n    recentMessages: Message[];\n  };\n};\n```\n\nIf somebody asks about parking, the agent doesn't need the Wi-Fi password, the boiler instructions and six months of pricing history.\n\nGive it what it needs to answer the question in front of it.\n\nThat sounds obvious.\n\nIn an agent system, it is surprisingly easy to forget.\n\nThis made a bigger difference than I expected.\n\nConsider:\n\n```\nParking is available behind the building.\nGuests should normally use Bay 14.\nSometimes another space may be available.\nDo not guarantee a second space.\n```\n\nThere are two completely different things happening here.\n\nThe first three sentences describe the world.\n\nThe last sentence describes what the agent is allowed to do.\n\nMixing those together makes the prompt harder to reason about.\n\nWe now think of them separately:\n\n``` js\nconst facts = {\n  parkingType: \"allocated\",\n  primaryBay: \"14\",\n  additionalSpacePossible: true\n};\n\nconst policy = {\n  mayGuaranteeAdditionalSpace: false\n};\n```\n\nThe distinction matters because facts can change.\n\nPolicy usually changes much less often.\n\nIt also means the application can enforce some rules without relying on the model remembering them.\n\nListings are written for humans.\n\nAgents need structured state.\n\nSuppose the listing says:\n\nParking is available for guests.\n\nPerfectly reasonable marketing copy.\n\nBut the agent needs to know:\n\n```\n{\n  parkingAvailable: true,\n  guaranteedSpaces: 1,\n  extraSpacesRequireApproval: true\n}\n```\n\nThose two things communicate roughly the same information to a human.\n\nThey are very different inputs for software.\n\nThe more agents we added, the more I found myself converting vague property information into explicit state.\n\nInstead of:\n\n```\nEarly check-in may sometimes be available.\n```\n\nStore:\n\n```\n{\n  standardCheckIn: \"15:00\",\n  earlyCheckInAllowed: true,\n  earliestPossibleTime: \"13:00\",\n  requiresTeamApproval: true\n}\n```\n\nThe agent can now reason from something much closer to reality.\n\nAnd more importantly, our application can stop it making promises it shouldn't make.\n\nThere is another problem.\n\nA fact can be correct and still be wrong.\n\nYesterday:\n\n```\nwifi.status = \"working\";\n```\n\nToday the router has died.\n\nThe database technically contains a fact.\n\nIt is just stale.\n\nSo useful agent context needs some idea of freshness:\n\n```\ntype ContextValue<T> = {\n  value: T;\n  updatedAt: Date;\n  source: \"host\" | \"system\" | \"channel\" | \"agent\";\n};\n```\n\nThat opens up much better behaviour.\n\nThe application can say:\n\n```\nif (hoursSince(wifi.updatedAt) > 72) {\n  requireVerification();\n}\n```\n\nOr the agent can respond cautiously rather than stating something as certain.\n\nThis became an important mental model for me:\n\n**Agent context is not knowledge. It is a snapshot.**\n\nSnapshots age.\n\nThis matters even more once agents can act.\n\nImagine this sequence:\n\n```\n10:00:00 Guest asks for early check-in\n10:00:02 Agent reads availability\n10:00:08 Cleaner changes schedule\n10:00:11 Agent confirms early check-in\n```\n\nThe model made the right decision using the information it had.\n\nThe system still made the wrong decision.\n\nThat is a normal software concurrency problem wearing an AI hat.\n\nThe fix is boring:\n\n``` js\nconst suggestion = await agent.decide(context);\n\nconst latestState = await bookings.getCurrent(bookingId);\n\nif (!stillValid(suggestion, latestState)) {\n  return requireHumanReview();\n}\n\nreturn execute(suggestion);\n```\n\nWe use the model to decide what it **would like** to do.\n\nThe application checks whether it is **still allowed** to do it.\n\nThat second check matters far more than making the prompt another 500 words longer.\n\nConversation history causes the same problem.\n\nIt is tempting to keep throwing every previous message into the context window.\n\nBut imagine a guest has sent 70 messages during a two-week stay.\n\nMost of that conversation is irrelevant when they ask:\n\nWhat time is checkout tomorrow?\n\nInstead of treating history as one enormous transcript, you can reduce it into state and recent events.\n\nSomething like:\n\n``` js\nconst context = {\n  booking: currentBooking,\n  property: relevantPropertyFacts,\n\n  recentEvents: [\n    {\n      type: \"guest_message\",\n      text: \"What time is checkout tomorrow?\"\n    },\n    {\n      type: \"late_checkout_request\",\n      status: \"not_requested\"\n    }\n  ]\n};\n```\n\nThe model gets much less information.\n\nBut the information it does get matters more.\n\nThat is usually the trade I want.\n\nThis is the part I would build earlier if I started again.\n\nWhen an agent gives a strange answer, knowing the output is not enough.\n\nYou need to know:\n\n**What did it believe was true at the time?**\n\nSo every decision should have a trace.\n\n```\ninterface AgentTrace {\n  agent: string;\n  contextVersion: string;\n  input: unknown;\n  decision: unknown;\n  model: string;\n  timestamp: Date;\n}\n```\n\nThen when somebody asks:\n\nWhy did the agent tell this guest they had two parking spaces?\n\nyou don't have to guess.\n\nYou can inspect the exact state supplied to the model.\n\nA surprising number of apparent \"AI mistakes\" turn out to be ordinary software mistakes upstream.\n\nWrong property.\n\nOld data.\n\nMissing field.\n\nIncorrect booking state.\n\nThe model simply gave a perfectly reasonable answer to the reality we accidentally handed it.\n\nOur agent flow increasingly looks like this:\n\n```\nGuest message\n      ↓\nIntent / task\n      ↓\nContext builder\n      ↓\nRelevant current state\n      ↓\nAI decision\n      ↓\nDeterministic validation\n      ↓\nState recheck\n      ↓\nHuman approval or action\n      ↓\nAudit log\n```\n\nThe LLM sits in the middle.\n\nIt isn't the application.\n\nThat distinction seems obvious written down, but a lot of agent prototypes blur it.\n\nThey build:\n\n```\ndata → enormous prompt → model → action\n```\n\nThen try to improve reliability by making the enormous prompt even larger.\n\nEventually you are asking a probabilistic model to compensate for missing application architecture.\n\nThat doesn't scale particularly well.\n\nIf I were building an agent system from scratch now:\n\nThe strange thing about building AI agents is that the longer I work on them, the less time I spend thinking about the model.\n\nThe model is important.\n\nBut most of the reliability comes from fairly ordinary software engineering around it.\n\nAnd honestly, I think that is good news.\n\n*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.*", "url": "https://wpnews.pro/news/why-giving-ai-agents-more-context-can-make-them-worse", "canonical_source": "https://dev.to/ben_mccarthy_aae742e0d499/why-giving-ai-agents-more-context-can-make-them-worse-1fii", "published_at": "2026-09-14 18:16:38+00:00", "updated_at": "2026-09-14 21:36:43.244979+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "large-language-models"], "entities": ["Zugrow"], "alternates": {"html": "https://wpnews.pro/news/why-giving-ai-agents-more-context-can-make-them-worse", "markdown": "https://wpnews.pro/news/why-giving-ai-agents-more-context-can-make-them-worse.md", "text": "https://wpnews.pro/news/why-giving-ai-agents-more-context-can-make-them-worse.txt", "jsonld": "https://wpnews.pro/news/why-giving-ai-agents-more-context-can-make-them-worse.jsonld"}}