> 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/the-concept.md). # The concept The platform is built around one observation: an autonomous flow from issue to pull request is not "a coding agent connected to a repository". It is a production process, and it needs four capabilities that no single coding agent provides. Those four are not a conclusion from the last two years. Fifteen years of building developer tooling kept producing the same four, at every scale of organisation. What agents added was not a new item on the list. It was the removal of the margin that made living with the old four possible. Each had been calibrated on the assumption that a human sat on the other side: a forty-minute build was tolerable because a person committed a few times a day; knowledge could stay in people's heads because a person knew to go and ask; review could be narrow because the stream of changes was narrow too. **Organisational context.** An agent has to understand not only the code, but the conventions, the dependencies between repositories, the real ownership of modules and the architectural decisions taken years ago. That capability is provided by **Visdom Context Fabric**. **Orchestration and oversight.** A multi-stage flow (analysis, implementation, validation, pull request, fix-and-review iterations) has to be definable, versioned, observable, interruptible and repeatable. That capability is provided by the **Visdom Orchestrator**. **Independent validation.** AI-generated code has to be verified by layers the model cannot talk its way past: deterministic gates, risk review and tests that hold against regression. Those capabilities are provided by **Visdom Code Review** and **Visdom Testing**, each with its own section. **Control and accountability.** An organisation needs to know what an agent did, when, why and at what cost, and to be able to prove it. Those capabilities are provided by **Visdom AI Tracing** and **Visdom Security**. ## The surface that ties them together Tying them together is the **Visdom Control Plane**: a shared management surface (projects, users, RBAC, secrets) for the components that are deployed. The numbers (process metrics, cost, attribution) are produced and served by AI Tracing. This division answers the obvious question about what the platform adds over using coding agents directly against a repository. In Visdom the coding agent is a **replaceable executor of one step**: the driver layer covers Claude Code, Codex, IBM Bob and others, and the list is open, because a driver is a configuration point rather than a fixed set. The value of the platform is everything around it: context, orchestration, validation, policy and audit. Those are precisely the elements that decide whether generated code can be deployed safely. ## What distinguishes the platform **A complete orchestration model, not an agent wired to a repository.** Versioned flow definitions, approval gates, policies and failure handling form a coherent production model in which the coding agent is one replaceable step. **Network-level control of AI traffic, applied before the fact.** A transparent platform proxy intercepts all agent-to-model communication: content is scanned for secrets and sensitive data *before* it leaves the environment, rather than detected afterwards in logs. **An audit trail that cannot be disputed.** Every prompt, model call and file change sits in a cryptographically signed, immutable chain of events, verifiable offline by an auditor. **Cost engineering built into the model, not bolted on afterwards.** A flow separates work that needs a model from work that does not: polling, cloning, parsing and posting run as deterministic tasks, and review depth is proportional to assessed risk. Token consumption is measured per model, project, flow and author, and reducing it is continuous platform work rather than something an organisation is left to discover on its own invoice. **One way of working across the organisation.** MCP servers, skills, model allowlists and tool configuration are defined centrally and versioned, instead of every developer assembling their own set. That is what makes an agent fleet governable: what is available, what is approved, and what was actually used are all answerable questions. **Self-hosted by design.** Full on-premises operation as an architecture, not a deployment mode. --- # 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/the-concept.md?ask=&goal= ``` `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.