Skip to content

Guides

Task-focused how-tos for running vornik day to day. Each guide assumes you already have a project up and running — if you don't, start with Getting Started and skim the Concepts page first.

Available guides

  • Conversation channels — connect vornik to GitHub, Slack, email, and voice so people can talk to it where they already work.
  • Workflows and LLM controls — author your own workflows and tune the safety, tool-discovery, and reliability controls that wrap every model call.
  • Connect your tools (MCP) — declare a project's MCP servers, restrict each to an explicit set of tools, throttle expensive tools, and inspect it all with vornikctl mcp.
  • Artifacts & outbound file delivery — render markdown to PDF/HTML and deliver files (or a task's output artifacts) to Telegram and email.
  • Autonomy — let a project create and run its own tasks on a schedule, with caps and approval gates that keep it in bounds.
  • Cross-project orchestration — have one project's workflow call another, spawn new projects on demand, or delegate to a remote agent over the A2A protocol.
  • Approvals & human-in-the-loop — put a person in the loop with approval steps, approval-gated autonomy, and mid-run checkpoints.
  • Let your assistant set up Vornik: connect Hermes, Claude or Codex so it can build and run your automations itself, with every credential entered and every change approved on your phone.
  • Set up Hermes with Vornik: Hermes as a broker client with Vornik as its memory, including Vornik and Hermes under separate OS users on one machine.
  • Acceptance check: an assistant sets up Vornik: the per-release manual check for Claude Desktop and Claude Code.
  • Recovering failed work — retry a task, rerun from a step, or apply a structured recovery action.
  • Cost and caching — keep model spend predictable with budgets, dynamic tool budgets, caching, and rate limits.
  • Named secrets — inject credentials into a project's agents as environment variables, scoped to the projects allowed to use them.
  • Signing in to the console — browser sessions: SSO on Enterprise, and exchanging an API key for a bounded session on Community.
  • Observability — the operator dashboards, the spend and Insight views, and the Prometheus metrics endpoint.
  • Storage and retention — understand what vornik keeps, for how long, and how to manage its long-term context.
  • The feature doctor — diagnose and safely enable vornik's opt-in features.
  • Evals — author repeatable swarm test suites with pass/fail predicates and run them with vornikctl eval run, with a regression diff across runs.
  • Clustering and the DMZ webhook relay — scale the worker tier or isolate webhook ingress in a DMZ with a mutual-TLS relay.
  • The automation composer ("Describe it") — describe an automation in plain language and get a validated project + swarm + workflow(s), for requests no gallery template fits.

How to read these

Every guide documents only the configuration and commands you, as the person running vornik, actually touch. Configuration lives in your project YAML files; secrets are always supplied through environment variables rather than written into config. The vornikctl command-line tool is your main interface for inspecting and validating that configuration — see the vornikctl reference for the full command list and the configuration reference for every key.

For unexpected public web redirects, use the installable redirect discovery skill to gather host evidence and report verification or unresolved destinations.