Explicit states
Define roles, prompts and tool access in .sm files. The Decision router can select declared states with a probability threshold.
Self-hosted · Built in Rust
Give your AI agents a runtime. Praxis connects your models to explicit workflows, practical tools and checks that determine when the work is done.
Web dashboard, terminal chat and Discord.
One runtime on your own machine.
RMB · Toutcome: committed
verified: trueCompletion requires current receipts. What is verified depends on the checks in your contract.
Choose your models
01 / The runtime
The model chooses an action. Your workflow defines the capabilities it can use and the evidence needed to move forward.
Define roles, prompts and tool access in .sm files. The Decision router can select declared states with a probability threshold.
Opt into capabilities with preconditions, postconditions and rollback. Failed source checks can restore the original file.
Require current, task-owned execution receipts before a state transition or completion. A model's claim alone cannot satisfy a receipt guard.
02 / Workflows
Praxis Decision IR maps a compact instruction to a trusted capability. The same contract, verification and receipt rules apply.
Use your normal chat model, including Ollama. The verified Rust workflow is an opt-in example you can adapt to your project.
Set up the IR workflow# Operator-selected project, checked first
[workspace]
required_files = ["Cargo.toml", "Cargo.lock"]
required_directories = ["src"]
[decision_ir]
R = inspect_file
M = verified_rust/modify_source
B = verified_rust/build_workspace
T = verified_rust/run_workspace_tests
C = agent_complete{"ir":"1 R {\"path\":\"src/main.rs\"}"}03 / Packages
Tools, services, the dashboard, the TUI, memory, scheduling and skills arrive as packages. The kernel loads them, authenticates callers and keeps every authority.
Tools, routes, UI, assets and migrations live in plugin.json. Install, upgrade or remove a package without patching the runtime; missing, disabled or unready code fails closed.
A package declares the role it wants and the operator grants it. Install never enables a tool, starts a service or hands out authority; lifecycle hooks run under an allow/ask/deny policy with their scripts pinned by hash.
Packages define which checks and resources matter. The kernel runs the checks, observes the outcome and signs the receipt a guard requires — a plugin cannot certify its own claims.
04 / Setups
xis installs a complete setup — plugins, workflows, personas and a config profile — from a repository you pin yourself. Every artifact is content-addressed and the index is signed against the key you pinned, so a repository can never vouch for itself.
You see the whole plan first: every file written, kept, backed up or removed, and every environment value you must supply. Files apply with keep, backup or overwrite, and an ownership lock means an upgrade or removal touches only what the setup owns — a file you edited is reported and left alone unless you force it.
Plugin packages are delegated to praxis plugin install, so the kernel keeps its hooks policy, its lockfile and its trust store. What you must change afterwards lands in one change report: required environment, applied settings, backups and the exact praxis plugin trust commands. Secrets are never written and grants are never automatic.
# pin a repository and its signing key (your decision)
xis repo add standard https://getpraxis.boo/repo --key ed25519:…
xis search vim
xis plan standard/[email protected]
xis install standard/[email protected]
# later: upgrade, or remove only what it owns
xis upgrade vim-states
xis remove vim-states --keep-data
xis motdowned files · hashes · versions — your edits survive05 / Your workspace
Configure the runtime once. Talk to it through the interface that fits the task.
Chat, inspect context and tool history, configure secrets, manage plugins and view workflow state.
http://localhost:1337Use the chat TUI with local history, provider login, streaming answers and conversation controls.
praxis tuiConnect an optional Discord bot for text and voice. Add QEMU VM tools and media plugins when needed.
Discord setup06 / Get started
Build with a recent stable Rust toolchain. Interactive onboarding prepares the installation assets and provider settings and installs the shipped plugins. Add optional capabilities as packages when you need them — the terminal UI, the dashboard and the tool packages below.
Read the setup guidegit clone https://github.com/wasser-quest/praxis.git
cd praxis
cargo build --release --locked
./target/release/praxis install-preset compatibility --directory "$PWD"
./target/release/praxis onboard --interactive
./target/release/praxis runhttp://localhost:1337.Dashboard: 0.0.0.0:1337 · Gateway API: 0.0.0.0:3537. Use your server's hostname for remote access. Keep access behind your firewall, VPN or authenticated TLS proxy.
praxis install-preset compatibility --directory <install> fills in what a source checkout cannot ship: workflows, prompts, skills, dashboard files, the shipped plugin folders and the VM runtime assets. It installs public files only — never a service, a secret, a provider call or a tool flag. Upgrades add --update-dashboard (previous files are backed up) and a one-time --enable-vm-tools --data-dir <data> grants the VM tools. Then onboarding writes your settings and praxis run starts. Whole setups — plugins, workflows, personas and a config profile in one signed bundle — arrive with xis, its plan and its change report.
Select an existing project with praxis run --workspace-dir /path/to/project. Installation assets stay at ROOT_DIR. The runtime checks the prepared project before calling the model.
07 / Install
One install command for every plugin: praxis plugin install. Packages that compile from source add --build, and that is the only difference. Copy the block and you have everything — or run only the lines you want.
Everything lands in PLUGINS_DIR (default DATA_DIR/plugins): one directory to list (praxis plugin list), verify (praxis plugin verify) and remove (praxis plugin uninstall <name>). The terminal UI is installed in step 3 and started in step 5 — praxis tui finds it in PLUGINS_DIR, beside the kernel, on PATH, or where PRAXIS_TUI_EXECUTABLE points.
The only things with nothing to install are the kernel-bundled packages — file_ops, runtime_control, memory, RAG, cron, Discord, interaction, skills, workflow authoring. They are always registered; praxis plugin builtins lists them.
# 0) build the kernel and the setup manager
cargo build --release --locked
cargo build --release --locked -p xis
PRAXIS=./target/release/praxis
# 1) public assets: workflows, prompts, skills, plugin folders, VM files
$PRAXIS install-preset compatibility --directory "$PWD"
# 2) all ten tool & media plugins, dependency-ordered
$PRAXIS plugin install-default --preset examples/presets/shipped-plugins.json
# or one at a time: $PRAXIS plugin install ./plugins/brave_search …
# 3) frontends & tool packages — --build compiles them from source
$PRAXIS plugin install --build ./plugins/tui
$PRAXIS plugin install --build ./plugins/dashboard
$PRAXIS plugin install --build ./plugins/shell
$PRAXIS plugin install --build ./plugins/legacy_file_ops
$PRAXIS plugin install --build ./plugins/vision
$PRAXIS plugin install --build ./plugins/xis
# 4) asset packs: coding, learning, persona, workflow
for pack in coding learning persona workflow; do
$PRAXIS plugin install "./plugins/asset_$pack"
done
# everything above lands in one directory (PLUGINS_DIR, default DATA_DIR/plugins)
$PRAXIS plugin list
$PRAXIS plugin verify
# 5) the terminal UI is installed now — start it and talk to your agents
$PRAXIS tui
/login openai sk-…one directory to list, verify and remove