Project Houston Weekly · July 13–17 (Week 4)
Achuta Kadambi
Friday, July 17, 2026
·5 min read
This week was an update to Houston’s plumbing. Specifically, improved file handling, file concurrency, code simplification, and the ability to have email as an additional intake surface for files. You’ll also notice the YAML pointer mirrors are gone — now that we trust Houston a bit more we don’t need to mirror Google Drive files to YAML pointers.
Bytes to G-Drive; Facts to Git Registry
Two weeks ago we gave every Drive file a “card” — a record Houston kept in a registry, with a background worker reconciling it against Drive every fifteen seconds. It was a reasonable design for the Houston of a month ago, when we did not have trust in its abilility to handle file concurrency (and the priority was not losing our first field data off Kelton jobsite).
Later on, we upgraded Houston to have access to the Google Drive API, which actually gives us a source of truth as Drive API has file logging. So we could get rid of the pointer cards for drive files. The main thing we need to do is have Houston distinguish between two broad types of data types; (1) Bytes — the actual files: PDFs, photos, plans — live in Google Drive, which we agreed was their home; and (2) Facts — a comp, a person, a price, a Redfin link — live in the Git registry as YAML records.
To decide on if an input is a byte or registry, we add an agent preamble to the context window so the passthrough agent can tell a byte from a fact and file. You won’t see a new feature from this — but hopefully, you’ll see Houston be more efficient as it does not need explicit concurrency syncs and daemons monitoring pointers.
PS: I think there is probably an issue lurking on collisions, e.g., where a certain topic like a person has a byte and a registry entry, but that is being taken on as technical debt right now.
Before this week
After this week
We can send files via email
One minor issue was that google chat does not allow lots of files to be attached. This is a limitation of chat UI interface: G-suite only lets a message have 1 file. Therefore, if we want to file 5 attachments via chat, that means 5 msgs.
While chat can still be used, it might be helpful to use email to add attachments, since Gmail UI lets you add a ton of attachments. Now, email capability was added, where one can email a document to houston@cambrian.world, and Houston reads the attachment, renames & files each into the right Drive folder. It also replies to the MTS team, so every MTS sees what came in and where it landed.
Two guarantees came out of it, enforced for chat file-adds too: every file Houston files gives you a one-click link to its folder, and it’s renamed properly — never IMG_3105.jpg but actually what the invoice is. So you don’t need to worry about clean filenames on intake.
Summary and Goals for Next Week
My main goals for next week will be more company-centric now that Houston is operational. I’ll be moreso working with Houston as a user by adding a bunch more files to Houston to stress-test it (while enriching our data corpus). I also plan to pay back the tech debt of bytes and facts duplication of info. At some point, I’ll think about migrating Houston to a server, but it’s not a high priority for the coming week.
Houston backlog
| Backlog Task | What it is |
|---|---|
| Interface Houston with Sentinel and Horizon | Connect the systems so they share data and act as one. |
| Move Houston to the right server hardware | Off the laptop onto proper hosting, with secrets in a store and its own service identity. |
| Continue to evolve Cambrian’s data schema | Keep refining the source-of-truth schema for files and the registry. |