SDK

Build with the kernel. Not around it.

Python agents, a CLI, and REST APIs. Everything you need to wire your domain logic into the cognitive stack — without touching kernel internals.

Python Agents

Four agents cover all external access — LLM, database, vectors, and events. Import them. Call methods. The agents handle connection pooling, retries, and configuration.

LLMAgent

from core.agents.llm_agent

Centralized LLM gateway. Single-turn, multi-turn, JSON-structured output, function calling. Model-agnostic — swap providers via env vars.

complete()complete_json()complete_with_tools()acomplete()

PostgresAgent

from core.agents.postgres_agent

Typed PostgreSQL access with connection pooling, transactions, and query builder. All persistence goes through this — never raw psycopg2.

fetch()execute()transaction()

QdrantAgent

from core.agents.qdrant_agent

Vector storage and semantic search. Manages collections, embeddings, and filtered retrieval. The memory layer for your vertical.

upsert()search()create_collection()

StreamBus

from core.synaptic_conclave.transport.streams

Redis Streams-based event bus. Publish and consume domain events asynchronously. Payload-blind — the bus never inspects your data.

emit()consume()acknowledge()create_consumer_group()

Example

python
# Your vertical's consumer — pure domain logic
from core.agents.llm_agent import get_llm_agent
from core.agents.qdrant_agent import QdrantAgent

llm = get_llm_agent()
qdrant = QdrantAgent()

# Semantic search + LLM reasoning in 3 lines
context = qdrant.search("collection", query, limit=5)
answer = llm.complete(
    prompt=f"Given {context}, answer: {query}"
)

CLI Reference

The vit CLI manages the full lifecycle — from bootstrapping the kernel to installing packages, upgrading versions, and rolling back if something breaks. Zero installation required: the wrapper auto-configures your PATH and bash autocomplete.

Core

vit statusShow kernel version, health, and running services
vit setupBootstrap a fresh installation
vit logs <service>Tail logs from a kernel service
vit config set <key> <value>Update kernel configuration

Verticals

vit vertical create <name>Scaffold a new domain vertical with manifest + structure
vit vertical deploy <name>Deploy vertical into the running kernel
vit vertical listList installed verticals and their status

Packages

vit install <package>Install a .vit package (service, order, vertical, or extension)
vit remove <package>Remove an installed package and its dependencies
vit list [--all]List installed packages or all available packages
vit search <query>Search the package registry
vit info <package>Show package details, dependencies, and compatibility

Updates

vit updateCheck for available kernel updates (read-only)
vit upgradeApply kernel upgrade with smoke tests and automatic rollback
vit planPreview upgrade plan without applying (dry-run)
vit rollbackRevert to the previous version via git snapshot
vit channel <stable|beta>Switch update channel
vit releaseValidate local release metadata

Vertical Manifest

Every vertical starts with a vertical_manifest.yaml. It tells the kernel what your domain looks like, what it needs, and which components it implements.

The manifest is declarative — no code. The kernel reads it at deploy time and wires your vertical into the pipeline.

domain_namestring

Your domain identifier (e.g. "healthcare", "legal")

domain_versionstring

Semver version of your vertical

compatibility.min_core_versionstring

Minimum kernel version required (e.g. "1.2.1")

compatibility.max_core_versionstring

Maximum kernel version, supports wildcards (e.g. "1.x.x")

compatibility.contracts_majorinteger

Must match the kernel's contract major version

compatibility.update_channelstring

Subscribed channel: "stable" or "beta"

compatibility.smoke_tests_timeoutinteger

Seconds to wait for smoke tests during upgrade (default: 300)

required_componentsobject

Components your vertical must implement: intent_config, manifest, readme

optional_componentsobject

Optional modules: graph_plugin, governance_rules, slot_filler, entity_resolver_config

notifications.enabledboolean

Enable update notifications on startup

notifications.check_interval_hoursinteger

How often to check for updates (default: 24)

REST APIs

Every kernel service exposes HTTP endpoints. Use them from external systems, dashboards, or custom frontends. All services run behind Docker with standard health checks.

MethodEndpointDescription
POST/api/graph/invokeExecute the cognitive pipeline with a user query
GET/api/memory/searchSemantic search across the kernel's memory layer
POST/api/embedding/encodeGenerate embeddings for text or documents
GET/api/conclave/streamsList active event streams and consumer groups
GET/healthService health check (available on every microservice)

Package System

Everything in Vitruvyan is a package. Services, Sacred Orders, verticals, extensions — all distributed as .vit manifests with declared dependencies, health checks, and smoke tests.

serviceservice-graph

Microservices that plug into the kernel (graph, embedding, MCP, neural engine).

orderorder-babel-gardens

Sacred Order modules — cognitive primitives (Babel Gardens, Pattern Weavers).

verticalvertical-finance

Domain-specific intelligence layers built on the kernel.

extensionextension-mcp-tools

Optional capabilities that extend the kernel without modifying core.

Dependency resolution

The package manager resolves dependencies via topological sort, detects version conflicts and port collisions before installation, and runs health checks after deployment. Removals cascade through the dependency graph — nothing gets orphaned.

Two tiers

Core tier

Managed by vit upgrade. Kernel infrastructure — you don't install these individually.

Package tier

Managed by vit install. Services, orders, verticals, extensions — install what you need.

Update & Upgrade

Kernel upgrades are safe by design. The update engine checks compatibility against your vertical manifests, runs smoke tests, and snapshots the current state before applying. If anything fails, it rolls back automatically.

01

Check

vit update

Fetches available releases from GitHub (Releases API with Tags fallback). Compares against your current version and vertical compatibility ranges. Read-only — nothing changes.

02

Plan

vit plan

Generates an upgrade plan: prerequisites, breaking changes, affected verticals, smoke test schedule. Review before committing.

03

Upgrade

vit upgrade

Creates a git snapshot of current state, applies the update, rebuilds affected containers, runs smoke tests. If tests fail within the configured timeout, automatic rollback.

04

Rollback

vit rollback

Reverts to the pre-upgrade snapshot. Works even if the upgrade partially succeeded. Your data and configuration are preserved.

CI enforcement

The release blocker runs in CI before every publish. It validates all vertical manifests against the new version, checks contract compatibility, and blocks the release if any vertical would break. Violations are not warnings — they are hard failures.

Contracts

The kernel enforces a contract system. Your vertical declares what it implements, and the kernel validates conformance at deploy time. No runtime surprises.

Vertical Contract V1

Required interfaces every vertical must implement: intent config, entity definitions, manifest schema.

Conformance Checklist

Automated validation that your vertical meets all contract requirements before deployment.

Event Envelope

Standard event format for the cognitive bus. TransportEvent (bus-level) and CognitiveEvent (consumer-level).

Update System Contract

Governs versioning, publishing, compatibility constraints, upgrade validation, and rollback procedures.

Package Manager Contract

Defines the .vit manifest format, package types, dependency resolution, and installation lifecycle.

CI Release Blocker

Blocks any release that would break existing vertical compatibility. Runs automatically in the pipeline.

Start building

Install the kernel, scaffold a vertical, and use these APIs to wire your domain logic into the cognitive pipeline.