Many hands on one canvas. Many companies on one platform.
Glow is a real-time automation platform built for whole teams and managed service providers: multiplayer on CRDTs in the core, AI streaming nodes directly onto the canvas from voice prompts, and human approval gates before irreversible actions. As Founding Product Engineer and fourth on the team, I shaped the canvas vision, the interaction model, and the product architecture — owning product decisions, core workflow behavior, and documentation.
Pax Momentum · Startup Wise Guys · Haatch · Team Ignite Ventures · Allied Venture Partners · Araya Ventures
The problem
Automation tools are built for one person building alone. Two people on the same workflow means one edits and the other waits. AI is either bolted onto everything or missing entirely, and nothing stops an agent from doing something irreversible.
A managed service provider runs automations for twenty or three hundred client companies, and every tool assumes one team: one workspace, one set of credentials. Shared logins, copies drifting apart, no single place to see it run. Support means passwords.
What existed already
n8n, Make, Zapier. Excellent products, and I have studied all three properly. Single-player editing; multi-tenancy bolted on afterwards with sub-accounts and shared logins.
Most automation platforms were designed around single-player editing, with multi-tenancy and real-time collaboration added later as sub-accounts and workarounds.
What it looks like
Live recording: building an inbound revenue deal desk with parallel branches and background testing from a single voice prompt. Watch more in Tutorials →
Multiplayer canvas topology: triggers, deterministic steps, human approvals, and client workspace isolation in MSP mode.
Whose part is whose
In MSP mode an agency reaches a client's workspace only through a grant the client consented to and can revoke. Nobody shares a password.
How it is meant to behave
I wrote the documentation — around a hundred pages, all of it. These five say more about how the product thinks than any feature list would.
For any team
Nobody waits, nothing locks
Several people edit the same workflow at once and see each other's cursors. The canvas is built on CRDTs — the data structures behind multiplayer design tools — so concurrent edits merge deterministically: no canvas locking, no blocking conflicts, and changes sync seamlessly once reconnected.
You choose when it is armed
A workflow in Draft runs only when you press Run; its triggers stay off, so you can build and test without anything firing. Switch it to Live and the triggers take over. Save a version before a risky change and you can restore it in full.
AI where judgement is needed, not everywhere
Ordinary steps run the same way every time. AI steps go exactly where a decision is needed — and a human approval can sit in front of anything irreversible. Requests nobody answers expire and take their own branch instead of waiting forever.
For MSPs and agencies, on top
Access is a grant, not a login
A client's admin consents to a tier and a scope, for a fixed period. They can narrow it, never raise it, and end it whenever they like. No tier can read credentials. The audit history of the relationship is kept permanently and stays exportable by the client.
Nothing is written before you have seen what will change
Pushing a workflow into a client's workspace runs a dry run first and shows a manifest: which steps rebind to the client's own accounts, which need connecting. Agency credentials never travel. Secret values never cross a workspace boundary. Sample data is stripped from every copy.
What did not go well
- Every edit used to re-save the whole workflow, so the longer someone worked the slower it got. Fixed in August 2026 — only what changed is saved now — but workflows already carrying that weight stop growing rather than shrink. It is in the changelog, plainly.
- Approval requests nobody answered waited forever. Now they expire and take their own branch. It should have been that way from the first version.
- Retries: turn the toggle on and leave the defaults and you have asked for ten tries a minute apart, and a request the other side rejected on its merits is re-sent byte for byte. The documentation says so, in those words, because the defaults are a decision we made and the honest thing is to write down the cost of it.
What it taught me
- Defaults are product decisions. Every one of them is a call I am accountable for, whether or not anyone reads the page that explains it.
- Write for both sides. Three of the five rules above were sharpened by having to explain them to a client’s admin and an agency on the same page — the moment a rule cannot be told to both, it is not a rule yet.
- Multi-tenancy is easy to promise and expensive to mean. Consent, scope, revocation, audit history that outlives the relationship — every one is a place a shortcut would have been invisible for a year and fatal after.
Shaping the canvas
Shaping the canvas was both a product design and systems architecture challenge. Retrofitting real-time collaboration and tenant isolation onto a single-player execution engine requires rewriting the state model from the ground up. We chose CRDTs at the foundation, visual streaming topology instead of chatbot popups, and automated testing playgrounds integrated directly into the canvas.
The writing and documentation are integral to product design: if an interaction or retry model cannot be explained clearly in one page, the feature is not finished.
What it draws on
The Control Tower years: many companies' clouds run from one place, with hard walls between them. Multi-tenancy is the same problem in a different coat, and I had already spent four years on it.