![\"Owner](\"https://production.owner-engineering-blog.com/images/posts/owner-agent-gif-3.gif\")
\n\n Owner Agent needs breadth to handle both the common operational tasks and the more advanced\n questions.\n
\n\n Common operational tasks: Some customers won’t use the Owner dashboard, or any\n dashboard. They will call support even to change their restaurant’s hours, which takes 3 clicks in\n our dashboard. They’ll still call. We want to be super available to them with no hold time.\n
\n\n More advanced questions: Some customers run dozens of locations. They want to\n understand trends, like what's moving on their menus. They want to know how many corporate\n customers they serve, and keep track of what their competitors are doing. There’s room for\n sophistication in helping them grow their business.\n
\n\n\n In the medium term, Owner Agent will also become proactive, volunteering to take actions to grow\n each customer’s business (e.g. create a coupon code in time for National Taco Day to drive app\n orders). Owner Agent will be the gateway to the entire breadth of the platform.\n
\n\n So we had to decide where to start - what to prioritize, which classes of problems to solve now\n versus later.\n
\n\n\n We've started by framing Owner Agent’s first big \"customer\" as our own customer-facing teams: 100+\n users, thousands of conversations per week.\n
\n\n They use Owner Agent to help with time-consuming support tasks - for example, setting up a new\n menu. In the past, our reps had to manually review a Google Drive with hundreds of food images,\n half of them unlabeled, trying to eyeball which image corresponded to which menu item. That pain\n is gone. Owner Agent has vision as one of its modalities; it offers its best guess to match menu\n items to photos. It also does the previously time-intensive work of deconstructing a menu PDF into\n items, modifiers, and assets.\n
\n\n Soon Owner Agent will be customer-facing. This isn't because our reps aren't great: in fact\n customer satisfaction exceeds 90%, and customers often mention how much they love our reps. But at\n peak times, callers can still wait on hold for 15 to 30 minutes. You shouldn't wait 30 minutes to\n change your hours just because the dashboard feels intimidating. Ideally Owner Agent will cut into\n those wait times.\n
\n\n3 primitives run through the rest of this post. Our team looks at them as a hierarchy:
\nFor example, suppose the customer says:
\n\n Remove the pollo taco from the menu at Miramar, add tomatillo as a salsa option there, and raise\n the price of guacamole in Atlanta by $1.\n\n
\n Even our human support reps would write up an email to confirm. The channel shapes how a tool call\n gets represented, and each channel has its own human in the loop.\n
\n\n It’s a hierarchy because, for instance, the channel is upstream of how Owner Agent gets approval\n to call a tool.\n
\n\n\n The approval is the agent saying it's about to make an operation and needs to show you first, then\n deciding which channel that comes into: UI or SMS. For example, imagine you call in over the phone\n wanting to make a meaningful change to your menu, including changing modifiers. We'll repeat the\n whole set of operations back to you: the intake, then the confirmation, out loud - but there's\n still room for error. We convert the set of operations into plain language and send it over SMS,\n confirming all the changes. So when you call in, you become the human in the loop. :)\n
\n\n That isn't an industry convention. But it's what our customers need, because we can't count on\n them to have our mobile app.\n
\n\n But say you do have the app. In that case, we can link you to your account and trigger a push\n notification that shows you exactly where to find that feature.\n
\n![\"A](\"https://production.owner-engineering-blog.com/images/posts/owner-agent-push-notification.webp\")
\n \n This goes for our reps too. They can say: “I'm happy to do this for you. But if you'd rather not\n talk to me, I just dropped a push notification into your phone.”\n
\n\n It’s educating the user inside a flow that was going to happen anyway, showing a better way to get\n there next time.\n
\n\n\n We have converted our historical support cases into a provable mechanism to demonstrate that the\n agent has the capabilities to impact these cases. That mechanism is our eval dash.\n
\n\n With help from our BizOps team, we’ve mined Owner's 224,000+ historical support cases from\n Snowflake and clustered them into a small set of scorable capabilities.\n
\n![\"Eval](\"https://production.owner-engineering-blog.com/images/posts/eval-dash-screenshot-1.webp\")
\n \n The top-level view covers about 25% of our case categories. Take menu updates: roughly 10,000 of\n our 224,000 cases, about 5%, came from someone trying to change a menu. Each case carries 3 levels\n of categorization: primary, secondary, tertiary. We counted 414 distinct reasons at last check.\n
\n![\"Eval](\"https://production.owner-engineering-blog.com/images/posts/eval-dash-screenshot-2.webp\")
\n \n We rank the work by support time, not case count. A family can match another in volume but take\n 10x the number of hours. So we show both and prioritize by time. That's why the target leads with\n time-to-close. We want the agent to absorb about 50% of the time our cases take to resolve.\n
\n\n\n The cases overlap more than they look. Say one case needs 3 operations and another needs 4. If 3\n of them match, the pair shares only 4 distinct operations. The count collapses. Today it looks\n like 224,000 cases reduce to around 2,000 discrete operations. Build those 2,000, and we cover the\n next 1,000 cases that lean on them.\n
\n\n One distinction: a capability isn't the same as a solved case. Hand the agent a case with 70\n moving parts and it may need to break it up, or punt, as a human might too. So we track 2 axes:\n the capability on one, reasoning through a specific case on the other.\n
\n\n I've stubbed about 1,000 evals by hand. Next I wire them into the codebase and run them in\n Buildkite. Then we run the agent against them. A second LLM grades each run against the expected\n output and tools, and we watch the trend. In production, a separate LLM checks every response\n against the tools the agent called. If the agent says \"I checked your account\" but never called\n the lookup, we catch it.\n
\nIf the agent passes the evals tied to a set of cases, we can say we solve those cases.
\n\n\n AI has shredded so many barriers to building: with the novelty of capable coding agents, we\n started to see a rapid expansion of internal apps and prototypes. We wanted anyone on the team to\n be able to build an app that could use internal data, connect to an LLM, and be shared securely.\n
\n\n That was the vision for Zeus. We just crossed more than 500 internal apps & prototypes running\n on the platform, which is ~3x the headcount of our engineering, product and design org.\n
\n![\"\"](\"https://production.owner-engineering-blog.com/images/posts/zeus-apps.webp\")
\n\n Some Zeus apps are universally used and will get their own blog posts in the future, like our\n internal coding agent, Forge.\n
\n![\"\"](\"https://production.owner-engineering-blog.com/images/posts/zeus-forge.webp\")
\n\n The PLG team built the PLG HQ, which drops confetti on demo day and gives everyone a bear to\n control.\n
\n![\"\"](\"https://production.owner-engineering-blog.com/images/posts/zeus-plg-hq.webp\")
\nThe design team made an app for brand assets:
\n![\"\"](\"https://production.owner-engineering-blog.com/images/posts/zeus-brand-assets.webp\")
\nWe all needed the Owner Atlas app, so we could search for food near us:
\n![\"\"](\"https://production.owner-engineering-blog.com/images/posts/zeus-owner-atlas.webp\")
\nAnd one person really needed to go back to '95:
\n![\"\"](\"https://production.owner-engineering-blog.com/images/posts/zeus-win95.webp\")
\nWe built Zeus to solve 4 problems.
\n\n First problem: internal apps were being deployed in all kinds of ways. Before\n Zeus, new internal apps were appearing constantly with different hosts, databases, and vendors. We\n wanted one frontend system, with everything deployed in the same place with the same database\n setup. With Zeus you click “generate app,” and a minute later you have a web app (Tanstack Start\n or Astro, react, server-side rendering, file-based routing). Zeus makes a GitHub repo, provisions\n a Postgres database and a storage bucket, scaffolds the template into the repo, injects the\n secrets, and commits. GitHub Actions deploys it, and Zeus watches to make sure the first\n deployment completes.\n
\n\n All apps run on Cloudflare's Workers for Platforms. They share one namespace, and a single\n gateway worker sits in front and routes each request to the right app. This gives us room for\n 10,000 apps before the next limit. Everything lives under one domain, and each app is a subdomain\n of owner.sh.\n
\n2nd problem: giving every app safe access to our data.
\n\n Zeus gives every app built-in access to our systems and holds the credentials itself without a\n vendor key. It calls a Zeus proxy, and Zeus handles auth, rotation, and logging. Out of the box,\n an app can:\n
\n\n 3rd problem: auth, app permissions and security. Auth runs through Shibboleth,\n our sign-in portal. It uses our Okta SSO, lets in only owner.com accounts, and is completely\n separate from our production product auth. The gateway worker checks auth on every request before\n it reaches an app for extra security. If you're not signed in, it sends you to Shibboleth\n first.\n
\n\n Permissions are per app. An app is either open to anyone at the company or limited to people you\n grant in. Each grant carries a role, member or admin. You can bundle users into a group and grant\n the group across several apps. You manage all of it from the app’s page. Apps you share\n company-wide show up in the gallery.\n
\n\n 4th problem: we needed to be able to update all the apps agentically as we make\n updates in the future. Our migrations system creates an isolated session on a throwaway VM for\n each app. The agent clones the app, makes the change, and opens a single PR. A manager session\n reviews all the PRs, retriggers updates when needed, and merges updates. We use this to bump\n dependencies, patch vulnerabilities, and roll out shared changes/upgrades. We can also run a\n read-only version that just reports back for compliance or tracking purposes.\n
\n\n All app logs drain into Datadog so users can debug their apps and the company has visibility into\n what's running. Zeus has a CLI for developers to manage and debug their apps.\n
\n\n The result is that when you plug your AI coding tool into a Zeus app, it doesn’t need to ask you\n configuration questions that you may or may not be able to answer. Auth, database, deployment, CI,\n monitoring, environment. That’s all decided. You just describe what you want to build.\n
\n\n App growth has been steadily increasing since the early days of the Zeus launch. Our teams can\n just ship apps instead of spending time evaluating tools and onboarding to new services, with just\n a few exceptions. Adoption across our team has been pretty organic since it’s so quick and\n painless to get started on the platform.\n
\n\n Every assumption we made about how small this would stay was wrong. And maybe this connects to\n where things are generally headed: the boundaries between engineering, design, and product are\n blurring. More people default to building. They see a problem and now have the tools to go do\n something about it. It used to require getting an engineer’s time, getting approval, getting API\n keys, getting access to systems. Zeus removes all of that. \n
\nThe first version was way too ambitious and overcomplicated.
\n\n We tried to build our own system for deployments and CI, basically bypassing GitHub Actions. Users\n would push code directly into Zeus for processing. Presumably this would let us analyze code and\n add security guardrails. But that ended up being too restrictive for all the edge-cases of what\n people wanted to build. We scrapped it and went with the generator approach we have now, in which\n Zeus scaffolds a real repo with real CI and gets out of your way.\n
\nAt first, we didn't plan for how fast it would grow.
\n\n We were limited by how many workers we could deploy on one account. When we started, we barely\n thought about it, figuring it’d be a long time before we hit the limit. Then we passed 100 apps,\n and it became clear we’d blow through that limit quickly. That forced a migration to Workers for\n Platforms while also keeping all the existing standalone workers running.\n
\nWe needed a way to maintain hundreds, maybe thousands, of apps.
\n\n The obvious risk with a platform like this is that apps get built, deliver some value, and then\n get forgotten. With 500+ apps and no guarantee each one has a long-term owner, that’s a problem.\n We built the migrations system where we can write a prompt for an AI agent and run it against\n every app on the platform at once. The apps don’t rot because the platform itself maintains them\n to a minimum standard.\n
\nExpectations and needed features grew quickly
\n\n Zeus began on a pure whim, and very much a side project to day-to-day responsibilities at Owner.\n Within a few short months, HR and finance built apps with highly sensitive data. A few apps were\n built that eclipsed the capacity of our original SQLite databases, and some of our builders\n clamored for dedicated compute features. Luckily, Owner has a supportive organization and we’ve\n managed to scale Zeus with contributions from VP Eng (thanks Max!) and now a second dedicated team\n member, Lucas.\n
\nIf you’re going to build this for your team:
\n\n You can’t predict what people will build. You can’t predict how complex the apps will be. You\n can’t predict the volume of apps. People will build more complex apps than you expect. They will\n build more apps than you expect. They’ll build single-purpose apps that will be used once in a\n meeting to make a decision, and then never again. They’ll build apps that become a key part of\n every demo and sales call we do across the company every day.\n
\n\n Everything that used to be impossible can now be built, and this means people will also build\n buggy slop, or accidentally extend beyond key boundaries. For better or worse, it’s an arms race\n between the platform and the builders. Don’t underestimate someone’s crazy off-the-rails agent.\n
\n\n As a starting point, pick the batteries that matter. For us, this was auth, hosting, and\n databases. That’s what people were repeatedly getting stuck on. If we’d tried to ship 30 different\n platform features on day 1, it probably would’ve been too complicated and nobody would have used\n it. Start with what people are already struggling with.\n
\nThanks for reading
\n\n Building Zeus has been a blast, and a great learning experience. For better or worse, our industry\n has completely changed. As builders, we need to ensure we embrace AI tools and new ways of\n working, and I believe that we can use them as a force for good for our mission, customers, and\n team. I’m grateful to Owner for the trust to build aggressively, explore the frontier, and to\n continue scaling what we’ve found works. Hopefully this can inspire others to get out there and\n build.\n
", "image": "https://production.owner-engineering-blog.com/og/zeus.png", "date_published": "2026-08-01T12:00:00Z", "date_modified": "2026-08-01T12:00:00Z", "authors": [ { "name": "Ryan Selden", "avatar": "https://production.owner-engineering-blog.com/images/authors/ryan-selden.webp" } ], "tags": [ "App" ] }, { "id": "https://production.owner-engineering-blog.com/menus-are-harder-than-they-look", "url": "https://production.owner-engineering-blog.com/menus-are-harder-than-they-look", "title": "Menus Are Harder Than They Look", "summary": "Modeling modifiers, combos, and \"no pickles, extra sauce\" without losing your mind, or your schema.", "content_html": "\n A menu looks like a list of items with prices. It is actually a graph: items own modifier groups,\n modifier groups own options, and options can open their own nested groups. A burger is simple\n until someone wants it as a combo, with a side swap, no pickles, and extra sauce that costs fifty\n cents.\n
\n\n We started with a flat table of items and a JSON blob of options. It shipped fast and broke the\n first time a restaurant asked for a half-and-half pizza. Pricing rules lived in the blob, so every\n client had to reimplement them.\n
\n\n Modifier groups are first-class records with min and max selection rules, and items reference\n them. Pricing is resolved server-side from the same rules the POS uses, so the cart total and the\n kitchen ticket always agree.\n
\nIf two systems calculate the same price, one of them is wrong.\n
The graph is harder to query, but it is the only model that survived contact with real menus.
", "image": "https://production.owner-engineering-blog.com/og/menus-are-harder-than-they-look.png", "date_published": "2026-07-28T12:00:00Z", "date_modified": "2026-07-28T12:00:00Z", "authors": [ { "name": "Adam Guild", "avatar": "https://production.owner-engineering-blog.com/images/authors/adam-guild.webp" } ], "tags": [ "Code" ] }, { "id": "https://production.owner-engineering-blog.com/the-6pm-problem", "url": "https://production.owner-engineering-blog.com/the-6pm-problem", "title": "The 6pm Problem", "summary": "How we handle traffic that's flat all day and then goes vertical for ninety minutes, every single night.", "content_html": "\n Restaurant traffic has one shape: nearly nothing until late afternoon, then a wall at dinner.\n Across time zones the wall rolls from east to west, and on Fridays it is taller. Averages are\n useless here; the only number that matters is the peak minute.\n
\n\n Autoscaling reacts in minutes, but the dinner rush ramps in seconds. We stopped waiting for\n metrics and started scaling on the clock, warming capacity thirty minutes ahead of each region's\n rush.\n
\n\n We alert on p99 checkout latency during the rush window only. Outside it, the same latency would\n page someone for traffic that does not exist.\n
\nThe result is boring dinners, which is exactly what a restaurant wants from its software.
", "image": "https://production.owner-engineering-blog.com/og/the-6pm-problem.png", "date_published": "2026-07-24T12:00:00Z", "date_modified": "2026-07-24T12:00:00Z", "authors": [ { "name": "Adam Guild", "avatar": "https://production.owner-engineering-blog.com/images/authors/adam-guild.webp" } ], "tags": [ "Code" ] }, { "id": "https://production.owner-engineering-blog.com/we-rewrote-our-checkout-flow", "url": "https://production.owner-engineering-blog.com/we-rewrote-our-checkout-flow", "title": "We Rewrote Our Checkout Flow and Conversion Went Up 11%", "summary": "Three months, four abandoned prototypes, and the one change that actually mattered.", "content_html": "\n Our checkout had five steps and a drop-off at every one of them. We assumed the fix was fewer\n steps, so we built a one-page checkout. Conversion did not move.\n
\n\n Session recordings showed people leaving at the pickup-time picker. The default was ASAP, but the\n estimate was hidden until the final step. Customers who discovered a 45-minute wait at the end\n left.\n
\nPeople don't abandon forms. They abandon surprises.\n
\n We moved the ready-time estimate to the top of the cart and kept it live as items changed. That\n single change accounted for almost all of the 11% lift.\n
", "image": "https://production.owner-engineering-blog.com/og/we-rewrote-our-checkout-flow.png", "date_published": "2026-07-20T12:00:00Z", "date_modified": "2026-07-20T12:00:00Z", "authors": [ { "name": "Adam Guild", "avatar": "https://production.owner-engineering-blog.com/images/authors/adam-guild.webp" } ], "tags": [ "App" ] }, { "id": "https://production.owner-engineering-blog.com/talking-to-pos-systems-from-2004", "url": "https://production.owner-engineering-blog.com/talking-to-pos-systems-from-2004", "title": "Talking to POS Systems From 2004", "summary": "A field guide to integrating with software that predates JSON.", "content_html": "\n Many of the restaurants we work with run point-of-sale software that was installed before\n smartphones existed. It works, the staff know it, and nobody is replacing it for us. So we\n integrate.\n
\n\n Every integration sits behind an adapter that translates the POS into our own order model. The\n rest of the platform never sees vendor quirks. A small agent runs inside the restaurant network\n and holds an outbound connection to us, so we never ask anyone to open a firewall port.\n
\nNone of this is glamorous, but it is why an order placed online shows up in the kitchen.
", "image": "https://production.owner-engineering-blog.com/og/talking-to-pos-systems-from-2004.png", "date_published": "2026-07-15T12:00:00Z", "date_modified": "2026-07-15T12:00:00Z", "authors": [ { "name": "Adam Guild", "avatar": "https://production.owner-engineering-blog.com/images/authors/adam-guild.webp" } ], "tags": [ "Code" ] }, { "id": "https://production.owner-engineering-blog.com/why-we-still-render-on-the-server", "url": "https://production.owner-engineering-blog.com/why-we-still-render-on-the-server", "title": "Why We Still Render on the Server", "summary": "Restaurant sites get opened on cracked phones over gas-station wifi. That shapes every stack decision we make.", "content_html": "\n Our median visitor is not on a new laptop. They are hungry, on a mid-range phone, on a weak\n connection, deciding in seconds whether to order or open a delivery app instead.\n
\n\n We give every storefront a strict budget: meaningful content in under two seconds on a throttled\n 4G profile. Client-rendered pages could not meet it once a menu passed a few hundred items.\n
\nThe fastest JavaScript is the JavaScript you don't send.\n
\n Server rendering is not fashionable advice, but for our customers it is the difference between an\n order and a bounce.\n
", "image": "https://production.owner-engineering-blog.com/og/why-we-still-render-on-the-server.png", "date_published": "2026-07-10T12:00:00Z", "date_modified": "2026-07-10T12:00:00Z", "authors": [ { "name": "Adam Guild", "avatar": "https://production.owner-engineering-blog.com/images/authors/adam-guild.webp" } ], "tags": [ "Code" ] }, { "id": "https://production.owner-engineering-blog.com/building-an-ai-phone-agent", "url": "https://production.owner-engineering-blog.com/building-an-ai-phone-agent", "title": "Building an AI Phone Agent That Doesn't Embarrass the Restaurant", "summary": "Latency budgets, hallucination guards, and knowing when to hand off to a human.", "content_html": "\n Restaurants miss a lot of calls during the rush. An agent that answers can take orders and answer\n questions, but a bad answer costs more than a missed call.\n
\n\n Callers hang up on silence. We budget under a second from end of speech to the start of a reply,\n which rules out long reasoning chains on every turn.\n
\nThe best thing an agent can say is \"let me get someone for you.\"\n
\n We measure success by orders completed without a correction in the kitchen, not by how human the\n voice sounds.\n
", "image": "https://production.owner-engineering-blog.com/og/building-an-ai-phone-agent.png", "date_published": "2026-07-06T12:00:00Z", "date_modified": "2026-07-06T12:00:00Z", "authors": [ { "name": "Adam Guild", "avatar": "https://production.owner-engineering-blog.com/images/authors/adam-guild.webp" } ], "tags": [ "App" ] }, { "id": "https://production.owner-engineering-blog.com/one-codebase-ten-thousand-storefronts", "url": "https://production.owner-engineering-blog.com/one-codebase-ten-thousand-storefronts", "title": "One Codebase, Ten Thousand Storefronts", "summary": "Multi-tenant theming when every owner wants their logo bigger.", "content_html": "\n Every restaurant wants a site that feels like theirs. We want one codebase we can ship to all of\n them on the same day.\n
\n\n A storefront theme is a small set of tokens: colors, type scale, radius, and a handful of layout\n choices. Components read tokens, never hardcoded values, so a new brand is a record rather than a\n branch.\n
\n\n Visual regression runs against a sample of real tenant themes on every release. If a change looks\n wrong on a dark theme with a long restaurant name, we find out before the restaurant does.\n
", "image": "https://production.owner-engineering-blog.com/og/one-codebase-ten-thousand-storefronts.png", "date_published": "2026-07-01T12:00:00Z", "date_modified": "2026-07-01T12:00:00Z", "authors": [ { "name": "Adam Guild", "avatar": "https://production.owner-engineering-blog.com/images/authors/adam-guild.webp" } ], "tags": [ "Code" ] }, { "id": "https://production.owner-engineering-blog.com/the-case-against-the-delivery-marketplace", "url": "https://production.owner-engineering-blog.com/the-case-against-the-delivery-marketplace", "title": "The Case Against the Delivery Marketplace", "summary": "What we learned building direct ordering, told through a year of funnel data.", "content_html": "\n Marketplaces are great at finding new customers and expensive at keeping them. A year of funnel\n data from direct ordering showed us where the value actually sits.\n
\n\n We focused on the moments after the first order: a receipt that links back to the storefront, a\n loyalty balance that only exists direct, and search results that point to the restaurant's own\n site.\n
\nDiscovery is rented. Loyalty is owned.", "image": "https://production.owner-engineering-blog.com/og/the-case-against-the-delivery-marketplace.png", "date_published": "2026-06-26T12:00:00Z", "date_modified": "2026-06-26T12:00:00Z", "authors": [ { "name": "Adam Guild", "avatar": "https://production.owner-engineering-blog.com/images/authors/adam-guild.webp" } ], "tags": [ "News" ] } ] }