Platform · Syncratic · Architecture
One governed path — for humans and agents.
Every capability in Syncratic is an API surface, and the layers underneath are deliberately decoupled: serving, background processing, and data each scale, inspect, and upgrade on their own. This page walks the critical design choices that make the platform safe to bet a large operation on.
API-first by construction
Agentic-ready, because the platform was never UI-first
The platform's interfaces were designed as APIs before they were screens. That single sequencing decision is why governed agents, automation, and external applications arrive as ordinary clients — not as a retrofit.
API-First
Every capability is an API surface
Search, Ask, Explorer, Graph, Insights, document delta, and threads are exposed as compact /api/v1 facades. There is no capability hidden behind the UI that an automation cannot reach.
Agentic-Ready
Agents ride the governed path
Service-account clients and AI agents call the same interfaces a person uses, with owner-bounded permissions, the same privacy gates, and the same audit trail. Non-human traffic is first-class, not bolted on.
One Contract
No shadow integration tier
Because every caller passes through one governed path, there is no parallel pipeline to secure, audit, or maintain. The agentic-governance mechanics are detailed on the AI Gateway page.
How policy, privacy, spend, and evidence govern every call before a model is invoked: see the AI Gateway.
Scaling principles
Decoupled by design, scalable by structure
Large operations need flexibility and control. Syncratic separates the application layer from the data layer and splits background work into dedicated classes, so each part of the deployment can be sized, secured, and changed on its own schedule — not the platform's.
A stateless serving tier
Interactive and API traffic lands on services that hold no session state of their own. Add replicas behind your load balancer and capacity follows demand — no re-architecture at twice the users.
Specialized worker classes
Background work is split into dedicated worker classes — enrichment, graph construction, change detection, knowledge events — each consuming its own event queues. Ingestion storms never starve interactive queries, and each class scales to its own load profile.
A pluggable data layer
Relational, vector, graph, and cache stores run as independent services behind the application layer. Swap, size, back up, and secure each store on your own schedule, with your own infrastructure choices.
Boundaries and packaging
Independence is the enterprise feature
The same decoupling that scales the platform also gives an enterprise control over it: explicit boundaries between planes, versioned contracts between components, and cloud-native packaging throughout.
Control plane and data plane, separated
Configuration, identity, and policy operate as a control plane distinct from the data processing it governs. Each fails, recovers, and upgrades independently, so a policy change never risks in-flight work.
Event contracts between runtimes
Components communicate through versioned, well-defined events rather than shared internals. One side can deploy without the other consenting. Coupling is a decision, not an accident of the codebase.
Cloud-native packaging
Helm/K3s deployment with image pinning, readiness APIs, and per-class autoscaling. The platform is containerized, declaratively configured, and observable from the start — deployment evidence replaces assumptions.
Conceptual dataflows
Three flows you can trace end to end
The layered structure shows up in how data actually moves. Each flow crosses the same boundaries — governed entry, event queues, specialized processing, stores — which is precisely why each can scale without disturbing the others.
- 01
Ingestion
Uploads and connector syncs enter through one governed path, land on event queues, and are picked up by the worker class built for them — enrichment, graph construction, change detection — before settling into the stores as indexed, related knowledge.
- 02
Retrieval
A query fans out across retrieval modes — lexical, semantic, and graph — assembling evidence from the stores it is permitted to touch, with boundary decisions applied at the store, not the interface.
- 03
Reasoning
Assembled evidence passes the Privacy Engine before any model role sees it. The model answers with citations back to source; the invocation, the policy decisions, and the evidence trail are all recorded.
- 04
Events back into the platform
What reasoning produces — threads, insights, signals — is persisted as governed knowledge, so the next question starts further ahead. The flows compose instead of terminating.
Data sovereignty
Local custody. Local processing. Local enforcement.
Sovereignty is not a deployment option bolted onto this architecture; it is how the architecture is drawn. Data stays inside your boundary, processing happens inside your boundary, and the rules that govern both are enforced inside your boundary. Nothing about scale requires any of it to leave.
Boundaries enforced at every store
Tenant and user scopes are enforced where the data lives — across every store in the deployment — not just checked at the API edge. A boundary is a property of the data, not a filter on the way in.
Privacy enforced before models
The Privacy Engine gates what context may reach a model role, with reversible tokenization and admin-configurable modes. Evidence is governed before any reasoning happens, not after.
Deployment-local model roles
Model roles bind to private, deployment-local models or approved external endpoints — your choice, per role. With offline-safe licensing and air-gapped operation, scale does not cost you custody.
Governed knowledge assurance
See the architecture run.
We will walk the layers on live data: an agent invoking Search through the governed path, a worker class scaling to an ingestion storm, and the audit trail both leave behind.