-
-
Mise Architecture
Inspiration
Two key experiences led me to this project.
First, I build ecommerce stores, and in many instances, the process involves keeping track of several multi-location configurations in a versioned document.
Second, I became exposed to using Terraform for automating cloud configurations at scale. Then, it dawned on me I could use the Terraform and general Infrastructure as Code (IaC) concept in ecommerce and POS systems.
That was when Mise (pronounced Meeze, similar to how you would pronounce “Freeze”) was born.
What it does
First, Mise helps teams make changes safely.
Mise is a governed AI operations platform for multi-location restaurants and franchise chains. It helps with configuration management for POS operations.
It sits on top of systems such as Square and Toast and, eventually, other restaurant platforms. An operator can give Mise a business request like:
“Add a 10% staff discount in Georgia, except Savannah.”
Mise then works through a controlled flow:
Understand the request
↓
Inspect the current estate
↓
Determine the affected locations and settings
↓
Create a plan
↓
Get human approval
↓
Apply the approved change
↓
Verify the live POS
Second, Mise detects configuration drift.
If someone later changes a setting directly in the POS, or another system changes it outside Mise, Mise can compare the live POS with the last approved state and flag the difference. That is the drift detection capability.
For example, Mise may have approved a 10% staff discount for Atlanta. Later, someone changes it directly in Square to 9%. Mise can detect the difference between the live and expected values, thereby identifying the drift.
For a large franchise, configurations can slowly become inconsistent across stores even when the original rollout was correct.
How Mise was built
I built Mise as a governed operations layer on top of Square, with a clear split between AI reasoning and deterministic execution.
The user starts in a React web console and gives Mise a request in plain English, such as “Add a 10% staff discount in Georgia, except Savannah.” That request is sent to a Strands agent running on Amazon Bedrock AgentCore.
The agent handles the parts that need reasoning: understanding the request, checking the current estate, resolving locations, and identifying the right POS setting.
Once the intent is understood, Mise stops relying on the model for execution. A deterministic Go engine creates the desired state and generates a saved plan showing exactly what will change, where it will change, and what the new values will be.
The operator then reviews and approves that specific plan. Only after approval can a protected apply worker send the change to Square. This means the AI does not have open-ended write access to the POS.
After the change is applied, Mise reads Square again and verifies that the live configuration matches the approved state. It also supports drift detection, so if someone later changes a setting directly in Square, Mise can compare the live value with the approved value and flag the difference.
Challenges encountered
One of the biggest challenges was keeping the AI useful without giving it too much control.
It was easy to imagine a system where the model simply interprets a request and writes directly to the POS, but that would be risky for real restaurant operations. I had to separate reasoning from execution so that the agent could understand intent and scope while the actual change was handled through deterministic plans, approval checks, and a protected apply worker.
Another challenge was location reasoning. A request like “Georgia, except Savannah” sounds simple, but the system has to distinguish between geography and POS location names, find the right stores, apply exclusions correctly, and avoid touching anything else.
I also had to deal with differences between human-friendly values and provider values. For example, Square may return a percentage as 10.0 while the approved configuration contains 10. Those values are the same in practice, so Mise needed semantic comparison rather than simple string matching.
The final challenge was verification. I did not want Mise to stop after sending a request to Square. I had to make sure it could read the live state back, compare it with the approved state, and detect later drift if someone changed the POS outside Mise.
Accomplishments
Mise works as a full end-to-end governed workflow, not just as a chatbot or prototype.
A user can give one conversational request across a multi-location restaurant estate, and Mise can understand the request, resolve the correct locations, create a detailed plan, require human approval, apply the approved change to Square, and then verify the live result.
I also built drift detection into the same system. If a setting later changes outside Mise, the platform can detect that the live POS no longer matches the approved state and show the difference.
Another accomplishment is that the agent does not have unrestricted write access. The model helps with understanding and investigation, but only the protected execution path can apply an approved plan. That gave me a much stronger governance model than a simple “AI calls API” design.
Lastly, Mise was tested against a real Square Sandbox estate with multiple locations and real configuration changes, including a staff discount targeted to Georgia while excluding Savannah.
Lessons
- Agentic AI is most useful when it is given clear boundaries.
- Natural language is very good for expressing business intent, especially when requests contain geography, exclusions, and operational rules. But once that intent has been understood, deterministic software is better for deciding exactly what should change and for making sure the same approved plan is executed.
- Another lesson was that multi-location operations are not only about making changes. They are also about keeping many locations consistent over time. That is why drift detection became a core part of Mise rather than an extra feature.
What's next for Mise
Concerning the next steps, Mise will transition from a strong Square-based proof of concept into a broader control system for multi-location restaurant operations.
Also, I hope not to remain a solo developer for long. After building a stronger core engineering team, we will expand support beyond discounts into more POS settings such as taxes, menus, service charges, pricing, and location-specific configuration.
There will also be plans to add more restaurant platforms over time so operators can manage changes across different systems from one governed workflow.
Drift detection will become more proactive. Instead of only showing that something changed, Mise should be able to explain what changed, when it changed, which locations are affected, and whether the operator wants to restore the approved state or accept the new one.
Lastly, we will strengthen governance for larger restaurant groups with role-based access, approval policies, audit history, scheduled changes, and safer rollout controls for different regions or groups of stores.
The goal is to make Mise the AI control plane for multi-location restaurant operations: one place where teams can describe what they want, review the exact impact, apply changes safely across the network, verify the outcome, and keep the estate aligned over time.
Log in or sign up for Devpost to join the conversation.