Project Houston Weekly · June 29–July 3 (Week 2)

Achuta Kadambi Friday, July 3, 2026 ·4 min read

Last week we set up Houston to access Cambrian’s files and talk to our team. This week we let it reason over the raw files themselves. Let us call this task as shipping bytes to the metal: sending the actual bytes of videos, documents, spreadsheets down to a powerful model.

Given that Cambrian is collecting a lot of data off each jobsite, we cannot send all the data to the metal. So we came up with a schema that is agent readable and encourages a bijective mapping between files to provide a source of truth. The result was that Houston has an improved ability to “see”, i.e., read the photos, renderings, and plans you send it. This is a small starting point in bringing Spatial AI into Houston.

Shipping bytes to the metal

As mentioned above, construction generates far too much data to shove wholesale into a context window, so the trick is routing only the relevant bytes to the model. Every file now gets a small Git pointer (e.g. an index card) which includes a thin spine (where it lives, its hash, its type) plus a payload of some meta data. These Git pointers bridge Drive and GitHub so a signed PDF and a code file share one source of truth.

As shown in the figure below, when you tag Houston with a photo, the following sequence occurs: your message fires a Google Workspace event onto a Pub/Sub topic that wakes Houston instantly instead of polling on a clock as it was setup earlier. The photo’s pixels travel separately to the metal, as attachment bytes, alongside your question.

Before this week; After this week

Before this week, Houston could file a photo but not open it. Now it can read the image, answer, and refer you to the source it read:

Before this week

After this week

A potentially useful upgrade that is still in progress is reading multiple images and comparing them. Here’s a test of Houston where Sasha posted two renderings and asked whether they matched his intent:

Houston · Horizon

SV

Sasha Vilesov8:04 PM

I think ficus trees need to be closer to the neighbor on the right, but is this roughly what you were thinking?

H

HoustonAPP8:05 PM

Yes — both renderings put the tall ficus hedge on the right, running along the driveway toward the neighbor’s two-story house, so the general idea matches. The difference:
• Left — the hedge is tall and dense, right against the driveway.
• Right — shorter and thinner, leaving a bigger gap to that neighbor.
So for ficus pushed closer to the right neighbor as a taller screen, the left rendering is closer to your intent. One other change: the left has an open lawn, the right a raised planter wall with drought planting. (compared 2 renderings · unverified vision read)

Quality of Life Improvements: Speed and Rendering

Until this week Houston checked for messages on a clock cycle. This week we replaced the clock cycle with a listener: a posted message wakes Houston the moment it lands to minimize lag.

Before this week

After this week

A small quality of life improvement was also to fix Houston’s Chat formatting this week, as Google does not use markdown. This enables its tables and text to render more cleanly.

Before this week

After this week

Goal for Next Week

The goal for next week is to improve the ability to reason over imagery. We noticed that the field crew is taking pictures of long receipts (e.g. 30 line items) across different photos. Image handling is now not just important for the Spatial AI and plans, but comprises a large amount of our numerical data as well. This will be one priority for Houston next week.

A quality of life improvement we will make will be speed. Houston is actually slower now, because we’ve shipped a bunch of data to the metal, that now slows down the model. How to handle caching and the context window will be on our mind for the coming week.

Houston backlog