Institutions

Architecture

Open standards, and no lock-in.

For the partner’s IT department: how Nano is built, and what keeps you independent of it.

Overview

Nano’s architecture todayAssistants go through Nano’s MCP gateway, which checks every call; behind it, the core and the software, each in its own space, on a database in France. Administration is connected to no assistant: it is done by human-run scripts on the server.The user’s assistantsChatGPT · Claude · Mistral Vibethe Nano app, or any other MCP clientHTTPS · MCP · OAuth 2.1 tokenNano MCP gatewaychecks the token, the tool’s nature,the plan, the quotas and the countryCoreaccounts · sign-indeadlines · reminderslanguages · calendarsGDPR rightsSoftwareeach in its ownprefixed data spaceno cross access(tested on every release)PostgreSQL · Francenightly backupsno assistant tool crosses this lineAdministrationbilling · prices · codes · countrieshuman-run scripts, on the server
Today: a gateway checks every assistant call; administration is connected to no assistant. In progress: the service and administration in two distinct databases, linked by a one-way log of rights.

The building blocks

MCP (Model Context Protocol)
An open protocol: one server serves every compatible assistant. Connected and tested with ChatGPT, Claude and Mistral Vibe. Every tool declares its nature (read, write, delete); tools are a public contract: we add, we never change them silently.
OAuth 2.1
Automatic discovery, dynamic client registration, PKCE (S256), one-hour access tokens, 90-day refresh with rotation, revocation. One account, whatever the assistant.
Neutral storage
ISO 8601 dates, amounts in minor units with an ISO 4217 currency, ISO 3166 countries, numbers in international E.164 format. Display in the user’s language and calendar happens on output, never in the data.
Module contract
A product plugs in with its data (in its own space), its tools, its deadline types and its offer — without a single line of its own in the core. Tests check this on every release. In progress The contract also carries the product’s life cycle: seven stages from lab to withdrawal, testing restricted to named testers, a validation signed on the exact fingerprint of the tools, shop pages generated from the catalogue — built, being put into service.
Service and administration kept apart
Live Today, billing, rights, prices and codes are exposed by no assistant tool: they are managed through human-run scripts. In progress Next: two distinct databases, no cross access rights, and rights passed to the service through an append-only event log.
Limits enforced by the server
Plan quotas, code-sending caps, closed countries: decided by the server, never left to the model’s good will.
No lock-in
Open standards; no assistant is indispensable; all of an account’s data can be exported as JSON by the user themselves. The Nano app provides its own assistant — a small open model, interchangeable by configuration, hosted in Europe — for those with neither ChatGPT nor Claude; the server and the tools are the same.
Operations
Node.js and PostgreSQL behind an HTTPS web server, on a dedicated server in France. Nightly backups, checked, and a restore that has been tested.

Designed from the largest scale down

The target is the starting point: 5,000 software products each serving 20,000 customers, in 50 countries. We look at what would break at that scale, then decide now only what costs little today and a fortune later:

  • each product knows the user only under a pseudonym of its own;
  • tokens that can be verified without querying a central database;
  • rights passed on as numbered, replayable events;
  • one entry point per product, a single sign-in for all;
  • a module contract that could run over the network, to host outside suppliers — the first has been in testing since October 2026, under this same contract.

In progress These decisions are taken; building them starts with separating the service from administration.