ruv.sgit.airUv + sgit

For Ruflo, AgentDB, RuVector and MetaHarness users · Agentic Engineering Live, London · 15 Oct 2026

Run your Ruflo hive with a written mandate per role and a vault for what it remembers.

Ruflo is an agent meta-harness for Claude Code and Codex: a queen-led hive-mind, 100+ specialized agents, a policy engine with legacy, observe and enforce modes that writes a decision receipt for each action, and AgentDB memory with HNSW search. RuVector adds a self-learning vector database with sub-millisecond queries, native or in the browser; MetaHarness scaffolds your own focused agent harness, like Ruflo. sgit.ai builds on them: an Agent Behaviour Policy compiles into Ruflo's own enforce mode, and an sgit vault keeps the hive's memory files encrypted on your machine, versioned and cloneable.

ruv.sgit = a Ruflo hive + sgit vaults + Agent Behaviour Policies.

Measured here. POC1: the same 11 actions through Ruflo's policy engine, 6 stopped in enforce mode with ABP rules (4 denied, 2 sent for approval), both of Ruflo's hash-chained receipt ledgers valid. The ruv.sgit runner, every run in the ledger: an ephemeral vault, deleted after the run; none of the probed text from the delivered files found in any byte the vault server stored; a fresh clone identical to what was delivered.

  1. 1 · Try an ABP in your Ruflo projectRuflo's policy engine in enforce mode, with rules compiled from a per-role mandate. No secrets needed. git clone https://github.com/SGit-AI/SGit-AI__Website__Ruv.git && cd SGit-AI__Website__Ruv && npm ci && npm run poc1 POC1 →Replicate →
  2. 2 · Keep your hive's memory in a vaultRuflo's memory DB files, encrypted on your machine, a branch per role, merged, then restored from a fresh clone. In the checkout from step 1; needs an sgit vault you created (its key in VAULT_KEY) and an SG/Send token in SGIT_TOKEN, both from the environment. pip install sgit-ai==0.21.0 && ROLE=coder bash poc/poc2-agent-memory-in-vault/run.sh write rm -rf .vault-memory && bash poc/poc2-agent-memory-in-vault/run.sh read POC2 →The ruv.sgit runner →
  3. 3 · Hand the setup brief to your agentOne page written for any agent with a shell: pinned Ruflo and sgit, a hive, two vaults, a check at every step. Needs an SG/Send token in SGIT_TOKEN. "Set this up and do run 1 with the objective below." The setup brief →
ruflo 3.56.10@ruvector/wasm 0.2.1metaharness 0.4.17sgit-ai 0.21.0rUv's projects: MIT, by rUv / ruvnet · ours: Apache-2.0
ruv.sgit, the equation: a Ruflo hive + sgit vaults + Agent Behaviour Policies. Open it full size · final frame.

The story in one table

Every row is one of his pieces, one of ours, and what you get when they meet. Each row is backed by a proof of concept on this site.

His pieceOur pieceTogetherProof
Ruflo hive-mind: a queen and workers (Ruflo ships 100+ specialized agents; POC1's ABP covers 6 roles)One ABP row set per roleA swarm whose every role has a written mandate; the policy engine enforces it and writes receiptsPOC1
RuVector / Ruflo memorysgit vaultAgent memory that is encrypted client-side, versioned, branched per agent, merged, and cloned onto a fresh machinePOC2
RVM capabilities (7 rights)ABP rowsCapability tokens compiled from a mandate, with the withheld rights listed and the reason keptPOC3
RuVector WASM in the browserA page served from a vaultAsk "can the coder send email?" offline, and get the row, the decision and the receipt hashPOC4
MetaHarness scaffold settings (permissions, witness manifest)ABPPolicy as code (his) and policy as a written, owned document (ours), diffed both waysPOC5
Ruflo inside Claude Code (MCP or plugin)Session record in a vaultA real swarm session, with its policy receipts, kept where only the key holder can read itPOC6

Where sgit.ai plugs in

The ABP is a JSON document per deployment: for each agent role, what it can reach, what it is mandated to do, the gap between the two, the barrier that closes it, and the owner who answers for it, valid until a date. It compiles into the enforcement points rUv's stack already has.

The vault is where everything that must survive and be reviewed goes: the ABPs, the compiled policies, the receipts, the agent memory, the session records. Files are encrypted on the client before upload; the server stores ciphertext under opaque ids. One vault is published on purpose, with its read key, so you can open it: the public demo vault.

ABP (JSON) ──compile──▶ Ruflo AgenticPolicyEngine (allow / deny / approval + receipts)
           ──compile──▶ RVM capability rights (READ WRITE EXECUTE ... + withheld)
           ──render───▶ MetaHarness governance settings (diff both ways)
           ──render───▶ browser viewer (RuVector WASM search over ABP rows)

sgit vault ◀── receipts, reports, ABPs       (ruv-pocs-public, read key published)
sgit vault ◀── memory snapshots per agent    (ruv-pocs-memory, private)
Hub and spoke: ABP and sgit vault in the centre, spokes to Ruflo policy engine, RVM, MetaHarness, RuVector memory and a Claude Code session
The intersection: one mandate, several enforcers; one vault, several writers.

Use cases, not repos

rUv's repositories are big. The way in is by use case: pick the thing you want to do, and the page tells you which of his tools to reach for, which of ours, and the POC that proves it.

USE CASE 1

Govern a swarm

Same swarm, same actions, both through Ruflo's policy engine: in its default legacy mode an agent may send email; in enforce mode with rules from the ABP it is denied, pushes go to a human, and Ruflo writes a receipt for every decision.

How →
USE CASE 2

Remember across runs

Agents write memory on their own vault branch, it merges, and a fresh clone restores it. RuVector already keeps memory in files, with snapshots, copy-on-write branches and attestation; AgentDB adds a cryptographic witness chain. The vault adds client-side encryption and a shared, cloneable history around those files.

How →
USE CASE 3

Prove what happened

Hash-chained receipts from the policy engine, committed to a vault with the ABP that produced them. Tamper-evident, private, replayable.

How →
USE CASE 4

Publish only on approval

A deploy is an approval row. In CI that is a protected environment a named human approves; in the engine it is require_approval.

How →
USE CASE 5

Learn with rollback

SONA, ReasoningBank, Darwin mode change behaviour over time. Versioned ABPs and vault history show what changed, when, and let you revert a learned pattern.

How →
USE CASE 6

Run anywhere

The same ABP and vault in a GitHub Actions job, in a browser page with RuVector WASM, and in a Claude Code session with Ruflo as an MCP server.

How →
Six use-case tiles
The six use cases. Generated infographic; the facts are in the pages.

What was proven, and when

Numbers on this site come from runs recorded under evidence/ in the repository. Nothing here is invented; where a third-party tool differed from its docs, the note is in build notes.

11actions in the swarm trace, evaluated twice
6allowed in Ruflo's default legacy mode; stopped in its enforce mode with ABP rules (4 denied, 2 for approval)
2of those need a named human (approval)
11receipts per run in Ruflo's hash-chained ledger, both ledgers valid
0ABP gaps (reach without mandate and no barrier)
2vaults: one public with its read key, one private

Same swarm, same actions: Ruflo default vs with the ABP

loading…

All six POCs with flows, commands and outputs →

How it all fits

flowchart LR
  subgraph ours["sgit.ai: the mandate and the memory"]
    ABP["ABP
abp/examples/ruflo-sparc-swarm.abp.json"] VP[("ruv-pocs-public vault
read key published")] VM[("ruv-pocs-memory vault
private")] end subgraph his["rUv's stack"] RF["Ruflo AgenticPolicyEngine
legacy | observe | enforce"] RV["Ruflo memory (AgentDB, HNSW)
and RuVector"] RVM["RVM capability rights"] MH["MetaHarness scaffold
.claude/settings.json"] WASM["@ruvector/wasm in the browser"] end ABP -- "compile.mjs → PolicyRule list" --> RF ABP -- "abp_to_rvm.py" --> RVM MH -- "harness-to-abp.mjs" --> ABP RF -- "receipts, report.json" --> VP ABP --> VP RV -- "DB files per role, branch per role" --> VM VP -- "app/ served from the vault" --> WASM CI["GitHub Actions
abp-gate → poc1 → poc3 → poc4 → approval → publish"] --> VP CI --> VM

Diagrams on this site are Mermaid, rendered in your browser from the page source, so they stay in sync with the text. The pictures are generated infographics; the diagrams are the mechanism.