Most consumer AI interfaces expose their machinery: a model picker, a mode switch, a settings panel, a separate tab for image generation. Each control is a decision the user must make before receiving any value, and each is a decision they are usually unequipped to make well. Somat takes the opposite position. The interface is a single conversation box; capability is not selected but inferred from the request, and appears only when it is asked for. This paper describes the design and implementation of that arrangement. Two rules organise the system. The first is that capability lives entirely on the server: the provider key, the model identifiers, and the routing decisions never reach the browser, and are absent from the client bundle, the system prompt, and error messages alike. The second is that state lives entirely on the client: conversation history, including generated images, is stored in the browser's IndexedDB, and the deployment carries no database at all. Between these two rules sits a tool layer of two application functions — image generation and document construction — augmented by provider-side web search and page fetch, driven from a single streaming turn loop over server-sent events. Documents are produced by a Markdown-to-office pipeline in which the model writes structured Markdown and the server renders it to .docx, .xlsx, .pptx, or .pdf; the presentation renderer additionally enforces a strategy-consulting slide grammar. Scanned images and image-only PDFs are recognised in the browser through WebAssembly OCR before any upload occurs, so pixels of a scanned document never leave the device. The result is a deployment whose privacy properties follow from where things are placed rather than from promises about how they are handled.
A conventional AI chat product asks the user to configure it. Which model? Which mode — chat, image, code, search? Which API key? These controls are presented as flexibility, but they impose a burden before any value is delivered, and they ask for judgements most users cannot make: the difference between two model names is not legible to someone who simply wants a letter written or a table produced.
Somat, deployed at somat.rominur.com, removes the controls entirely. There is one input box. There is no model picker, no mode switch, no API configuration, and no settings page. When the user asks a question they receive an answer; when they ask for an image they receive an image; when they ask for a spreadsheet they receive a spreadsheet. Capability is discovered through use rather than through configuration.
This is a design commitment with engineering consequences, and the remainder of this paper is about those consequences. Section 2 states the principles. Section 3 describes the turn loop and the tool layer. Section 4 covers the document pipeline. Section 5 covers ingestion and in-browser OCR. Section 6 covers the state and secrecy split. Section 7 covers abuse control for an interface with no login. Section 8 discusses limitations.
Four principles govern the implementation, and every subsequent section is an application of one of them.
P1 — One surface. Everything the product can do is reachable from the conversation. No capability is placed behind a mode, a tab, or a toggle. The cost of this principle is borne by the routing layer: if the user cannot declare intent through a control, intent must be inferred from language.
P2 — Capability on the server. The provider key, model identifiers, and limits are server-only. No value is exposed through a public build-time variable, so none can appear in the client bundle. The system prompt additionally instructs the assistant never to disclose the model, vendor, or version even when asked directly, so the identity is withheld at the language layer as well as the transport layer.
P3 — State on the client. Conversations are persisted in the browser. The server holds no user data at rest, which means there is no user database to secure, migrate, or breach.
P4 — Prefer the device. Work that can be done on the user's machine is done there. Optical character recognition is the clearest case: recognising a scanned page locally means the page image is never transmitted.
A request produces a single server-sent event stream. The route assembles the system prompt and the trimmed conversation, opens an upstream streaming completion, and relays deltas to the browser as they arrive. Tool calls are accumulated across streaming chunks, executed when the upstream turn ends in a tool request, appended to the message list as tool results, and the completion is re-opened — all within the same response stream, so the user sees one continuous reply rather than a sequence of requests.
History is bounded before dispatch rather than after: the oldest turns are dropped until the serialised conversation fits a character budget, with independent caps on a single message and on generated output. Bounding the input at the edge keeps both latency and cost predictable regardless of how long a conversation has run.
The assistant is offered four tools. Two are implemented by the application; two are executed by the provider.
| Tool | Executed by | Purpose |
|---|---|---|
buat_gambar | Application | Generate one image from a description, with aspect ratio and quality arguments |
buat_dokumen | Application | Build a .docx, .xlsx, .pptx, or .pdf from Markdown content |
web_search | Provider | Search the web when the answer depends on current information |
web_fetch | Provider | Retrieve and read a page the user has linked |
Two details of this arrangement are worth drawing out. First, the tool schemas are written in Indonesian, matching the language of the conversation they are selected from; the selection decision is made in the same language as the request that triggers it. Second, the image tool's schema instructs the model to rewrite the user's request into a detailed English image prompt before calling — the interface remains Indonesian while the generation prompt is expressed in the language the image model handles best. This is invisible to the user, which is the point.
Provider-side tools are declared rather than implemented. Search and fetch execute upstream, and their citations return with the completion, so the application carries no crawler, no HTML extraction, and no robots handling. Search is bounded on three axes — results per search, searches per turn, and total results per turn — because each search carries a marginal cost.
Under P1 there is no mode switch, so intent must be inferred. Rather than a classifier ahead of the model, Somat delegates the decision to tool selection itself: the model is given tools whose descriptions state exactly when they apply, and the system prompt directs it to call them without first asking for confirmation when the request is unambiguous. The routing layer is therefore the tool schema, and adding a capability means adding a tool description rather than extending a dispatcher.
Document generation is the feature that most distinguishes the system from a text-only chat, and it rests on one decision: the model never emits a binary format. It emits Markdown, and the server renders that Markdown to the requested format. Language models write Markdown reliably; they do not write OOXML reliably. Placing the format boundary here means a malformed document is a rendering bug in code that can be tested, not a generation failure in a model that cannot be.
Four renderers share the Markdown parse and diverge in mapping. The word processor renderer maps headings, paragraphs, lists, tables, and code blocks to their document equivalents. The spreadsheet renderer maps each Markdown table to a worksheet, using the heading immediately above the table as the sheet name. The PDF renderer performs its own pagination. The presentation renderer is described below. Renderers are imported dynamically per format, so a request for a spreadsheet never loads the presentation or PDF code paths.
Presentation output is where a naive Markdown mapping fails most visibly: headings become titles, bullets become bullets, and the result is a document that has been reformatted rather than a deck that argues. Somat instead constrains generation to a consulting deck grammar, enforced in the system prompt and honoured by the renderer's parse:
Sumber: line becomes a source note in the slide foot.The renderer reads this grammar structurally rather than cosmetically: kicker and source lines are lifted out of the body into dedicated regions, and body height is computed from whether a kicker is present. The prompt and the renderer encode the same document model, so a deck that follows the grammar renders correctly and one that does not degrades to an ordinary slide rather than breaking.
Uploaded files are handled along two paths depending on whether the file carries a text layer.
Text-bearing files — PDF, Word (.docx and legacy .doc), Excel, PowerPoint, OpenDocument, HTML, plain text, delimited data, and source files — are parsed server-side and inserted into the conversation as text. Spreadsheets are converted sheet by sheet, each labelled, so a workbook arrives as identifiable tables rather than an undifferentiated dump.
Image-bearing files — photographs, screenshots, and scanned PDFs — are recognised on the device. A WebAssembly OCR worker configured for Indonesian and English runs in the browser; scanned PDF pages are rasterised locally and recognised page by page under a page cap that keeps the tab responsive, and only the resulting text is transmitted.
This is P4 in its strongest form. A user photographing an identity document or a bank statement is handing the pixels to their own browser, not to a server; the network sees only the extracted characters. The trade-off is honest: recognition quality is bounded by the device, and long scans are slower than a server would be. For the document types users actually photograph, that trade is worth making.
The two halves of the deployment are deliberately asymmetric, and the table below states which side holds what.
| Item | Location | Consequence |
|---|---|---|
| Provider API key | Server environment only | Never in the bundle; cannot be read from the client |
| Model identifiers | Server config only | Absent from responses, prompts, and error messages |
| Conversation history | Browser IndexedDB | No server-side user database exists |
| Generated images | Browser IndexedDB, as data URLs | Chosen over local storage to avoid its size ceiling |
| Rate-limit counters | Server memory, or Redis when configured | Only ephemeral, non-identifying state |
The privacy claim here is structural. A conventional assurance — “we do not retain your conversations” — is a statement about behaviour and requires trust. “There is no database” is a statement about architecture and can be checked from the deployment. Clearing browser data deletes the history because the browser is where the history is, and no deletion request is involved.
The corresponding cost is equally structural: history does not follow the user between devices or browsers, and clearing site data is irreversible. For an unauthenticated public tool this is the correct trade, but it is a trade and not a free win.
An open interface with no login and a metered upstream needs a defence that does not require identity. Somat meters by client address across three independent dimensions, each with a short burst window and a daily ceiling: conversation turns, image generations, and uploads. Image limits are considerably tighter than chat limits because image generation is the most expensive operation available, and a site-wide daily image ceiling sits above the per-address one so that a distributed attempt cannot exhaust the budget by spreading across addresses.
Counters live in Redis when it is configured and in process memory otherwise. The fallback is documented rather than concealed: on a serverless platform each instance keeps its own counters, so effective limits are looser than the configured values. Stating this is more useful than implying a guarantee the deployment does not provide.
Inference is not selection. Under P1 the user cannot force a tool. When intent is genuinely ambiguous, the model may answer in prose where a document was wanted. This is the direct cost of removing controls, and it is accepted rather than solved.
The device bounds OCR. Recognition runs on the user's hardware, so quality and speed vary with it, and long scanned PDFs are capped to keep the browser responsive.
Portability is forfeited. Client-resident history cannot sync, and no server-side recovery exists.
Deck grammar is enforced by prompt. The presentation rules are instructions to a model, not a validator. A deck that violates the grammar renders as an ordinary deck; nothing rejects it. A structural check before rendering would make the guarantee real, and is the clearest next step.
Identity withholding is a policy, not a control. The assistant is instructed not to disclose the model it runs on. Instructions of this kind are known to be circumventable under adversarial prompting; the transport-layer protection of the key is robust, the language-layer withholding of the model name is not.
Somat is an argument that a capable AI product need not expose its machinery to be useful, and that the interface simplification is affordable if the engineering absorbs the cost. Removing the mode switch pushes intent inference into tool schemas. Removing the format selector pushes correctness into renderers that can be tested. Removing the database pushes state into the browser. Removing the server-side OCR pushes recognition onto the device. In each case the user-facing surface gets smaller and the implementation gets more opinionated — which is the trade the system is built to make.