Skip to main content
Orbit’s software architecture should separate user experience, orchestration, model execution, integrations, data services, and operational controls. The diagram below is a conceptual target architecture, not a claim that every component is deployed.

​
11.1 Client layer

The client handles presentation, user input, session navigation, and visible interaction states. It should not contain privileged secrets or be trusted to enforce server-side permissions. Web, desktop, and mobile clients may share design principles while using platform-appropriate implementation details.

​
11.2 Identity and access

Authentication establishes who the user is. Authorization determines what that user and their agents may do. These functions should remain distinct. A valid session does not imply unrestricted access to every project, connector, model, or administrative operation. Administrative access should use role-based controls, strong authentication, audit trails, and narrowly scoped privileges.

​
11.3 API gateway

The gateway can provide request validation, authentication checks, rate limiting, routing, and consistent error handling. It should avoid logging secrets or unnecessary user content. Abuse controls should protect both service availability and customer accounts.

​
11.4 Orchestration layer

The orchestrator manages task state, model requests, tool calls, timeouts, retries, cancellation, and results. It should track which step is active and ensure that retries do not accidentally duplicate non-idempotent actions such as sending a message or creating a purchase.

​
11.5 Model layer

A model router can select an available model based on task requirements, permissions, cost, latency, and configured preferences. Routing decisions should be observable enough to explain relevant behavior without exposing sensitive infrastructure details.

​
11.6 Tool runtime

Tools should run in controlled environments with explicit input schemas, output validation, time limits, and restricted credentials. Untrusted code should be isolated from the main application and production secrets. Tools should return structured results so the orchestrator can distinguish success, partial success, and failure.

​
11.7 Data layer

Data services may store accounts, project metadata, conversations, uploaded files, preferences, and audit records. Each data type should have a defined retention policy and access boundary. Encryption, backups, deletion workflows, and recovery tests should be part of the design.

​
11.8 Observability

Operational visibility should include service health, latency, error rates, queue depth, model availability, tool failures, and resource utilization. Logs should be designed to diagnose failures without collecting more personal data than necessary.

​
11.9 Deployment environments

Development, staging, and production should be separated. Changes should pass automated checks and, where appropriate, human review before reaching production. Rollbacks should be tested before they are needed during an incident.