01 The problem
A Vancouver interior design firm came to us with a problem that did not fit in one box, because it was not one problem. It was the same problem wearing five different costumes.
Design work runs on coordination. A project moves forward when the right email gets answered, the right vendor confirms the right spec, and the right person remembers what was decided three months ago. None of that is design. All of it consumes designers. The inbox decided each morning's priorities by arrival order instead of importance. Vendor threads stalled on incomplete information, then needed chasing. Institutional knowledge lived in the heads of senior people and in attachments nobody could find. The picture of how the business was doing lived in whoever last assembled it. And business development, the work that feeds next year, happened in the gaps the other four problems left behind.
Most firms in this position buy five tools and get five new logins. The brief here was different: one operating layer, built around how the firm already works.
02 Why one system was never going to be enough
The usual engagement automates the single most painful workflow and stops. We argued against that here, for a reason worth making explicit: the five problems feed each other.
An answered email often depends on knowing what was decided before, which is a knowledge problem. A vendor follow-up depends on noticing the gap, which is an inbox problem. A leadership decision depends on seeing the numbers, which is a reporting problem. Automate any one in isolation and it keeps tripping over the other four. The firm did not need a faster inbox. It needed an operating layer where each system hands off to the next.
That argument cuts both ways, and we were honest about the cost: five systems in one build means a longer deployment, more change management, and more education before anyone can declare victory. The firm took that trade with eyes open.
03 What had to be true first
Three constraints were fixed before the build started.
Built around the firm's actual workflows, not generic ones. A design studio's email is not a sales team's email. Vendor coordination has its own grammar: specs, lead times, samples, revisions. Off-the-shelf tools kept failing the firm precisely because they were built for someone else's workflow, so this build started from how the studio actually runs.
Drafts and suggestions, never silent actions. The system proposes; people decide. An AI-drafted reply is a draft until a person sends it. A vendor follow-up goes out under rules the team set. Nothing client-facing happens without a human having either written the rule or approved the message.
The firm's knowledge stays the firm's. The knowledge brain runs on the firm's own database instance, isolated from every other client of ours, and the firm keeps the keys. That is our standard architecture, and it mattered doubly here because the corpus is the firm's competitive memory: past projects, decisions, vendors, pricing history.
04 What we built
Five systems, one build, sharing one data layer.
- AI inbox. Incoming email is triaged by priority instead of arrival order, and the system prepares draft replies for a person to edit and send. The morning starts with what matters, not with whatever landed last.
- Vendor coordination. Vendor threads are checked for completeness: missing specs, missing confirmations, missing dates. Gaps trigger automated follow-ups under team-set rules, so chasing stops being a job a person has to remember.
- Internal knowledge brain. A retrieval system over the firm's own documents and decisions, powered by vector search on Supabase. Ask it what was decided, and it answers from the firm's record instead of someone's memory.
- Visual business dashboard. A high-contrast live view of the numbers leadership actually checks, replacing the assembled-by-hand status picture.
- Inbound content engine. The system reads industry content and surfaces suggestions, so business development draws from a continuously stocked shelf instead of a blank page.
Underneath the five sits an execution layer of 18 automation scripts, including scrapers that watch Vancouver building permits and realtor listings and enrich what they find. Permit activity is an early signal of design work to come; the system reads it so a person does not have to.
Basis for the counts above: deployed modules and scripts in the project repository, June 2026.
05 The technologies behind it
- React and Vite for the front end. This build is custom rather than templated, because the dashboard and inbox interfaces had to match the firm's working patterns, not ours.
- Supabase holds the data layer, including the vector store behind the knowledge brain. One database instance, owned by the engagement, isolated from everything else.
- Modal runs the Python execution layer: the 18 scripts, on schedules, with no servers for anyone to maintain.
- Claude does the language work: triage judgments, draft replies, completeness checks, retrieval answers.
The system runs on the same DOE architecture as every build we ship: plain-text directives the team can read and edit, an orchestration layer that makes decisions, and deterministic scripts that do the work. The reasoning behind each tool is documented at /stack.
06 Where the numbers are
This is a deployment story, and we would rather say that plainly than dress it up. The systems are built and in deployment. The outcome numbers, hours reclaimed in the inbox, vendor threads closed without chasing, time to answer from the knowledge brain, are not measured yet, and we do not publish numbers we have not measured.
What exists today is the before picture: the baseline workflows were recorded before the build, the same way the measured cases on this site recorded theirs, because an after number means nothing without one. First measurements land this quarter. When they do, this page gets them, with the measurement basis attached.
What we can already say: the five problems in section 01 now have five running systems against them, the counts in the header are real, and the firm's team is being trained on all of it as it deploys.
07 What the team learns and owns
Under our Build + Educate model, the firm's team is learning the system while we ship it. They own the directives: triage rules, follow-up logic, dashboard definitions, all in plain text they can edit without an engineering ticket. They are learning to evaluate AI-drafted replies instead of trusting them blindly, and to feed the knowledge brain the documents that make it smarter.
The education is not a courtesy. It is the difference between a firm that operates an AI layer and a firm that rents one. When the engagement's build phase ends, the operating knowledge stays in the building.
08 Related work
The vendor-coordination and intake patterns here are productized as client onboarding and document automation, and the knowledge brain is the same pattern as our own agency knowledge vault, which we run on ourselves. For a measured case where the before/after numbers are already in, read the Breez outbound engine. If you want your own baseline mapped before any build, start with the free audit.