Frequently Asked Questions

What is Hoziron?

Hoziron is an enterprise AI agent infrastructure platform. It provides a model-agnostic runtime for deploying, managing, and orchestrating AI agents with built-in data sovereignty, compliance guardrails, and multi-provider support. It's a compliance-ready distribution targeting the insurance vertical.

Do I need a licence to run Hoziron?

Yes, always — this is not optional and there is no bypass, dev-mode flag, or environment variable that skips it. hoziron-server verifies a signed carrier licence at $HOZIRON_HOME/licence.json on boot and refuses to start meaningful work without one, even for a fully local/air-gapped, no-cloud-provider deployment (the routing gateway that dispatches every model call is what's gated, not just cloud access). See Getting Started: the carrier licence gate for the full flow — send your carrier ID/name to Hoziron to have one issued, then hoziron-cli licence status to check what's installed.

What happens if my licence expires?

Cloud routing stops (falls back to RejectCloud — the default expiry behaviour) while local-model routing keeps working; the ops dashboard surfaces the expiry. A missing or corrupt licence file, or a bad signature, is a hard boot failure with a specific diagnostic message — the server won't start at all until it's fixed. See ADR-034 for the full expiry-behaviour table.

What LLM providers are supported?

A broad set of cloud drivers ships in the kernel — Anthropic, OpenAI, Groq, Gemini/Google, DeepSeek, Mistral, Cohere, xAI, Bedrock, Vertex AI, and several more — plus local/self-hosted drivers (Ollama, vLLM, LM Studio, Lemonade) and a generic openai-compatible driver for anything else that speaks the OpenAI chat-completions wire format (Azure OpenAI, LiteLLM, in-house shims, etc). Which ones are actually eligible for routing is controlled entirely by your config.toml's [[provider]] inventory (ADR-053) — a driver being compiled in doesn't mean it's usable until you declare an instance of it.

Can I use local models?

Yes. Declare an Ollama or vLLM [[provider]] and rank it in [routing_gateway.local].preference (and omit or leave empty any cloud [[provider]] entries). This is the recommended setup for air-gapped deployments — see the local models guide. A licence is still required even for a fully local setup; it's what makes the routing gateway itself willing to start.

How do I add a new provider?

Add a [[provider]] block to config.toml with an explicit driver (one of the compiled-in driver names above — never inferred from id) and, for cloud drivers other than anthropic, a url. There's no [default_model] field anymore; instead, rank the provider/model in [routing_gateway.standard] (cloud-eligible) or [routing_gateway.local] (local-only) preference lists. See Install via Binary for worked examples.

What's the difference between a skill and a competency?

A skill is a tool the agent can invoke (query a database, call an API, read a file). A competency is a complete behavior definition — it bundles a system prompt, required skills, configuration, and metrics. Think of skills as individual capabilities and competencies as complete job descriptions.

How does PII protection work?

Data flowing between agents in multi-agent workflows passes through a PII tokenization pipeline. Detected PII (names, ID numbers, policy numbers) is replaced with opaque tokens before crossing agent boundaries. Each agent has its own isolated memory scope — no cross-agent memory access is possible. The carrier's own carrier-pii-policy.toml (operator-set, not agent-configurable) governs which PII types can reach which provider class — see ADR-034.

Can agents communicate with each other?

Not directly. Agents are isolated by design. They communicate through workflow steps — the workflow engine passes outputs from one agent as inputs to another, with PII tokenization applied at each boundary. This ensures data sovereignty and prevents information leakage.

Is my data sent to cloud LLM providers?

Only the messages that route to a cloud provider under your PII policy and routing config. If you use local models exclusively (Ollama/vLLM), no request payload leaves your network. The platform itself stores all state locally in SQLite — nothing phones home. (Licence issuance is a manual, offline exchange of a carrier ID and a signed file — not a runtime network call either.)

How do I run Hoziron air-gapped?

1. Use local models (Ollama or vLLM) instead of cloud providers — declare them under [[provider]] and rank them in [routing_gateway.local], and don't declare a hoziron_cloud/BYO cloud provider
2. Get a licence issued with no --anthropic-api-key (a local-only licence still requires the base signed licence file — see the licence gate)
3. Transfer packages offline using hoziron-cli catalog export / hoziron-cli catalog import

See the air-gapped deployment guide.

How do I create my first agent?

There's no hoziron-cli agent new command — agents are authored as installable packages. Install an agent-template package from a catalog registry and activate it in one step: hoziron-cli catalog install <package> --activate. See Your first agent for the full flow, including what to do if you don't have a registry configured yet.

What's the performance overhead?

Minimal. Each agent uses ~10 MB base memory plus conversation context. CPU is negligible when idle and bursts during LLM interactions. The platform is a single Rust binary — no JVM warmup, no garbage collection pauses. A 2-core, 2 GB machine can run 5+ agents comfortably.

How many agents can I run?

Depends on your hardware and conversation volume:

Idle agents have negligible overhead. Active agents consume resources proportional to conversation length and LLM call frequency.

How do I back up my data?

All platform state lives in $HOZIRON_HOME/data/. Your carrier licence ($HOZIRON_HOME/licence.json) and config.toml live one level up, directly under $HOZIRON_HOME — back those up too, since a lost licence file means asking Hoziron to reissue it.

# Stop the server process (Ctrl+C, `kill <pid>`, or `systemctl stop hoziron`)
cp -r $HOZIRON_HOME/data/ $HOZIRON_HOME/licence.json $HOZIRON_HOME/config.toml /backup/hoziron-$(date +%Y%m%d)/
# Restart it
hoziron-server

Or use the built-in backup command, which packages platform state into a single archive:

hoziron-cli backup create
hoziron-cli backup list
hoziron-cli backup restore <file>.tar.gz

For live backups (SQLite supports concurrent reads):

sqlite3 $HOZIRON_HOME/data/hoziron.db ".backup '/backup/hoziron.db'"

Can I migrate from another platform?

There's no automated import tool. Hoziron agents are packages with their own manifest/definition format (hoziron-cli package init --type agent-template <name>), so bringing an agent over from another framework means re-authoring its system prompt and model config as a package by hand — see Your first agent. Data integrations use standard protocols (PostgreSQL, REST APIs, S3), so reconnecting data sources is straightforward.

What happens when I uninstall an agent?

Uninstalling removes the agent from both the Core store and the kernel registry, clears its conversation history, and frees its memory scope. The agent must be in Terminated state before uninstall (stop it first). Audit trail entries for the agent's activity are preserved. Use hoziron-cli catalog uninstall <name> or the dashboard's uninstall action.

How do I contribute a package?

1. Scaffold it: hoziron-cli package init --type <skill|competency|agent-template|workflow-template|integration> --name <name>
2. Build the archive: hoziron-cli package build ./my-package/
3. Lint it against ADR-003 rules: hoziron-cli package lint ./my-package/
4. Publish: hoziron-cli package publish ./my-package/ --notes "what changed"

There's no separate local-signing step — hoziron-cli package publish runs lint → build → upload in one pipeline, and the registry signs the package at publish time, not your local machine. Use hoziron-cli package verify ./my-package/ beforehand if you just want to check the content hash without touching a registry, and hoziron-cli package provenance <name> afterward to see the signed version history / fork lineage.

See the publishing guide for full details.

Related:

• Getting started
• Troubleshooting
• Architecture overview