Use caseMulti-site operationsProposal, not a deployment

Your business tells you what is about to happen, and helps you act first.

An AI operator for multi-site businesses that turns POS, WhatsApp and scattered files into a living model of the business — anticipating problems, simulating alternatives and coordinating action before money is lost.

Nothing on this page is running for a customer. What exists is the runtime underneath it: the ontology proposal and its accept gate, the forkable log, the conservation checker, the receipt and the reproducibility lattice. This page is the argument that those are the right primitives for this product, and it says which parts are still missing.

The thesis

Small businesses do not lack data. They lack a coherent operational model of themselves.

The data is fragmented across a point-of-sale system, a set of spreadsheets and a phone, and a large share of the decisions live in conversations that were never written down anywhere. This is not a reporting problem, and a dashboard does not touch it.

What is missing is a representation: a model of how this business actually runs, assembled from the traces it already produces, kept current, and usable for asking what happens if. That is the thing Parallax proposes, gates behind a human, and then rolls forward.

“La búsqueda es generalizable, y lo que retorna el agente tiene que razonar cómo articularlo en la ontología según el modelo de datos que va emergiendo.”the line the whole design follows from

The consequence is the interesting part, and it is the opposite of how these systems are usually built. The ontology is not installed first. It is discovered and corrected by watching the business, so search is a way of reconstructing context rather than the product, and predictions are expressed over real entities — this site, this employee, this supplier — rather than over an anonymous time series. Actions and their outcomes then feed the model that produced them.

The loop

Seven stations, and not one of them is a new subsystem.

observar → estructurar → predecir → simular → recomendar → medir → recalibrar. Each station below names the operator in the runtime that does the work, because a loop drawn over primitives that do not exist is a diagram, not an architecture.

  1. observar

    intake

    POS exports, WhatsApp threads, spreadsheets, the folder someone keeps the recipes in. No integration agreed in advance and no schema to fill in first.

  2. estructurar

    proposeOntology + accept

    Sites, staff, inventory, shifts, suppliers, sales — proposed from what was actually in the sources, with the questions it could not answer left open. The operator accepts it before anything forecasts.

  3. predecir

    rollout

    A forecast expressed over real entities rather than an anonymous series: this site, this Friday, this shift. Typed simulated, because it has not happened.

  4. simular

    fork + diff

    Do nothing, against the action being considered. Same state, same seed, one decision different. The gap between the two branches is the argument for acting.

  5. recomendar

    conversation + receipt

    One concrete action in the channel the business already uses, with the receipt behind it rather than a chart in place of it.

  6. medir

    observe

    What actually happened. The quantity does not change its name, it changes its type: simulated becomes observed, and the receipt's split moves.

  7. recalibrar

    certifyPolicy

    Forecast against outcome, written into the record. A policy that stops reproducing gets demoted whatever it declares about itself.

Worked example

What the operator actually receives.

The regression, the chart and the explanation can all be attached. They are evidence for the recommendation; they are not the product. The product is one message that names a decision and can be answered with a word.

Parallax · Thursday 18:40

La sede de Chapinero probablemente venderá 22% más este viernes.

Si no haces nada, faltarán dos insumos y habrá déficit de
personal entre 7 y 9 p.m.

Recomiendo mover a Cindy, ordenar 18 kg adicionales y adelantar
el pedido.

¿Lo ejecuto?

Operator

Sí, pero deja el pedido para mañana temprano

Parallax

Hecho. Turno actualizado, pedido programado 6:00 a.m.

Pronóstico +22% · simulado · clase PINNED
Recibo completo: /r/bef312a9

Parallax · Saturday 09:10

Viernes cerrado: +19% real, 0 faltantes, turno cubierto.

Pronóstico 22% → real 19%. Error de 3 puntos, registrado.

The last message is the one that matters and it is the one this kind of product usually skips. A recommendation nobody scored is a guess with good manners.

Product, technology, moat

Three different things, kept apart on purpose.

LAYERS — the product is not the engine, and neither is the defensibility
LayerWhat it is
ProductA predictive operating copilot, WhatsApp-first
First userThe owner or operator of a business with several sites
First strong caseStaffing, inventory and demand in restaurants and franchises
InterfaceAlerts, questions, approvals, charts and reports over WhatsApp
EngineContext assembly, code, statistical models, simulation, agents
RepresentationA dynamic ontology — SQL, files or a graph, decided by the context
MoatA calibrated history of prediction → decision → outcome

The moat row is the only one that cannot be bought or copied in a quarter, and it is the one Parallax is built to produce. A receipt binds a forecast to the decision it caused and to the outcome that followed, under a seed that makes the whole thing replayable. A year of those is a calibrated record of this specific business. A year of chat logs is not.

How it is wired

WhatsApp, Kapso, Genesis, and the hub.

The channel is not a metaphor. A real WhatsApp message already runs an agent turn in a confined workspace on our own hardware, and the hub already answers the route that turn would call. Here is each hop and whether it carries traffic today.

  1. 01channel

    WhatsApp → Kapso

    Kapso is the Cloud API gateway. A thread id arrives as kapso:<phoneNumberId>:<waId>, and the principal is the second segment — the first is our own number and is identical on every message.

    runs in production

  2. 02ingress

    Tailscale Funnel

    The webhook port is published and nothing else. SSH stays closed. AllowFunnel is keyed by host:port rather than by path, so the port is separate from the one the web app listens on.

    runs in production

  3. 03runtime

    Genesis session

    One agent session per thread, in a dedicated workspace directory rather than the whole home. A fail-closed allowlist on waId: an unknown sender is refused, and the refusal is the default rather than the exception.

    runs in production

  4. 04engine

    Parallax hub

    POST /api/whatsapp/turn takes {from, text, threadId} and nothing else. Every ontology, run and receipt is authored server-side, so there is no path here that hands the hub content to publish.

    runs, driven by the demo

The first three hops carry real WhatsApp traffic today. The fourth is the one that is not joined in production: the hub answers /api/whatsapp/turn and serves /r/:id, and bun run demo:live drives that whole thread against the deployed hub — but no Genesis session is calling it for a real number yet. Parallax’s own channel layer is pure functions with no transport attached, which is exactly why it can be pointed at one.

What is still missing for this use case

Exists

  • The ontology proposal and its accept gate
  • Append-only log with copy-on-write forking
  • Conservation invariants, checked in code
  • The receipt, with its own observed/simulated split
  • The reproducibility lattice and the policy certifier
  • A live WhatsApp → agent path on our own VPS

Needed next

  • A POS intake alongside the filesystem and table proposers
  • A forecasting actor — today’s actors are seeded and pure
  • A restaurant domain: its transition, and the conservation law it already keeps
  • Joining the Genesis session to the hub for a real number
  • The write-back that turns an approval into an action

Unmeasured

  • No forecast has been scored against a real Friday
  • No business has been modelled from its own transcripts
  • The +22% and the +19% above are illustration, not results

The third column is the one to read first. The numbers in the example thread are made up to show the shape of the message, and a system whose whole claim is that a number must say how much of it was real does not get to be vague about that on its own website.

Start

The runtime is the part that already works.

Point it at a directory and it will propose a model of it, refuse to run until you accept, and hand you a receipt that says what share of its own answer was real.