documentation · architecture

Architecture

Skyber does not train its own model. It is the layer above the models: it owns your context, decides which model and tools a request needs, and turns the result into something usable.

USER
  |
  v
SKYBER  (session -> entitlement -> orchestration)
  |
  +-- MEMORY   account-wide context, personas, projects
  +-- MODELS   built-in models, your endpoints, your keys
  +-- TOOLS    live search, agents, document pipeline
  |
  v
EXECUTION -> streamed text | generated files | actions

Request flow

1. Session. The browser holds an authenticated session. Every request that touches your data carries it.
2. Entitlement. The workspace routes check your subscription or active test pass before any model call is made. Without one you are sent to the subscribe screen rather than silently downgraded.
3. Assembly. The server builds the request: the conversation's persona and system prompt, recent turns, relevant account memories, any attached documents, and the mode flags you have set.
4. Routing. Intent detection picks the path — plain chat, deep reasoning, vision, search, image generation, or a file-producing workflow — and the conversation's selected model or your own endpoint.
5. Streaming. Tokens stream back as they are produced, so you can steer or stop mid-answer.
6. Persistence. Messages, generated artifacts and any new memories are written back to your account.

The server boundary

Provider keys, entitlement decisions and privileged database access live server-side and are never shipped to the browser. The client receives streamed output and its own rows — nothing else. Access rules are enforced in the database, so authorization does not depend on the UI behaving.

Why this shape

Model quality changes every few months. Context, workflows and output formats do not. By keeping the durable parts — memory, personas, projects, tools, artifacts — in the workspace and treating the model as swappable, upgrading the model never means starting your working relationship over.