Architecture
Application and runtime boundaries
flowchart TB
desktop[Desktop v2] --> runtime[SAgents v2]
server[Server v2] --> runtime
custom[Your Python host] --> runtime
runtime --> model[Models and context]
runtime --> tools[Tools and Skills]
runtime --> state[Sessions and execution]
Hosts own authentication, credentials, UI, global conversation indexes, and tool resource bindings. SAgentApplication owns runtime composition and component lifetimes. SessionStore is the authority for Session state and acknowledged events.
Read by topic
- Plugin architecture: registration, configuration, scopes, and host injection.
- Memory: context projection versus durable history.
- Tools and MCP: capabilities and authorization.
- Sandbox lifecycle: suspension and resource release.
- Agent package management · Server Agent platform.
- Resource management · Single-host concurrency.
- Context budgets · Model pool and persistence.
- Local sandbox constraints.
- Full runtime architecture: dependency rules and contracts.
Deployment boundary
The built-in schedulers and session stores do not make a distributed runtime. SQL persistence, per-user limits, and fencing are separate guarantees. Server v2 supports one worker. Native local process execution is not container isolation; security depends on the selected provider and the guarantees it actually enforces.