MayAI — A Consumer AI Agent for Household Tasks, Starting with Food

MayAI is a consumer AI agent I co-founded in 2025: a home butler for people in the UAE, who use a separate app for every errand. Its first domain was food. From one chat message it finds restaurants and dishes in Dubai, shows their menus and builds the order. It reached a working prototype.

The challenge

Running a household in the UAE means juggling a separate app for every errand: food, groceries, cleaning, rides, across services such as Careem, Deliveroo, Keeta and JustLife. MayAI’s idea was to replace them with one conversation that coordinates multi-step tasks across those services. You say what you need in a sentence, such as “I have six friends coming over at 8 pm”, and an agent works out the steps and carries them out.

An agent that acts for a consumer has to earn trust in ways a chatbot doesn’t:

• It has to act. Saying “let me look into that” and then doing nothing is worse than no answer.
• It can’t invent anything. A dish that isn’t on the menu, or a price that isn’t real, becomes an order nobody can fulfil.
• It has to know when to ask. “Add the burger” is clear when one burger is on screen, and a guess when there are three.
• Its data is someone else’s. Restaurant and menu data arrives large, nested and inconsistent, and every extra field sent to the model costs time and money.

What we built

• The app. A mobile-first web app that installs like a native one, in English and Arabic with a right-to-left layout. It covers sign-up, a short onboarding (name, monthly budget, preferred services), a home screen with suggestions and active orders, the chat, the cart, checkout and order history.
• The chat. Replies arrive with cards and quick-reply options. A restaurant card opens its menu, and a dish card adds the dish to the order.
• The agent. One agent, built on Microsoft Agent Framework in .NET and running OpenAI models through OpenRouter. It works with six tools: a free-text search for restaurants and dishes, a filter by cuisine, diet and sort order, a list of the filters available, a restaurant’s menu, the cart, and a memory of the user’s preferences.
• Live data. Restaurant and menu data came live from Careem. A small Node.js service of our own sat in between and reduced each response to plain restaurant and menu records.
• Memory. Each user’s conversation is saved on the server and restored with every message, so it can be picked up where it left off. Lasting preferences, such as allergies, budget habits and things the user won’t eat, are saved through the memory tool.
• Checkout. In the prototype, checkout is simulated. The user fills in the delivery details and confirms, and the order is recorded, but no payment is taken and nothing is sent to a restaurant.

Keeping the agent honest

• The model returns IDs, and the server builds the cards. Every reply is a JSON object in a fixed schema: the agent’s reasoning, a message, up to five quick-reply options, and the IDs of the items it wants to show. The server looks each ID up in what the tools returned during that request and builds the card from that data. An ID that no tool returned is dropped, so a dish the model made up can’t appear on screen.
• Act first, then speak. The agent’s instructions tell it to call the tool, read the result and only then answer, and never to announce what it is about to do.
• Ask when it isn’t sure. If the user says “add the burger” and the last search returned several, the agent leaves the cart alone and asks which one. If the user asks for a change it can’t pass on, such as “no onions”, it adds the dish and says so.
• Widen an empty search. When a search comes back empty, the agent tries a broader one and says what it did.
• Reason before answering. Before it writes the message, the agent fills in a reasoning field: what the user wants, what it already knows, what could go wrong, and which tool gets there fastest. The app never shows it.
• Small tool results. Menus are stripped of images, tracking fields and banners before they go to the model. The server keeps what the cards need.
• One transaction per turn. The user’s message, the agent’s reply and the updated conversation are saved together. If the model call fails, none of it is saved.

My role

I co-founded MayAI. I designed its architecture and the agent, meaning the tool set, the structured reply and the server-side checks around it, and I led the build with one developer.

Outcome

• A working prototype in English and Arabic: from a chat message to restaurants, menus, a cart and a simulated checkout
• An agent design that keeps invented items off the screen, because the server shows only what a tool returned
• Not developed further: it stopped at the prototype stage, before any real ordering or payment integration

Stack

C# · .NET 10 / ASP.NET Core · Microsoft Agent Framework · OpenAI models via OpenRouter · Entity Framework Core · SQLite · SvelteKit · Svelte 5 · TypeScript · Tailwind CSS · Node.js · Express · Docker