At 1 am, you want to add a bottle of kefir to an order arriving in the morning. For this example, assume that changes are still permitted. For you, it takes a tap. For the platform, the change must remain compatible with stock, order preparation and the vehicle's departure.
Adding a row to a database is not enough. The bottle must exist, be available for sale, reach the right bag and then the van serving your address.
This is where e-grocery architecture begins: keeping information aligned with the physical world. A promise in the interface must remain feasible even when stock, warehouse capacity and delivery conditions change between two API calls. Skip the interactive overview and continue with the technical analysis.
What happens behind a simple “Place order”?
A conceptual map of the links between the customer app, backend, data, AI, infrastructure, warehouse and delivery.
Figures reported by Rohlik, checked on 28 August 2026. GitLab scan: 9 June 2026; 342 active repositories out of 625 scanned. The ≈58/day average comes from 1,738 production deployments over 30 days, reported through Datadog DORA. These are not live FiraCode measurements.
The machinery from above
Select a component for an explanation. Arrows show conceptual relationships, not confirmed API calls.
On narrow screens, scroll the map horizontally; with a keyboard, focus the map and use the arrow keys.
- GitLab CI/CD
- Docker images
- ArgoCD / GitOps
- Kubernetes / GKE on Google Cloud
A simplified delivery model: building images and reconciling configuration are distinct responsibilities. Terraform manages infrastructure; Datadog, OpenTelemetry, Grafana and Sentry provide observability. This is not a request path.
Frontend — React, Next.js, Swift, Kotlin
In plain language
This is the shop counter: products, images, prices, buttons and the basket.
What it means technically
The frontend renders the interface, manages local interaction and communicates with backend systems through APIs.
Example: Web: React / Next.js. Android: Kotlin / Jetpack Compose. iOS: Swift / SwiftUI.
An order’s journey
An illustrative sequence, not the confirmed internal order of processing.
The customer selects “Place order”
The phone tells the shop: “I want these products.”
The frontend sends one or more requests to backend systems.
Selected component: Frontend — React, Next.js, Swift, Kotlin. Step 1 of 10: The customer selects “Place order”.
A simple way to remember
At a glance
- Customer
- Frontend
- Backend
- Data
- Warehouse
- Routing
- Courier
- Customer
Observability: Datadog · OpenTelemetry · Grafana · Sentry
Full text version: components and steps
The customer
You tell the shop what you want: “I’d like this kefir.” This is where the interaction begins.
The interaction starts in the web, Android or iOS app and produces requests to backend systems.
Example: search for “kefir”, choose a quantity and select “Add to cart”.
Frontend — React, Next.js, Swift, Kotlin
This is the shop counter: products, images, prices, buttons and the basket.
The frontend renders the interface, manages local interaction and communicates with backend systems through APIs.
Web: React / Next.js. Android: Kotlin / Jetpack Compose. iOS: Swift / SwiftUI.
Backend — Java / Spring + Python / FastAPI
These are the services that apply the shop’s rules. When you ask “can I buy this?”, they check what is allowed.
Backend services implement rules for orders, prices, stock, payments, delivery capacity and other domains.
Rohlik describes Java as the centre of its transactional core, with Python used extensively for services, data, ML and agents.
Data — MySQL, PostgreSQL, Redis, RabbitMQ, Snowflake
MySQL and Postgres are large notebooks. Redis is a quick note on the desk. RabbitMQ is the postal service. Snowflake is the analytical library.
OLTP databases retain transactional data, Redis supports fast access, RabbitMQ transports messages, and Snowflake serves analytics and data warehousing.
In a conceptual example, an event such as ORDER_CREATED can let the warehouse, notifications and analytics react separately. The event name is illustrative.
AI / ML / Operations Research
Think of a colleague who estimates tomorrow’s needs and solves puzzles with millions of possibilities.
This includes demand forecasting, machine learning, mathematical optimisation, LLMs, AI agents and MCP. These functions are not all stages of every order.
Rohlik describes demand estimation, labour planning, choosing products for automation and predicting handling times. MCP is reported as an API surface across 15+ services.
WMS + AutoStore
In an automated warehouse, systems coordinate bringing a bin to the operator: the product comes to the person.
The WMS coordinates warehouse operations. Internal services connect it to automation; AutoStore uses robots and bins for goods-to-person fulfilment.
Illustrative flow: introducing products into the system → picking → conveyor transport → dispatch. The actual configuration varies between centres.
Route optimisation
A large puzzle: how can thousands of orders reach thousands of people using a limited fleet, without being late?
Optimisation engines can allocate deliveries and capacity under constraints on time, distance and resources.
Rohlik reports in-house route planning, real-time fleet tracking and courier capacity optimisation.
The courier — the final physical stage
After the calculations, a real person loads the products into a van and brings them to your door.
Last-mile systems connect warehouse dispatch to fleet tracking, routes, capacity and delivery execution.
Software meets the physical world: addresses, traffic, time, products and the customer.
An order’s journey
The customer selects “Place order”
The phone tells the shop: “I want these products.”
The frontend sends one or more requests to backend systems.
The system identifies the user and market
The shop checks who you are and which country you are shopping in.
Rohlik describes shared code and data isolation per market. The source does not specify whether that isolation is logical or physical.
The backend checks the rules
The shop’s services check whether the request makes sense.
Validation may cover products, quantities, prices, promotions, addresses, delivery slots and other commercial rules.
Data systems come into play
The services consult the shop’s notebooks and quick notes.
MySQL/PostgreSQL, Redis and other systems provide different forms of storage and data access.
The payment is processed
The shop checks whether payment can be made.
Rohlik lists Adyen, PayPal, bank transfers and real-time fraud scoring. The exact point of payment authorisation or capture is not published here.
The order may produce events
The internal postal service can announce a new order.
RabbitMQ is the declared default message broker and allows systems to be decoupled through messages.
The warehouse starts preparing the order
People and, where automation exists, robots start preparing the products.
Rohlik describes internal services between the WMS and automation: AutoStore, picking, conveyors and dispatch. We do not infer the equipment in the Romanian warehouse.
The system solves the delivery puzzle
Planning systems work out who carries the orders and how to organise the routes.
Rohlik reports in-house engines for route and courier capacity optimisation; this is a simplified representation of planning.
The courier leaves
A real van leaves the warehouse for the customer.
Fleet tracking and last-mile systems support operational execution.
The order reaches the customer
What began as bits on a phone becomes a real bag at your door.
Resulting states may feed analytics, support and other processes; the exact path of these updates is illustrative.
1. An online supermarket is more than a website
The model frontend → API → database explains a web request, but hides almost every operational decision.
Rohlik describes proprietary software for its storefront, forecasting, fulfilment, payments and customer communications. Sezamo is the group's Romanian brand.
Conceptual model, not Rohlik’s published internal architecture. Arrows indicate dependencies, not a mandatory sequence of synchronous calls.
Scroll horizontally. When using a keyboard, press Tab until this area has focus, then use the arrow keys.
Text description of the connections
- Web / iOS / Android → API / edge
- API / edge → Customer and identity
- API / edge → Catalogue, search, prices, promotions
- Catalogue, search, prices, promotions → Cart and checkout
- Cart and checkout ↔ Stock, payment, time slots and capacity
- Cart and checkout → Accepted order
- Accepted order → Fulfilment / WMS / picking
- Fulfilment / WMS / picking → Products, automation, conveyors
- Products, automation, conveyors → Dispatch and loading
- Dispatch and loading → Routes, couriers and vehicles
- Routes, couriers and vehicles → Customer
- Routes, couriers and vehicles → Stock, payment, time slots and capacity — constraints (dashed connection)
A bounded context defines the boundary of a business model and its rules. “Available” can mean that a product may appear in the catalogue, that a quantity can be reserved, or that an item has already been picked. Confusing these meanings causes problems even when each API works in isolation.
2. What the platform's scale actually measures
Inventory consulted on 28 August 2026: Rohlik.
| Indicator | Value |
|---|---|
| Active/scanned repositories | 342/625 |
| Contributors | 221 |
| Production deployments | 1,738 per 30 days; approximately 58 per day |
| Commits | 8,350 per 30 days |
| Technologies/domains | 89/7 |
Scroll horizontally. When using a keyboard, press Tab until this area has focus, then use the arrow keys.
The stated sources are GitLab — 9 June 2026 — Mesmer and Datadog DORA. The consultation date is not the collection date. We have not independently measured operational activity.
The five main markets are Czechia, Germany, Austria, Hungary and Romania. The minority stake in Bulgaria's eBag is presented separately. Countries.
A repository might contain a library, a frontend, declarative infrastructure, ML pipelines or several services. This does not establish that there are “342 microservices”. Contributors do not automatically equal employees either.
At this scale, the useful question is how to manage contracts, versions and operational responsibility. Repository count alone does not measure architectural quality.
The paved road label identifies recommended internal standards. Growing, Steady, New and Sunsetting describe adoption, not a ranking of quality. Rohlik's legend. A technology being phased out may still support important functions; the label alone does not establish a migration deadline.
We can organise the inventory by responsibility to make sense of it. This table is an explanatory model, not a confirmed mapping of internal services.
| Responsibility | Main question | Examples from the inventory |
|---|---|---|
| Interface | How does the user express a request? | React, Next.js |
| Transactions and state | Which change do we accept and persist? | Java/Spring Boot, MySQL/PostgreSQL |
| Data and optimisation | What does history show, what demand do we expect, and how do we allocate resources? | Python, Snowflake, mathematical programming |
| Physical execution | Which products have been picked and loaded? | WMS, automation, logistics |
| Software operations | Which version is running, and how do we investigate errors? | GitLab CI, GKE, Argo CD, OpenTelemetry |
Scroll horizontally. When using a keyboard, press Tab until this area has focus, then use the arrow keys.
These responsibilities affect one another. A forecast can change staffing plans, but cannot confirm that a particular order is ready. A successful deployment does not confirm that a product has reached the vehicle.
3. The transactional core: rules that must remain true
In Rohlik's technology inventory, Java is described as the centre of the transactional core, while Spring Boot is listed as a default backend framework.
A transactional core must protect invariants such as “the same reservation cannot consume stock twice”. Spring provides abstractions for transactions and integration with data access. That makes it suitable for these problems without proving that every Rohlik checkout, inventory or payment component is written in Java. Spring transactions.
Suppose payment is authorised but the response is lost. Retrying without a stable identity can repeat the business effect. Idempotency means that repeating the same logical operation does not create another charge or another order.
Protection requires more than an identifier: it must be associated with the user and request, the result must be stored, and concurrent requests need defined handling. A local transaction does not automatically include the payment processor, broker and warehouse. The framework cannot turn these independent systems into a single atomic operation.
Rohlik's inventory also includes Testcontainers. The library documentation describes starting databases and other dependencies in temporary containers for integration tests. A useful reservation scenario is two requests competing for the last unit: testing with the real engine can expose behaviour that a simplified substitute hides. It does not automatically reproduce production load, configuration or every failure mode.
4. Forecasts do more than produce charts
Rohlik lists Python for services, ML, data and agents, alongside FastAPI. Veloq is Rohlik's proprietary technology platform, also available to other online retailers. Veloq WMS documentation connects anticipated demand with workforce allocation.
Conceptually, the dependency is:
demand → forecast → procurement → scheduling supplier deliveries → staffing requirements → preparation capacity.
For perishable products, overestimating demand can mean expiry and waste, not just cash tied up in stock. Underestimating it can lose a sale and leave a basket incomplete. Electronics also have storage and depreciation costs, but not the same daily pressure to maintain freshness.
A statistically good model is not enough. If it predicts demand correctly but goods arrive after peak picking time, the operational result is still poor. Predictions must become feasible decisions that account for supply lead times and limits on space and staff.
This explains why data engineering, ML and operational optimisation should be assessed together, rather than solely through a model's score.
5. Where software meets the warehouse
In its account of automation and operational optimisation, Rohlik describes WMS integration with automation, MIP for SKU allocation within the grid, ML for replenishment and linear programming for shifts.
A WMS, or Warehouse Management System, manages warehouse operations. In Veloq's terminology, a WES, or Warehouse Execution System, coordinates execution between the WMS and automation. Picking means collecting items; fulfilment includes preparing an order for delivery. Veloq WMS, Veloq WES.
AutoStore is not a metaphor for the cloud: bins are stacked in a grid, retrieved by robots and brought to workstations. Rohlik announced the launch of such an installation in Munich in September 2022, including conveyor connections. This is a dated example from a specific location. The sources consulted do not confirm the same configuration at Sezamo's Romanian warehouse. Rohlik announcement.
Linear programming optimises an objective subject to linear relationships. MIP, mixed-integer programming, also supports integer variables for discrete decisions: whether to assign an item to a particular area, for example. A SKU is a code identifying a type of stock item. We do not assume that Rohlik uses the solvers in the documentation cited to explain the concept. OR-Tools introduction.
Conceptual example: the grid may hold enough stock while its picking ports are saturated. Speeding up one robot does not help if the next conveyor is blocked. Local optimisation must be judged by its effect on the entire flow.
Integration with robots does not reveal where every controller runs. We cannot infer that GKE directly controls the motors. In an integration model, an accepted request, an operation in progress and a confirmed physical outcome are different states. A successful HTTP response may confirm only the first stage.
Routing does not necessarily begin after packing either. Veloq Router describes estimating preparation and loading times alongside the route, then passing priorities to the WMS. Veloq Router.
Rohlik reports proprietary route solvers, real-time fleet tracking and optimisation of courier capacity. These are declared capabilities, not a demonstrated configuration for Romania.
6. Stock does not necessarily make a delivery promise feasible
For our example, the conditions might be:
eligible product → available quantity → reservation → warehouse capacity → timely preparation → vehicle and time slot → payment authorisation → feasible delivery.
This is a conceptual list of constraints, not the published sequence of Sezamo's checkout.
Two customers can see the last bottle at the same time. If both try to reserve it from the same state without concurrency control, a race condition can occur: the result depends on the order of operations. A cache may display stale state, and simply reading a quantity does not guarantee its reservation.
A reservation needs a concurrency rule and, when temporary, an expiry. If payment fails, capacity and stock must be released. If payment succeeds but confirmation is delayed, the system must be able to reconcile the outcome.
One architectural option is a sequence of local transactions with compensating actions, known as a saga. Compensation does not turn back time: releasing a reservation does not return a dispatched bag to the warehouse. AWS saga orchestration.
When resuming a flow, the right question is “what has already executed?”, not just “which request failed?”. This is where consistency, retries and error recovery meet.
7. RabbitMQ and states that change at different times
RabbitMQ appears in 50 repositories, according to Rohlik's inventory. Asynchronous flows between domains are plausible; the inventory does not reveal their topology.
An event-driven example compatible with Rohlik’s public stack, not a confirmed internal topology. OrderConfirmed is an illustrative name.
Scroll horizontally. When using a keyboard, press Tab until this area has focus, then use the arrow keys.
Text description of the connections
- Order domain → Broker / exchange — OrderConfirmed: example
- Broker / exchange → Queue + consumer: fulfilment
- Broker / exchange → Queue + consumer: analytics
- Broker / exchange → Queue + consumer: loyalty
- Broker / exchange → Queue + consumer: notifications
- Broker / exchange → Queue + consumer: customer projection
Events such as OrderCreated, OrderModified, OrderCancelled, PickingStarted, OrderDispatched and OrderDelivered are illustrative names, not confirmed Rohlik contracts. A consumer is a component that processes incoming messages.
The source of truth is the authoritative record for a particular state. A read model organises data for reading. It can be implemented as a materialised projection: a derived representation stored and updated from changes in the source.
In this example, an order might be cancelled in the authoritative record while analytics still counts its previous version and the loyalty system has not adjusted the points. Event propagation could explain the difference. This does not mean that every divergence is acceptable, or that we have identified Sezamo's internal mechanism.
Differences may also arise from different filters or business rules. Without logs, tracing and backend code, we cannot establish the cause of a real incident. Under eventual consistency, if updates stop and are processed correctly, representations converge on the state relevant to each model.
A system based on eventual consistency needs clear operational criteria: what delay is acceptable, how are stalled consumers detected, and how are projections repaired? “It will synchronise eventually” is not enough.
RabbitMQ documents the possibility of message redelivery; consumers must handle duplicates. Confirmation that the broker has received a message does not certify that every business effect has completed. RabbitMQ reliability, acknowledgements and confirms.
To avoid saving an order without publishing its event, one possible pattern is a transactional outbox: persist state and event in the same local transaction, then transmit the event separately. This is a conceptual recommendation, not an implementation attributed to Rohlik. AWS transactional outbox.
8. Multiple markets require more than a tenant_id
Rohlik describes shared code, isolated data, regional identity, feature toggles and tenant-aware routing across markets. Rohlik.
Architecturally, feature toggles allow the same codebase to expose different behaviour. Tenant-aware routing preserves market context. This does not tell us whether isolation uses separate databases, distinct schemas or other mechanisms.
Possible variations include payment methods, promotions, taxation, assortment, integrations and logistics models. We do not attribute a specific configuration to Romania without documentation.
In a platform with physical operations, isolation must also hold in caches, messages, jobs and authorisation context. Selecting the right tenant in the interface does not protect a consumer that loses that context.
Compared with a simple SaaS application, code reuse must also account for physical constraints that cannot be changed by configuration alone: staff, temperature requirements, vehicles and geography. A shared codebase does not mean identical constraints everywhere.
9. Infrastructure that supports continuous change
The infrastructure listed by Rohlik includes Google Cloud/GKE, Docker, GitLab CI/CD, Argo CD and Terraform, alongside Datadog, OpenTelemetry, Grafana, Sentry and canary releases.
A compatible conceptual flow is developer → GitLab CI → Docker image in a registry → versioned configuration → Argo CD → Kubernetes/GKE. Terraform manages declarative infrastructure in this model. Not every change must follow exactly the same sequence.
An image packages the application and its dependencies; a container is a running instance. In Kubernetes, a Pod groups one or more containers that share networking and may use shared volumes. Pods run on cluster nodes. GKE is Google's managed Kubernetes service, not an additional layer traversed by every request. These concepts explain where and how applications run, not the rules governing orders. Docker images, Kubernetes Pods, GKE.
In the illustrated flow, CI runs the configured checks and produces the artefact. Continuous delivery prepares it for release; continuous deployment also automates promotion to production. A commit or merge alone does not prove that the version has reached customers. Release stages and conditions must be defined in the pipeline. GitLab on CI, delivery and deployment.
In GitOps, Git expresses the desired state, and Argo CD compares it with the system's actual state. Automatic application and drift correction depend on the sync policy. Argo CD automated sync.
A canary release initially limits exposure to the new version and uses evaluation criteria before expanding it. Traffic control and analysis are distinct from configuration synchronisation; Argo Rollouts is a separate project that can coordinate such strategies. Rohlik's inventory does not establish which controller, thresholds or rollback mechanism are configured. Argo Rollouts.
The published frequency aggregates production deployments; it does not imply the same number of daily storefront changes. Without incident rates and recovery times, we cannot infer reliability.
A container may restart within the same Pod according to its policy; a controller may create a replacement Pod when necessary. These are different mechanisms. Kubernetes lifecycle. If a process disappears after payment authorisation, a new instance must discover the outcome already produced. Restoring execution is not the same as recovering a transaction.
Observability means being able to explain system state from its signals. Tracing correlates distributed operations, metrics show trends, and logs provide details. OpenTelemetry supplies tools to generate, collect and export signals; other systems handle storage and visualisation. OpenTelemetry's role.
In the kefir example, you would want to trace the reservation, message delay and acceptance for picking. An application rollback does not automatically reverse a physical action and may require compatibility with data already written.
The inventory cannot establish cluster topology, the exact data isolation mechanism or recovery procedures. Those require architecture documentation and operational evidence, not just product names.
So far, we have viewed the platform through web and mobile interfaces. But the screens through which we reach them do not define orders, reservations or business rules. What changes when a user expresses intent in natural language and an AI application proposes the necessary operations?
The platform gains a new type of client: an AI agent.
10. MCP for a developer who knows REST
MCP adds an interface to the infrastructure discussed so far. It does not replace the services that decide whether a product can be reserved or an order changed.
The analogy “MCP is roughly a USB-C for AI applications” helps on first encounter: there is a common way to connect. Its limit is that a shared connector guarantees neither semantics, permissions nor the quality of the connected system.
Model Context Protocol is not an AI model. It is a protocol through which an application can discover and use external capabilities.
| Component | Responsibility |
|---|---|
| MCP host | The application coordinating interaction with the model and access policies. |
| MCP client | The host component communicating with a particular server. |
| MCP server | Exposes capabilities through the protocol. |
| Tools | Callable functions for reading or taking action. |
| Resources | Data and content supplied as context. |
| Prompts | Reusable interaction templates. |
Scroll horizontally. When using a keyboard, press Tab until this area has focus, then use the arrow keys.
These roles and primitives are defined in the MCP documentation; we should not assume that every server exposes all of them. Architecture, server primitives.
Messages use JSON-RPC. Standard transports include stdio for a local process and Streamable HTTP for HTTP communication. HTTP authorisation is addressed separately through an OAuth-based framework. Connecting does not automatically grant permission for every business action. Transports, authorisation.
For a REST developer, the useful difference is the contract intended for an AI client: discoverable tools, descriptions, input schemas and results. Existing APIs can remain behind it; the model does not need to know the database structure.
The MCP references in this article use the 2026-07-28 specification. We do not automatically attribute that version to Sezamo’s server.
11. What a Grocery MCP Server exposes
Sezamo documents HTTP and OAuth connectivity, with access to shopping and support functions. Its introductory documentation does not publish a complete catalogue of named tools. Sezamo MCP, Romanian introduction.
The following names appear in Sezamo connector metadata consulted on 28 August 2026. This is an observed contract, not evidence that the operations were executed:
| Operation | Declared role |
|---|---|
| batch_search_products | Search for products. |
| get_cart | Inspect the cart. |
| add_items_to_cart | Add products to the cart. |
| get_checkout | Inspect checkout and validations. |
| fetch_orders | Inspect orders. |
| cancel_order | Cancel an eligible order. |
| submit_claim | Process a claim; this can credit the account. |
Scroll horizontally. When using a keyboard, press Tab until this area has focus, then use the arrow keys.
We do not replace these names with assumed aliases. In particular, get_checkout does not place an order. The description of show_submit_checkout specifies a button opening web checkout, where the user reviews and completes the order.
Conceptual reconstruction, not internal Rohlik documentation. The MCP client logically belongs to the host; it is drawn separately for clarity. Backend topology is abstracted.
Scroll horizontally. When using a keyboard, press Tab until this area has focus, then use the arrow keys.
Text description of the connections
- User → MCP host: AI application + LLM
- MCP host: AI application + LLM → MCP client
- MCP client ↔ Sezamo MCP Server — MCP
- Sezamo MCP Server ↔ Business APIs and services
- Business APIs and services ↔ Authoritative data
- Business APIs and services ↔ Warehouse and logistics
The exposed operations cover responsibilities such as catalogue, cart, delivery, orders, profile/loyalty, claims, returnable packaging and recipes. Grouping them into domains is our interpretation, not an inventory of the company's microservices.
12. MCP is not the supermarket's backend
In the illustrated model, the host and model interpret intent while the MCP server exposes business operations. The authoritative records for stock, payments, orders and delivery remain in the systems managing those domains.
An MCP server can validate arguments, combine responses and simplify an operation for the agent. It must not become a way to bypass backend rules.
For example, a cancellation tool must obtain an eligibility decision from the order domain. It cannot infer from a conversational message that physical preparation has stopped.
This is a recommendation about separating responsibilities, not a claim that we have inspected Sezamo's internal implementation.
13. The interface changes; the obligations remain
In a conventional interface, the user interacts with interface elements and those actions trigger API calls. In a conversational interface, the user expresses intent, the model proposes tool calls, and the application executes them within permitted boundaries.
Conceptual example: “Add the ingredients for carbonara, choose the versions I usually buy and avoid unavailable products.”
The agent could consult preferences it is authorised to access, search for products, check variants and add accepted items. If it does not know the number of portions or budget, it can ask. If some operations succeed, it must state exactly what changed without automatically repeating the entire flow.
A visual cart remains useful for quantities, prices and substitutions. The conventional UI does not disappear: it also becomes the place to review the consequences of freely expressed intent.
14. MCP beyond shopping
Rohlik lists MCP in 17 repositories and across 15+ services, with FastMCP in 8 repositories. OpenAI GPT, LangChain/LangGraph, Langfuse and LiteLLM also appear in the inventory. Rohlik.
Repositories, services and tools are distinct categories; their counts are not interchangeable. The presence of FastMCP does not prove that every MCP server in the group uses that framework.
The architectural distinction remains useful: the protocol defines the contract, the server library implements it, and orchestration determines the sequence of calls. The model and observability have other responsibilities. A technology inventory does not prove how all these components are connected in a particular agent.
Inference: a common protocol can serve agents for customers, development, operations and analytics. It does not follow that they all share permissions or access the same systems. The internal reporting example demonstrates a use distinct from shopping.
15. reporting-mcp: access to data does not explain its meaning
In its article dated 24 April 2026, Rohlik presents reporting-mcp, a gateway to Snowflake and a semantic layer versioned in Git. It documents search_verified_queries, search_tableau_metrics and read_query; writes are disabled by default. Rohlik article.
The general problem is semantic. “Revenue” may include or exclude returns; “active customer” needs a period and criteria; “margin” requires an agreed formula. A SQL query can run without error and still calculate the wrong metric. A semantic layer makes relationships, dimensions and formulas explicit. Snowflake semantic views.
Rohlik's layer should not automatically be equated with Snowflake's “Semantic Views” product.
Conceptual synthesis of Rohlik’s reporting-mcp article. Includes new SQL and the recommendation for additional checking; it does not enforce exclusive use of approved queries.
Scroll horizontally. When using a keyboard, press Tab until this area has focus, then use the arrow keys.
Text description of the connections
- AI agent → reporting-mcp
- reporting-mcp → Semantic layer / verified queries
- Semantic layer / verified queries → SQL selection and validation
- SQL selection and validation → Snowflake
- reporting-mcp → Metadata + new SQL — no suitable match (dashed connection)
- Metadata + new SQL → Read-only validation
- Read-only validation → Snowflake
- Snowflake → Result
- Result → Additional checking — new SQL: recommendation (dashed connection)
Prioritising verified queries is guidance for the agent. Rohlik also permits exploration with new SQL; it does not guarantee exclusive use of approved queries. Rohlik article.
The governance lesson is to separate three checks: may the user see the data, is the query permitted, and does the result match the business definition? Read-only access limits modifications, but does not resolve data disclosure, query cost or misinterpretation. An approved formula also requires control over the filters, period and granularity used.
16. When AI can change the real world
Reading the catalogue and cancelling an order have different consequences. The agent can propose a call, but the backend must check the user's authority over the order and whether the change is still allowed.
OAuth authorisation does not replace confirmation of a specific action. The user must understand what will change, and retrying a request after a timeout must not duplicate its effect. These are general design rules, not findings about Sezamo's implementation. MCP tools, authorisation.
Similarly, a tool description requiring confirmation does not prove that the server enforces it technically. Between expressed intent and a business effect lie authorisation, validation and execution boundaries that must be checked separately.
This leads to a separate analysis: “When AI can cancel an order: securing a transactional MCP server.” Here, the lesson remains architectural: introducing an AI client does not transfer the authority of business services to the model.
17. What engineers can learn
- The domain model comes before the framework. Define what reserved, confirmed, prepared and dispatched mean.
- The physical world changes transaction boundaries. A software rollback cannot reverse every operational effect.
- State convergence must be designed. Under eventual consistency, define acceptable delays, reconciliation and rules for conflicting states.
- Observability is part of architecture. Without correlation between operations, a correct HTTP response can hide an incomplete flow.
- Market isolation must reach the last consumer. It does not end at a filter in the interface.
- AI agents need more precise contracts. Tool names, errors, effects and limits must be explicit.
- MCP standardises access, not business truth. Authorisation and data meaning remain separate responsibilities.
- Permissions and confirmations belong in the security architecture. Do not leave them solely to instructions given to the model.
The bottle of kefir makes the problem tangible: the user requests a change, and the infrastructure must turn it into a feasible delivery. An AI agent can formulate the next request. The system must check whether it is authorised, whether it remains feasible and what actually happened.
For practical checks on launch and operational responsibility, see FiraCode resources. Learn about the author on the studio and founder page.
Independent analysis based on technical sources from Rohlik Group, Sezamo and MCP, and examination of Sezamo connector metadata. No account or order operations were executed for this article. The conceptual diagrams do not represent internal Rohlik documentation. FiraCode is not affiliated with Rohlik or Sezamo.