Workspace identity
Membership, roles, invitations, active workspace state, and accountable human identities provide the boundary around agent work.
Read governance architectureArchitecture and operating model
The operating layer around the agent
Praxis Agents OS connects identity and runtime context to typed tools, approval policy, execution, schedules, and audit. It complements model providers and agent frameworks rather than replacing them.
Public pre-release build. Core runtime and governance foundations are available now.
System boundary
Own the organisational layer, keep the components replaceable
The model and orchestration framework remain choices inside the implementation. Praxis owns the shared operational environment around them.
Model providersReasoning, generation, embeddings, and specialist services remain replaceable components.
Agent runtimePydantic AI and project runtime code assemble instructions, history, capabilities, and model calls.
Praxis servicesWorkspaces, agents, tools, skills, files, knowledge, memory, schedules, approvals, audit, jobs, and storage.
Private capabilityOrganisation-specific agents, interfaces, workflows, tools, integrations, rules, and data.
A run inside Praxis
Identity before action
Agent execution begins inside an organisational boundary, not as an anonymous model call with ambient access to every tool.
IdentityThe principal and active workspace define the organisational boundary for the run.
ContextInstructions, bounded history, active resources, skills, files, knowledge, memories, and model choice are assembled through shared seams.
AuthorityAssigned tools and a server-derived run envelope constrain the effects the run may perform.
ExecutionTool calls pass through one typed registry and audited dispatch path.
RecordRun state, tool activity, approval decisions, schedules, and audit events remain inspectable.
Controls and context
What the public build does today
Everything below is implemented in the repository today. The project is still pre-release: production email transport and self-service password recovery are absent, while Code Mode, native sandboxed computation, model failover, durable replay, and user-developed applications remain active or planned work.
Typed tools and policy
Tools declare their provider, input and output contracts, mutation behaviour, and effect scope before the runtime dispatches them.
Read runtime architectureApproval and run envelopes
Unapproved external writes can suspend under a require-approval policy; scheduled and delegated runs carry explicit authority.
Review completed runtime plansKnowledge and persistent memory
Hybrid knowledge retrieval, provenance-tracked memories, conversation compaction, and operator surfaces for reviewing and correcting stored context.
Read the context architectureSelf-hosting
Control creates operational responsibility
The project includes a local Docker Compose flow around the API, web app, worker, and Postgres. Turning that foundation into a production deployment still requires deliberate infrastructure and operational ownership.
Read setup guidance ->- 01Infrastructure, database, storage, and worker operation
- 02Provider accounts, model access, credentials, and secret management
- 03Updates, monitoring, retention, backups, and incident response
- 04Tool policy, approval rules, workspace roles, and operational ownership
Inspect the project
Read the code, architecture, and roadmap together
Current behaviour lives in the public repository. Architecture notes explain the intended boundaries; the roadmap makes unfinished work visible.