My custom GPT couldn't tell me the square footage of the shed.
That sounds like a small thing, but it kept happening. Wrong numbers. Wrong building. Or no answer at all, just a vague “I don't have that information” from an AI that was theoretically loaded with every document we had.
We were setting up an AI system for Arena Hall — a real estate project with multiple buildings, each with its own history, files, and operational details. My instinct was to build one custom GPT and give it everything. Lease docs, floor plans, maintenance logs, contracts, renovation history. All of it.
Seemed efficient. One place to ask questions about the whole project.
It wasn't efficient. It was noisy.
Why Loaded-Up GPTs Underperform
Here's what I didn't fully appreciate at first: the context window isn't magic, and more files don't mean smarter answers.
When you load 80 files into a custom GPT and ask a question, it's searching through all 80 files every time. It doesn't automatically know which documents are relevant. It's weighing everything — lease agreements from the Gibson building while you're asking about the guest house, maintenance logs from three years ago while you need current specs.
The signal gets diluted. The GPT pulls in loosely related information, misses specifics that are buried somewhere in the pile, and produces answers that are… fine. Not wrong exactly. Just imprecise. And in real estate, imprecise is often worse than nothing, because you might act on it.
Our single Arena Hall GPT wasn't dumb. It was overwhelmed.
The Library Approach
Once we understood the problem, the fix was obvious: build smaller GPTs, not bigger ones.
One GPT for the Gibson building. Only Gibson building files — floor plans, lease, maintenance history, renovation specs. Nothing else.
One GPT for the guest house. Only guest house files.
One for the culinary operations. One for the real estate side generally.
Each GPT has a narrow job. It knows one thing well.
Now when someone asks about square footage, they open the Gibson building GPT. It doesn't have to sort through documents about three other buildings. It just has Gibson documents. The answer comes back fast and right.
The shift feels counterintuitive — shouldn't a bigger knowledge base produce better answers? But it's actually the same principle as hiring specialists instead of generalists for specific problems. You don't ask your accountant about your roof. You call a roofer.
How We Keep Track of It
A library only works if people know which book to open.
We track the whole GPT library in Airtable. Each row is one GPT:
- Name (descriptive, like “Arena Hall — Gibson Building”)
- Instructions (what it's for, how to use it)
- Files loaded (which documents are in it)
- Use cases (what kinds of questions it handles well)
Anyone on the team can look up which GPT to use before they start asking questions. Takes five seconds. Saves a lot of back-and-forth and wrong answers.
This part matters. Building the GPTs is only half the system. If people don't know the library exists or which specialist to summon, they'll default back to asking ChatGPT everything and getting mediocre answers.
What This Looks Like in Practice
Say we're doing a walkthrough of the guest house and we want to quickly check the last maintenance date on the HVAC system. Before: you'd open the big Arena Hall GPT, hope it had that file, and get an answer that may or may not be specific to the guest house.
Now: you open the guest house GPT. Ask the question. The GPT has maybe 15 files, all about the guest house. The HVAC answer is in there somewhere and it finds it.
Small context. Focused files. Better answer.
The Design Principle
Most people approach AI tools the same way they approach early software: one tool for everything. One spreadsheet. One folder. One assistant that handles all queries.
But AI assistants actually work better when scoped. A narrow, focused GPT is faster to query, more accurate in its answers, and easier to maintain. When you need to update information — new lease terms, a renovation — you update one GPT's files, not a massive shared document dump.
Before you finalize any custom GPT, ask: what's the smallest useful scope for this thing?
If you're building a GPT for a whole company, try building one per department first. If you're building one for a project, try one per major component. Fewer files per GPT. Cleaner answers.
The skill isn't building an AI that knows everything.
It's building a library and knowing which specialist to ask.
If you're designing AI systems for your business — whether that's document search, team knowledge bases, or client-facing tools — I help teams figure out the right architecture before they build. Reach out or check out my AI consulting and workshop programs.
