Runwise Studio
Runwise had 1 designer and 3 queues: branded water usage reports for sales, a product audit that ran on judgment alone, and collateral that had to match a brand system I had just rebuilt. Studio is the design production agent I built to take the queue. It executes inside that brand system, and I stay in the loop as the designer who decides. Launched Aug 31, 2026 for the sales and product teams.
1 designer, 3 queues
Every request was real and hand assembled. A sales rep needed a branded water usage analysis for a prospect and got it days later, built from a spreadsheet and a template. The product audit I started in 2024 depended on me noticing problems, so it moved at the speed of my attention. And every deck, one-pager, and report was a chance for the brand system to drift, because the people producing them were not the person who built it.
Runwise runs in 10,300+ buildings, so the data behind those reports exists. What was missing was a way to turn it into finished, on-brand work without a designer doing every step by hand, and without handing the brand to a model that would produce the generic output everyone recognizes on sight.
A designer, not a chatbot
Studio's identity is a product and brand designer, modeled on how I work, not a coding helper or a chatbot. That decision set the rules. Brand and content are prescriptive: the agent knows the brand system cold. Product analysis is a dialogue: the agent proposes, I steer, and it does not prescribe fixes it has not discussed.
It also cannot ship on its own. Every output routes through a human designer before it leaves, and findings go to shared channels, not private messages, so the team sees what I see. I wrote the internal launch note around that boundary: Studio is an extra set of hands for the output. The taste and the why stay with me.
Skills, tools, schedules, channels
The agent is a small file-based system. Skills are markdown: the brand system, the water analysis method, the report formats. Tools are deterministic connectors: PostHog, read only, across the app and the marketing site; Google Drive; Slack. Schedules run the recurring jobs, and Slack is the channel it lives in. It runs on Claude, deploys to Vercel on merge, and I test changes locally against real Slack threads before they go live.
Water reports: a rep posts building data in the marketing requests channel and tags Studio. It drafts the analysis in brand, usage against the 120 gallons per unit per day benchmark, overage, estimated savings, and hands it to me. I refine it with the agent until it is right, it goes back to the rep, and the final lands in a shared Drive folder.
Rage-click report: every Friday morning Studio pulls the week's rage clicks from PostHog and posts a structured report to the product feedback channel: a summary, the top offending pages, a deep dive on the worst hotspot, and a likely fix. The lookback is 7 days by default and adjustable, and it does not resurface issues the team already knows about.
Renaming it was part of the design. It started as Picasso. Studio says what it does, which is execution, not art.
The audit gets a data source
The first report reframed the product audit. 40% of all rage clicks landed on the home and building pages, concentrated on the Water tab menu. The install flow's toilet tab was the next hotspot. On the marketing site, the single largest cluster sat on the fixed header logo: people expected it to navigate, and it did nothing. None of that came from a manual audit, and all of it became work I could point to.
Water reports that took days by hand now start the moment a rep asks, and every one looks like it came from the same place.
Next, planned: the brand system moves into a shared repository that both Studio and my desktop tools read from, so decks, one-pagers, and reports draw from one source. When a new design decision is made, the agent opens a pull request and I approve it. The rage-click check moves from weekly to hourly.