Lyzant logoLyzant
Back to selected work

Ecommerce operations

Medusa Voice Agent: Operating ecommerce admin through natural language

Lyzant built a voice-operated AI agent inside Medusa Admin so administrative work can be requested in ordinary language. The agent interprets spoken intent, translates it into Medusa actions, and keeps the interaction inside one live conversation.

Organization
Lyzant
Technology
Medusa.js, OpenAI SDK, OpenAI Voice SDK
Live website
Visit website
Industry
Ecommerce operations
medusa-openai

Platform highlights

This project adds a voice-operated AI agent to Medusa Admin. Instead of navigating through several screens for every administrative task, an operator can describe the work in natural language and continue the exchange as a live voice conversation.

The agent connects spoken requests to actions available in Medusa. It can interpret the goal, identify the information required for the task, ask for missing details, execute the relevant admin operation, and explain what happened in the same session.

The interface is built around conversation, but the underlying work remains structured. Each action is represented as a defined tool with known inputs and outputs. Medusa remains responsible for the commerce data and business operation, while the agent handles intent, tool selection, and the dialogue around the task.

The challenge

Commerce administration is precise work. Product, inventory, pricing, customer, and order operations depend on structured records and clear inputs. A conventional admin interface exposes that structure through navigation, forms, filters, and confirmation screens.

Natural language works differently. A spoken request may describe the desired result without naming the exact record, field, or operation. People also correct themselves, refer to something mentioned earlier, or add an important condition after the request has begun. The agent needed to handle that flexibility without treating an ambiguous sentence as permission to make an uncertain change.

The agent therefore operates through defined Medusa actions. It can reason about a request and carry out work only when a matching action exists. Medusa continues to enforce the data model and business rules.

The process

We started with the administrative journey rather than the speech interface. The work was broken into actions the Medusa application could expose safely and consistently. Each action needed a clear purpose, required inputs, a predictable result, and a useful error response.

Those actions became the agent's tool layer. The OpenAI SDK coordinates the reasoning and tool calls, while the OpenAI Voice SDK manages the live conversational channel. Medusa receives structured operations instead of an unbounded text instruction.

The conversation flow was then designed around the moments where an operator may need to clarify, confirm, or continue. A broad request can be narrowed through a follow-up question. A completed action can become context for the next instruction. An error can be described in ordinary language without hiding the exact reason the Medusa operation did not complete.

Turning a spoken request into a Medusa action

A voice request passes through several responsibilities. The voice layer captures the conversation. The agent interprets the user's intent and determines whether it has enough information. If the request matches an available admin tool, the model prepares the structured arguments that tool expects.

The tool then calls the relevant Medusa operation. Its response returns to the agent as structured data, which gives the conversation a factual basis for the reply. The agent can report the result, surface a validation problem, or ask for the next required detail.

This separation matters because fluent language is not the same as a valid commerce operation. The model handles the flexible part of the interaction. Medusa handles records, validation, and business behavior. The tool contract connects the two.

A bounded tool layer for autonomous work

The agent does not receive unrestricted access to the application or database. Administrative capabilities are exposed as explicit tools. Each tool describes what it does, which values it needs, and what it returns.

This makes the agent easier to reason about. A request must map to a known capability before the system can act. Required information can be checked before execution, and Medusa can reject an operation that does not satisfy its own rules.

It also keeps the product extensible. New admin capabilities can be added as new tools without rewriting the voice experience. The agent gains another action it can select, while the interaction pattern remains consistent for the operator.

Conversation that keeps operational context

Administrative work often develops over several exchanges. The first request establishes the task, and later instructions refine it. A useful voice agent needs to retain the relevant context without forcing the operator to repeat every detail.

The session therefore treats follow-up language as part of the same workflow. The agent can connect a clarification to the operation being prepared, use the result of one tool call when discussing the next step, and distinguish a correction from a separate request.

At the same time, conversational memory does not replace structured inputs. Before a tool runs, the agent still converts the current understanding into the exact arguments required by the Medusa action. This prevents loose conversational context from becoming an equally loose data update.

Safeguards for voice-driven administration

Voice lowers the effort needed to issue a request, which makes clear execution boundaries more important. The agent must know when it can proceed, when it needs another detail, and when an action deserves an explicit confirmation.

The system treats autonomy as bounded execution. The model can choose and coordinate the tools required for a task, but the available tools define the limits of that autonomy. Medusa validation remains active, and the agent reports failures instead of presenting an unsuccessful action as completed.

After an action runs, the agent explains what it attempted and reports Medusa's response. The operator can correct the request or continue through the regular admin interface.

The application foundation

Medusa.js provides the commerce administration layer and the operations the agent can perform. The OpenAI SDK provides the agent logic that interprets intent, selects tools, and coordinates multi-step work.

The OpenAI Voice SDK adds the real-time conversational interface. It carries the spoken exchange while the agent and Medusa tool layer handle the structured work behind it.

Keeping these responsibilities separate makes the system easier to extend. Voice is the interaction channel, the agent is the coordinator, and Medusa remains the source of truth for commerce operations.

The outcome

The working agent adds a voice operating layer to Medusa Admin. Administrative work can begin as a spoken request, continue through natural-language clarification, and finish as a structured Medusa operation instead of ending as advice in a chat response.

Adding another admin capability now means defining another Medusa tool with clear inputs and outputs. The existing conversation, validation, and confirmation patterns continue to govern how the agent uses it.