Work/Architecture firm
Half the firm's work was closed to AI
Two calls found the real problem. I advised against the build they asked for and showed what they need in a working demo.
- 2 calls to find the real problem
- Advised against a risky build, twice
- The advice held 3 months later
- Industry
- Architecture
- Firm
- Employee-owned
- Time to the real problem
- 2 calls
- Stage
- Advice and a working demo
In one paragraph
An architecture firm asked what it would take to run AI on work they cannot put into a public tool. Their clients are life science and advanced technology companies, and that work arrives under NDA. I spent two calls and a document review finding out what they already do. I also built them an interactive briefing that runs the thing it describes, and I recommended a first build they had not asked for. What they asked for was automated quality control on drawing sets. What I proposed was a private search over the building codes they already own, and later, with better evidence, two text workflows from their own daily practice. Most of this case study is about the reasoning behind that swap.
First contact was on 10 June 2026. The first commit to the briefing application came two days later, in the same week as the first working session.
The problem I started from
The client is an employee-owned architecture practice in California. They design laboratories, manufacturing space and civic buildings, so a meaningful share of their work sits under confidentiality agreements that their clients take seriously.
The problem they stated was privacy. The real problem took a second call to find, and neither of us expected it.
They were already using AI heavily, on real projects.
Then the firm's President said the sentence the whole engagement turns on:
"If anything is private, I don't use it just for the sake of confidentiality."
So the bottleneck was never capability or cost. They already pay for AI, at a price the firm considers unremarkable, and they are good at using it. Half their work is simply closed to the tool they are good at.
That reframed what a private setup is for. Its job is not to make their current work cheaper. Its job is to open up the half of their work they cannot bring to the table today.
What I decided
This is the part of a project that is mine. AI agents I direct wrote the code, but they did not make the calls below.
Text before images, both times they asked for drawings. In June the room lit up at the idea of first-pass quality control on drawing sets. The tool would be trained on how the firm wants drawings to look, and then it would flag inconsistencies, code problems and stale tasks. It was the most wanted thing on the list, and I recommended against it as a first build twice, three months apart. These were my reasons, in order of weight:
- A wrong answer has to be visible. Code search cites the code, the edition and the section on every answer, so an error announces itself the moment someone clicks the citation. Quality control on a drawing set fails silently, because a flag that never appears looks exactly like a clean set. Nobody finds out until construction.
- A licensed architect seals the drawings. Search carries no professional liability, but a tool that can miss a defect quietly inherits some. That is a conversation to have deliberately, not by accident in a pilot.
- It is text, so it runs on hardware they might already own. Reading drawings needs a model that reads images, plus real computing power. Their server room holds two towers, one of them unused, and nobody yet knows what either can run.
- They already own the codes. There is no data to acquire, no licensing question and no waiting.
What exists
| The briefing | 13 chapters, 11 opportunity cards, 16 build diagrams, 17 answered questions, 26 glossary terms |
|---|---|
| Live Q&A | Answers from the guide's own content, with citations and suggested follow-up questions |
| Live demo | Upload a document and ask it questions. It comes loaded with 3 public documents, which hold 1,123 passages and about 90,000 words |
| Code | 7,934 lines across 107 files, and 32 tests in 287 lines across 6 files |
| History | 58 commits on the current branch, from 12 June to 11 September |
| Access | A passphrase gate with a 30-day session, and every accepted and rejected entry logged with a timestamp |
| Deployment | Self-hosted on a VPS behind a reverse proxy, and deployed by a webhook on every push |
The finding that changed the work
On the second call I asked them to show me instead of telling me, and they shared a screen for thirteen minutes. Most of what I learned was not in anything either of them said.
The finding came from one of their code compliance conversations, which I read later. A glazing specification was failing a Title 24 prescriptive requirement, and their AI tool worked the problem properly. That was good work, but it sourced the answer from an architecture news site and a manufacturer's own marketing data. Then it ended with this:
"I couldn't pull the live table off up.codes."
Their AI cannot reach the platform that holds the codes. Because the authoritative source is closed to the tool, they answer code questions from the open web. That single line is the strongest evidence in the entire account for the build I had recommended in June. I found it in a screenshot, three months after recommending it.
What I would do differently
Watch them work before writing anything. Everything I got wrong in June came from taking descriptions at face value. Thirteen minutes of screen sharing in September was worth more than the entire first engagement. I could have asked for it in June, but I did not think to.