Georgi Boby: From Michelin-Starred Kitchens To Enterprise Automation

There are environments so complex, so unpredictable, and so resistant to standardization that automating them has long been considered more theoretical exercise than practical ambition. Industrial kitchens are one of them. The variables in a professional kitchen - temperature, humidity, the precise caramelization point of an onion, the texture of a sauce mid-reduction - do not yield easily to rule-based programming. You cannot write enough conditions to capture what a trained chef knows in muscle memory.

Georgi Boby spent six years trying to solve that problem. Today, as Co-Founder and Chief Product Officer at Rilo, he is applying what he learned to a different kind of unstructured environment entirely.

Built in the Kitchen, Tested at Scale

Mr. Boby joined CloudChef, a Palo Alto-based food technology company, as a founding engineer in 2019. The company had attracted more than $20 million from investors, and the engineering challenge it had set for itself was substantial. Thermal cameras and various other sensors document the cooking process in real-time, capturing variables such as temperature, weight, water loss and color change. These measurements are translated into data points for a machine-readable file, which preserves the recipe exactly to the chef's specifications. The goal was not to program a machine to follow a recipe. It was to build a system capable of learning what a recipe actually meant by watching a master chef execute it.

Mr. Boby had arrived at CloudChef via IIT Bombay, where he studied Electrical Engineering and completed his degree in three years, one year ahead of the standard program. At CloudChef, that instinct for first-principles thinking found an outlet. Using the sensor and vision systems his team built, they captured what expert chefs did in real time and translated it into executable instructions a kitchen operator with no culinary training could follow. The chefs themselves could not distinguish the output from their own work in blind tests.

The restaurant industry was operating under significant structural pressure during this period. That's on top of rising labor costs, which 98% of restaurant operators identified as an issue for their business, according to the National Restaurant Association's 2024 State of the Restaurant Industry report. The problem CloudChef was solving was not simply one of efficiency. It was one of knowledge transfer: how do you take expertise that exists in one person's hands and mind and make it executable by someone with entirely different skills?

That question stayed with Mr. Boby long after he left the kitchen.

From Physical Systems to Product Architecture

By 2025, when Mr. Boby departed CloudChef to co-found Rilo, the engineering instincts he had developed building physical automation systems had crystallized into a clear product philosophy: the interface between a capable system and the person using it is not an afterthought. It is the hardest part of the engineering problem.

At Rilo, Mr. Boby serves as Chief Product Officer, responsible for translating that philosophy into a platform architecture that non-technical users can operate with confidence. The product challenge is not dissimilar to what he faced in food robotics. In both cases, the system has to meet the user where they are, not ask the user to meet the system where it is.

"At CloudChef, the kitchen operator did not need to understand the machine learning model," Mr. Boby said. "They needed to follow instructions that made sense to them. The same principle applies here. The person automating a sales workflow should not need to understand what is happening underneath. They should just be able to describe what they want."

The Architecture Behind the Interface

The system Mr. Boby designed at Rilo rests on three technical components. The Natural Language Workflow Engine interprets plain-language task descriptions and converts them into executable automation logic without requiring users to specify conditions or write code. The Model-Agnostic AI Orchestration layer selects from available AI models based on what a given task requires, allowing the platform to route work to whichever model is best suited without locking into a single provider. The Browser Vision Automation component allows Rilo to interact with any web-based tool visually - the way a human operator would - navigating interfaces it has never been specifically integrated with, extending its reach beyond what traditional API-based automation can access.

That third component carries a direct line back to his robotics work. A machine that can watch how a human navigates a piece of software and replicate that navigation is solving a structurally similar problem to a machine that watches a chef reduce a sauce and produces instructions for someone else to do the same. In both cases, the system has to perceive what is happening, extract the intent behind it, and produce a reliable output that someone without the original expertise can execute.

Backing and Early Traction

Rilo, developed under the parent company Workatoms Inc., has attracted investment from Peak XV Partners (formerly Sequoia Capital India and Southeast Asia). Surge is a seed partner for outliers who see the world differently. A community where builders learn and grow together. A platform designed to help founders lay the foundations for enduring companies. Rilo is among the companies that have gone through the program. The company is based in Mountain View, California. Early customers have included companies across sales operations and marketing functions, with at least one reporting month-over-month growth it attributed directly to automations built on the platform.

The market for enterprise automation software is large and competitive, with established players and a growing number of AI-native entrants contending for the same buyer attention. For Mr. Boby, the differentiator is not the capability of the underlying technology. It is whether the product layer built on top of that technology is engineered well enough that the people who need it most can use it without assistance.

The Product Is the Problem

Enterprise software has a long history of systems that worked in principle but failed in practice because the gap between what they could do and what an ordinary user could get them to do was never adequately closed. Mr. Boby's view, shaped by years of building automation systems that had to perform reliably in the hands of people with no technical background, is that closing that gap is a product engineering problem as much as an AI problem.

Getting the interface right is not a design decision that follows from building a system that works. It is the condition under which the system can work at all. The kitchen taught him that. The question is whether the same lesson translates at the scale of enterprise software.

"The hardest part of automation is not the automation," Mr. Boby said. "It is building something that the person who actually needs it can use without needing to ask for help. That has been the problem from the beginning. We are still working on it."