# Building RestaurantOS AI: Observable Multi-Agent Restaurant Orchestration with OpenTelemetry and SigNoz

> Source: <https://dev.to/prashanth123/building-restaurantos-ai-observable-multi-agent-restaurant-orchestration-with-opentelemetry-and-5a23>
> Published: 2026-07-27 03:37:40+00:00

Learn how we built an observable AI-powered restaurant operating system using OpenTelemetry, SigNoz, Prisma, and multi-agent architecture.

Modern restaurants generate enormous amounts of operational data every day. Forecasting demand, tracking inventory, minimizing food waste, and purchasing ingredients are all interconnected decisions that traditionally require significant manual effort.

To automate these processes, we built **RestaurantOS AI** an **AI-powered Restaurant Operating System** driven by specialized autonomous agents.

But there was one major challenge.

Large Language Model (LLM) agents don't behave like traditional software.

They are probabilistic.

They make decisions.

They call multiple services.

They generate intermediate reasoning.

Without observability, debugging becomes nearly impossible.

That is why **OpenTelemetry** and **SigNoz** became core components of our architecture rather than optional monitoring tools.

In this article, we'll walk through how we built an observable multi-agent system that makes every AI decision transparent.

Restaurant managers constantly answer questions like:

Instead of solving these manually, RestaurantOS AI coordinates multiple specialized AI agents that collaborate together.

RestaurantOS AI uses five specialized agents orchestrated through a sequential pipeline.

```
                           +--------------------------------------+
                                      |             User Request             |
                                      |   e.g. "Tomato supply shortages"     |
                                      +------------------+-------------------+
                                                         |
                                                         v
                                      +--------------------------------------+
                                      |          Supervisor Agent            |
                                      |   Routes, Orchestrates & Synthesizes |
                                      +------------------+-------------------+
                                                         |
                                                         v

     ┌────────────────┐      ┌─────────────────┐      ┌────────────────┐      ┌─────────────────┐      ┌────────────────┐
     │    Stage 1     │ ---> │     Stage 2     │ ---> │    Stage 3     │ ---> │     Stage 4     │ ---> │   Final Output │
     └────────────────┘      └─────────────────┘      └────────────────┘      └─────────────────┘      └────────────────┘
              |                         |                        |                         |                        |
              v                         v                        v                         v                        v
     ┌────────────────┐      ┌─────────────────┐      ┌────────────────┐      ┌─────────────────┐      ┌────────────────┐
     │ Demand Agent   │ ---> │ Inventory Agent │ ---> │ Waste Agent    │ ---> │ Purchase Agent  │ ---> │ Response        │
     │                │      │                 │      │                │      │                 │      │ Synthesis       │
     │ Forecast POS   │      │ Detect Stock    │      │ Reduce Waste   │      │ Generate POs    │      │ Final Decision  │
     │ Sales Demand   │      │ Deficits        │      │ & Promotions   │      │ Supplier Logic  │      │ Returned        │
     └────────────────┘      └─────────────────┘      └────────────────┘      └─────────────────┘      └────────────────┘
```

Acts as the orchestrator.

Responsibilities:

Uses historical POS sales to estimate:

Compares projected demand against current inventory.

Detects:

Identifies ingredients approaching expiry.

Suggests:

Creates supplier purchase recommendations by considering:

To trace every component of our backend, we initialized the OpenTelemetry Node SDK before the Express application starts.

``` js
import { NodeSDK } from '@opentelemetry/sdk-node';
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';

const sdk = new NodeSDK({
  traceExporter,
  instrumentations: [
    new HttpInstrumentation(),
    new ExpressInstrumentation(),
    new PrismaInstrumentation(),
    getNodeAutoInstrumentations()
  ]
});

sdk.start();
```

This automatically traces:

Auto instrumentation isn't enough for AI systems.

We created custom spans around every agent execution.

``` js
return tracer.startActiveSpan(`Agent ${agent.name}`, async (span) => {

    span.setAttribute("agent.name", agent.name);

    const result = await agent.execute(input);

    span.setStatus({
        code: SpanStatusCode.OK
    });

    span.end();

});
```

Each span records:

This lets us visualize every agent independently inside SigNoz.

LLM requests deserve their own telemetry.

We adopted OpenTelemetry GenAI Semantic Conventions.

```
span.setAttribute("gen_ai.request.model", model);

span.setAttribute(
    "gen_ai.usage.total_tokens",
    response.usage.total_tokens
);

span.setAttribute(
    "gen_ai.latency_ms",
    durationMs
);
```

Now every LLM request captures:

Exactly what production AI applications need.

During development we also used the official **SigNoz MCP Server**.

It enabled:

Instead of manually configuring dashboards, the AI assistant generated many of them automatically.

When a user submits a request:

```
POST /ai/query
│
├── Demand Agent
│     └── LLM Request
│
├── Inventory Agent
│     ├── Prisma Query
│     └── LLM Request
│
├── Waste Agent
│     └── LLM Request
│
└── Purchase Agent
      ├── Prisma Query
      └── LLM Request
```

Inside SigNoz we can immediately identify:

This transformed debugging from hours into minutes.

Since OpenTelemetry was initialized using Node's `--import`

, it executed before our application loaded environment variables.

As a result, the OTLP exporter ignored our cloud configuration.

``` python
import dotenv from "dotenv";

dotenv.config();
```

Load environment variables before initializing OpenTelemetry.

Native PostgreSQL on Windows occupied port **5432**, causing Prisma to connect to the wrong instance.

Expose Docker PostgreSQL on **5435** instead.

```
ports:
  - "5435:5432"
```

Changing `POSTGRES_PASSWORD`

had no effect because PostgreSQL initializes credentials only once.

Delete the existing volume.

```
docker rm -f restaurantos-postgres

docker volume rm restaurantos_ai_postgres_data

docker compose up -d postgres
```

Building RestaurantOS AI taught us several important lessons.

✅ AI systems require domain-specific observability.

✅ OpenTelemetry makes every agent execution traceable.

✅ SigNoz provides a complete end-to-end visualization.

✅ Token usage should be monitored just like CPU or memory.

✅ Database spans reveal bottlenecks that AI latency often hides.

Most importantly:

Observability turns AI from a black box into production software.

RestaurantOS AI combines specialized AI agents with production-grade observability.

By integrating **OpenTelemetry** and **SigNoz**, every HTTP request, database query, LLM call, and autonomous decision becomes traceable.

Instead of wondering *why* an agent behaved a certain way, we can inspect the complete execution path in seconds.

As AI systems continue becoming more autonomous, observability will become just as important as the models themselves.

If you're building AI applications for production, start instrumenting early you'll thank yourself later.

Happy Building! 🚀