MESkit
View on GitHub

MESkit public website

Architecture

MESkit uses a four-layer architecture that keeps operations typed, auditable, and reusable across interfaces. The same tool layer powers UI interactions, agent tool-use, and future MQTT ingestion paths.

Last updated: March 3, 2026

Summary

Design principle: one operation path, multiple interfaces.

Summary

UI clicks and natural-language commands both resolve to typed tool functions. Those functions validate inputs and execute against Supabase-backed ISA-95 tables. Agent runtime logic and transport layers remain composable around that stable core.

Four-layer design

Current stack plus planned device transport.

┌──────────────────────────────────────────────────────────┐ │ Frontend (Next.js App Router, responsive UI shell) │ ├──────────────────────────────────────────────────────────┤ │ Tool Layer (Server Actions + Zod validation) │ │ UI calls tools • Agents call tools • same interfaces │ ├──────────────────────────────────────────────────────────┤ │ Agent Runtime (Claude tool-use) │ │ Operator Assistant • Quality Analyst • Planner │ ├──────────────────────────────────────────────────────────┤ │ Supabase (Postgres + Auth + Realtime + Edge Functions) │ ├──────────────────────────────────────────────────────────┤ │ MQTT Broker (M6) → Edge Function bridge │ └──────────────────────────────────────────────────────────┘

Tool layer rationale

Single source of truth for operations.

Type safety

Every tool contract is schema-validated before touching persistence, regardless of caller.

Testability

Business logic is isolated in functions that can be tested without UI rendering or model prompts.

Auditability

Tool-level call traces provide clear accountability for user and agent actions.

Agent runtime

Claude tool-use with explicit constraints.

Runtime behavior

  • Injects mode and context before tool selection.
  • Accepts model-selected tool calls only from registered definitions.
  • Streams tool results back into assistant responses.
Example flowClaude tool-use
Prompt → tool selection → schema validation
→ execution against Supabase
→ structured result
→ final assistant response

Supabase and MQTT transition

Stable operational contracts across transport shifts.

Why Supabase

  • Postgres relational model aligns with ISA-95 tables.
  • Realtime channels support dashboards and event triggers.
  • Auth and edge functions reduce initial infrastructure overhead.

MQTT bridge design

  • Topic pattern: meskit/{line_id}/{workstation_id}/{event_type}
  • Gateway validates payloads and writes to Postgres.
  • Downstream behavior continues through existing tool logic.

Key facts and mini FAQ

Answer-ready architecture summary.

Key facts

  • Frontend uses Next.js App Router with SSR/SSG-friendly rendering.
  • Tool layer is the single source of truth for UI and agents.
  • Agent runtime uses Claude tool-use with explicit tool registration.
  • Supabase provides Postgres, auth, realtime, and edge functions.
  • MQTT bridge is planned for milestone M6 using the same operational contracts.

Mini FAQ

Why is the tool layer central?

It prevents business logic drift between UI handlers and agent actions.

Does MQTT require a separate logic stack?

No. MQTT changes transport, while execution remains on the same validated tool functions.

Where are realtime updates handled?

Supabase Realtime subscriptions push state updates to connected clients and triggers.

Canonical links

Supporting technical pages.