> For the complete documentation index, see [llms.txt](https://docs.visdom.virtuslab.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.visdom.virtuslab.com/visdom-orchestrator/user-guide.md).

# User Guide

Definitions, flows and runs. Everything else hangs off those three.

The Orchestrator runs coding agents as governed, repeatable workloads instead of as a person sitting at a terminal. What it manages is the execution side of the software lifecycle: which agent runs, on what input, in what order, under whose approval, against which budget, with what allowed to leave the pod, and what evidence is left behind.

{% hint style="info" %}
The Orchestrator does not decide **what** an agent should know (that is Context Fabric) and it is not where a developer's local coding session lives. It is where a task goes when it should run without a human driving it, repeatedly, in an environment somebody has to answer for.
{% endhint %}

Three things are worth understanding before anything else, because everything in the UI is one of them:

* **Definitions**: containers, MCP servers and agents. Reusable, versioned, forked from a signed catalog or written from scratch.
* **Flows**: a graph of nodes and edges. Nodes are agents, decisions, approvals, loops, sub-flows and gates; edges carry either data between named ports or bare sequencing.
* **Runs**: one execution of a flow. Each node run becomes a Kubernetes Job, events stream back live, and the run holds the audit trail, the costs and the artefacts.

Everything else (memory, comments, chat, quotas, egress, adapters) hangs off those three.

The frontend is organised into six sections: Workspace, Build, Operate, Govern, Benchmarks and Account. The pages below follow roughly that order.

{% hint style="info" %}
**Recommended reading order**: [Concepts and the object model](/visdom-orchestrator/user-guide/concepts-and-the-object-model.md) → [The catalog](/visdom-orchestrator/user-guide/the-catalog-install-fork-upgrade.md) → [Configuring an agent](/visdom-orchestrator/user-guide/configuring-an-agent.md) → [Flows](/visdom-orchestrator/user-guide/flows-nodes-ports-and-edges.md). That is the same order as doing it: fork one agent from the catalog, get it running alone, then wire it into a graph. [Known limitations](/visdom-orchestrator/user-guide/known-limitations.md) is worth reading before you plan around a feature.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.visdom.virtuslab.com/visdom-orchestrator/user-guide.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.