Portego

Setting up a smart home is still slow and fragmented. Portego lets you and an AI agent design the floor plan together, then bind it to real devices through a local gateway.

Comment

Inspiration

Smart-home setup is still fragmented. Every brand has its own app, and those apps rarely treat the home as rooms, doors, and devices. I built Portego to try a different sequence: describe the home in conversation, refine it on a shared canvas, then connect that plan to real hardware.

What it does

Portego is a digital twin of the home. People and agents share one model of floors, rooms, and devices. A Linux gateway on the local network binds that model to real hardware, so the house you designed is the house you can switch. You can create floors, rooms, doors, windows, and devices by hand, or ask an agent to create them through WebMCP. Both write the same home document. You can drag a room after the agent makes it, and the agent can read the new layout and continue. The canvas works without an account. Login and hardware connectivity are private beta. The gateway opens an outbound WebSocket to Portego. It shows a pairing code, finds supported devices on the LAN, and lets you bind them to devices in the model. The connection is outbound, so the house does not need an exposed port or a public IP.

Why WebMCP

The home is structured data. Asking an agent to read pixels or click around a canvas would be fragile. Portego registers operations such as home.add_room, home.add_device, home.get_document, and home.apply_changes. Those tools use the same model and validation as the editor. A compatible agent is operating Portego, not a separate chat bolted onto it.

How people and agents work together

You describe a house; the agent produces a first layout. You move rooms, rename devices, add openings, or undo. The agent reads the revised document and continues from there. Once a physical device is discovered and bound, device.set_state goes through the gateway to the real device.

How I built it

The frontend is Next.js on Vercel. Konva draws the home. A validated HomeDocument is what actually gets saved. The page registers twenty WebMCP tools with document.modelContext.registerTool. Tool calls and UI actions share the same operations, validation, history, and persistence path. A FastAPI service on Render handles authentication, stored homes, gateway pairing, device bindings, and command relay. The Linux gateway connects out to the backend over an authenticated WebSocket and runs protocol adapters for local devices. Shelly is the first working adapter. Matter discovery is in the repo; Matter commissioning is not enabled yet. There is also an optional Cloudflare Worker and Durable Object relay, so long-lived gateway connections do not have to live on the API process.

Challenges

The hard part was keeping agent edits, canvas interactions, undo history, and persisted data on one model. Geometry needed real validation. An agent-generated layout is only useful if rooms, openings, and devices stay valid and still editable by hand. Local hardware added another constraint: remote control without opening inbound ports into someone's home. Guest designs also have to survive login without being duplicated or dropped.

What I learned

Structured operations are much more reliable than asking an agent to drive a visual UI. The useful loop was a strong first draft from the agent, then both of us revising the same home. I also think this only scales if devices ship agent-native. If every product keeps a private app, agents go back to guessing at UIs. Building that access has to become ordinary product work, or there needs to be a shared protocol so each brand is not inventing its own.

What's next

Public signup, OAuth for the remote Portego MCP server, a packaged Raspberry Pi gateway, more protocol adapters, and Matter commissioning. Longer term I want the agent-native part to be reusable: either make it cheap to ship a device that already exposes structured operations, or settle a protocol others can implement. Portego is one attempt at that for the home (WebMCP on the model, adapters on the gateway).

Try it at tryportego.com.

Built With

Share this project:

Updates

Submission history