Praxis

Self-hosted · Built in Rust

From a decision
to a verified result.

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.

Workflow / verified codingIllustrative example
Requested action

Apply the change.
Prove it passes.

  1. 01
    Read & decideInspect source and its current hash
    R
  2. 02
    Apply a contractSnapshot, modify, check or restore
    M
  3. 03
    Verify the resultBuild and test the current workspace
    B · T
Execution receiptoutcome: committed
verified: true
Runtime
verified

Completion requires current receipts. What is verified depends on the checks in your contract.

Choose your models

01 / The runtime

Make the workflow
part of the system.

The model chooses an action. Your workflow defines the capabilities it can use and the evidence needed to move forward.

01

Explicit states

Define roles, prompts and tool access in .sm files. The Decision router can select declared states with a probability threshold.

02

Actions with contracts

Opt into capabilities with preconditions, postconditions and rollback. Failed source checks can restore the original file.

03

Evidence for completion

Require current, task-owned execution receipts before a state transition or completion. A model's claim alone cannot satisfy a receipt guard.

02 / Workflows

Small instructions.
Defined effects.

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
verified-implementation.smWorkflow excerpt
# 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
execute_decision{"ir":"1 R {\"path\":\"src/main.rs\"}"}

03 / Packages

A small kernel.
Installable packages.

Tools, services, the dashboard, the TUI, memory, scheduling and skills arrive as packages. The kernel loads them, authenticates callers and keeps every authority.

01

Everything is a declaration

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.

02

Trust is granted

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.

03

Evidence, not claims

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.

Read the trust model

04 / Setups

Whole setups.
Signed and planned.

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.

How xis works
xisSetup sketch
# 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 motd
xis.lock.jsonowned files · hashes · versions — your edits survive

05 / Your workspace

Work where you are.

Configure the runtime once. Talk to it through the interface that fits the task.

01 / Browser

A dashboard
for the details.

Chat, inspect context and tool history, configure secrets, manage plugins and view workflow state.

http://localhost:1337
02 / Terminal

Stay in
your terminal.

Use the chat TUI with local history, provider login, streaming answers and conversation controls.

praxis tui
03 / Discord

Bring agents
to your channels.

Connect an optional Discord bot for text and voice. Add QEMU VM tools and media plugins when needed.

Discord setup

06 / Get started

Your next agent
starts here.

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 guide
Build & start
git 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 run
Open the dashboard at http://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.

The standard preset

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.

For verified coding

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.

Project setup

07 / Install

Install everything,
in one place.

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.

Every install command
InstallEverything, in order
# 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-…
PLUGINS_DIRone directory to list, verify and remove