Building a self-improving agent: Owner Agent

Restaurant owners are some of the most customer-obsessed operators I’ve ever met. They usually talk to their customers dozens of times a day. That closeness gives them a great understanding of what their customers need.

At Owner, we build products to help restaurants grow. Our customers range from highly technical operators running dozens of locations to owners who would rather spend their time making delicious food and taking care of guests than looking at a dashboard. Okay, all of them would rather take care of their guests than look at a dashboard.

When we set out to build Owner Agent, we wanted to show our customers the same care and thoughtfulness that they show their guests.

Running a restaurant is demanding. Our customers don’t always have the time to dig into how their business is doing.

And when they need to make a menu change or toggle off their online availability due to a big dinner rush, digging around in a dashboard or app is the last thing they want to do.

Our vision for Owner Agent: customers should be able to get anything they need from Owner as easily as sending a text.

We're getting there. Over the last two months, we’ve brought Owner Agent to GA, powered tens of thousands of conversations, and seen customer usage grow by ~30% week over week since launch.

This post walks through the product and architectural decisions behind Owner Agent, including how Owner Agent is integrated across Owner and how it’s set up to keep improving.

Where customers meet Owner Agent

Customers start using Owner Agent while they’re still becoming customers.

Our Grader helps restaurant owners understand how their website performs. It evaluates Google search visibility, CRO factors, and how the restaurant compares with its local competitors.

Through Grader, a swarm of agents researches the restaurant across the internet, gathering its brand identity, local details, menu, and photos. The Grader feeds our AI Website Builder, which rebuilds their website in near real time, turning it into a best-in-class website that will grow the restaurant’s sales.

Owner Agent is a companion throughout the experience, helping customers quickly refine their website in plain language.

Once they’re using Owner, customers can turn to Owner Agent in our dashboard and mobile app.

Some owners will never open a dashboard. From the app, they can make an operational change between lunch and dinner in one sentence and approve it on one card.

Others run several locations and want to go deeper. They can ask how their business is doing, and Owner Agent responds with insights from the restaurant’s data.

Learning from our first users

We started dogfooding Owner Agent with our customer-facing teams months before the public release.

They were some of the best early users we could have hoped for. They were vocal about what they needed and brought us the problems they were solving for customers. Their feedback helped us iterate quickly and see whether the agent was useful.

Menu setup is one of my favorite examples. Our launch team used to drag food photos into ChatGPT one at a time to figure out which menu item each photo represented. Now, they just drop a menu PDF and a Google Drive folder of photos into Owner Agent.

[Please don’t ask me what our launch team did before LLMs existed.]

We wanted to prioritize the capabilities that would make the biggest difference for customers. We looked to our hundreds of thousands of historical support cases.

With these cases, we could see what the owner asked for, how our team handled it, and how long it took. This gave us a starting point to understand what to build, and what to prioritize.

We built an “Eval Dash” to explore those cases and prioritized them by how much support time it takes to resolve them.

Most of those cases ask for the same handful of things in different combinations.

Once we grouped them, hundreds of thousands of cases came down to about 2,000 distinct operations, like changing hours or issuing a refund. Those 2,000 operations became the evals we test Owner Agent against.

Choosing our agent stack

We built Owner Agent on the Vercel AI SDK. It’s model agnostic, so we can move between providers and models as they improve without rewriting Owner Agent. It has great developer experience and support, and it’s one of the most widely adopted agent frameworks, so the patterns and answers our engineers need are usually already out there.

On top of the SDK, John Harlow, a senior engineer on our Agents team, built ownerTool.

The AI SDK’s tool describes something a model can call: a description, an input schema, and a function to run. That’s enough to call a function, but not enough to safely change a restaurant’s business. ownerTool makes every tool also declare who is allowed to run it, whether it reads or changes data, how much damage a wrong call could do, and whether the owner has to approve it first. With that, a product team can take an operation that already exists, like setting holiday hours, and give it to Owner Agent.

export const createSpecialHoursTool = ownerTool({
  owner: {
    identifier: 'create-special-hours',
    authZ: ({ user }) => user.can('create', 'location.special-hours'),
    effect: 'mutation',
    consequence: 'major',
  },
  description: 'Create holiday hours or a one-day closure for a location.',
  inputSchema: z.object({ locationId, day, month, year, hours }),
  outputSchema: z.object({ specialHoursId, locationId, day, month, year }),
  toolApproval: 'user-approval',
  execute: (input) => SpecialHours.create(input),
})

• authZ checks the same permissions the user has everywhere else in Owner. If they can’t create special hours in the dashboard, Owner Agent can’t create them either.
• effect says whether the tool only reads data (query) or changes it (mutation).
• consequence says how costly a wrong call would be, from none to catastrophic. Looking up today’s sales is harmless. Closing a store on the wrong day is major, because it costs a day of sales.
• toolApproval makes Owner Agent stop and ask the owner before the tool runs.

That risk disclosure bubbles up through Owner Agent’s patterns of interaction framework, to determine when operations need extra confirmation.

Owner Agent as a client

Our historical support cases span the breadth of Owner’s products.

Our Agents team can’t build and maintain every capability on its own.

We treat Owner Agent as another client of our platform, alongside the dashboard and mobile app. Owner Agent calls the same services that power those surfaces, building on the same business logic and authorization patterns.

The Agents team owns the shared framework, approvals, observability, and eval infrastructure. Product teams know their domains and contribute the tools and capabilities to Owner Agent.

Our website team, for example, exposes the operations customers need to update their website.

We group capabilities into domains such as menu, website, and payments. A domain is how a product team ships a capability into Owner Agent as one unit, built with ownerDomain.

export const websiteDomain = ownerDomain({
  name: 'website',
  featureFlag,
  enabledWhen: capabilityStatusIs('website-builder', 'active'),
  instructions,
  skills: ownerSkillSet({ websiteSkill }),
})

It bundles the domain’s tools, the instructions that tell Owner Agent how and when to use them, and skills for longer tasks. Importantly, every domain has a feature flag, so a team can roll it out restaurant by restaurant and turn it off instantly if something goes wrong. enabledWhen only loads a domain for restaurants that use that product, so a brand without our website builder never sees website tools.

Growing Owner Agent across the product

Making Owner Agent a client has shifted how our product teams work.

When a team ships a feature for customers, we now think about how customers can use it through Owner Agent.

As teams have contributed, Owner Agent has grown beyond its initial menu and website capabilities. As of October 2026, Owner Agent has 241 tools across 27 domains, including sales reporting, locations, and custom domains.

Making Owner Agent’s actions understandable

Clarity of operation has been the biggest goal since we started building Owner Agent. It means that whenever Owner Agent proposes any action, it’s very clear what will happen when you hit “approve.” This is so important because tool call approvals are much more common in Owner Agent than in ChatGPT.

I think of it as UI design for a genie. The genie is going to grant whatever wish you make. But before the wish is granted, you need to make sure you understand what you’re getting out of the wish.

Cole Derochie, our Agents design lead, has designed patterns of interaction for clarity of operation.

He views an agent conversation as a stream of four kinds of moments. For each one, Claude, ChatGPT, Cursor, and the MCP spec have converged on a small set of shapes.

Patterns in action

Owners often send requests like this one.

Remove the pollo taco from the menu at the Miramar location. Also add tomatillo as a salsa option there. In Atlanta, raise the price of guac by $1.

A card that says “update menu” doesn’t give our customers enough context to be confident that Owner Agent will make the changes they intend. Through our clarity of operation framework we:

1. Get approval for every change. The card shows each item, location, and change, with the before and after in plain language. Owners can approve or reject each row on its own.
2. Act with the same permissions as the user. Tools use the same RBAC as the rest of Owner.
3. Hand off to a support rep when Owner Agent can’t finish the job. Our support reps pick up where Owner Agent left off, with the full conversation and context.

The feedback loop

When customers use Owner Agent in ways we haven’t built tools to handle yet, here’s what the feedback loop looks like to get Owner Agent working great for that use case the next time.

Scaling Owner Agent

At first, we gave the model every tool definition and every domain instruction on every request.

Do things that don’t scale, right?

Past 200 tools, that context bloat started to hurt quality and drive up cost, so we added tool search and skills.

With tool search, tool definitions stay out of the model’s context until Owner Agent asks for them. A request to raise the price of guac loads 3 menu tools, not all 241 tools.

Similarly, skills let us give Owner Agent instructions for a specific task without putting every instruction in every request.

John also wrote up these patterns and more, like routing and handoffs between agents, in Some agent patterns.

Running Owner Agent in the background

Owner Agent has to keep working after a customer closes the app or a request times out.

In these cases, we run it headless.

For example, an owner might ask Owner Agent to match 80 photos to their menu, and then lock their phone.

A background worker picks up the job with that user’s permissions. If something needs approval, it sends a push notification to the owner, and idles until the owner comes back to the conversation.

Lessons we’ve learned

• Start from requests customers have already made (support history) to anchor on known needed capabilities.
• Match the agent’s permissions to the user’s.
• Focus on clarity of operation. Make every change easy to confirm, with one row per change, plain language, and nothing happening before approval.
• Invest in observability at step 0.
• Build a self-improving agent. Turn every failure into an eval.

Proactive is the next frontier

Owner Agent is reactive today. The customer experience starts when Owner Agent is prompted.

We want Owner Agent to be a proactive partner in our customers’ growth.

Soon, it will notice opportunities to improve their business, bring those opportunities to the customer with context, and make the next step easy to approve.

We’re building toward the team of AI executives described in our Series C memo and Series D memo.

If you’re interested in building agents at scale and going deep with customers, we’re hiring.