Agentic Engineering Live · rUv in London · 15 Oct 2026 · built the night before

Let the agents go to town. Give each one a mandate, and a memory you can trust.

rUv's stack (Ruflo, RuVector, RVM, MetaHarness) is built for autonomy: swarms, consensus, self-learning, speed. sgit.ai adds the two things autonomy needs to be trusted: a written mandate per agent (an Agent Behaviour Policy) and memory with history that the host cannot read (an sgit vault). This site shows both running inside his tools: in CI, in a browser, and in a Claude Code session.

See the six POCs Understand rUv's stack Open the live app

ruflo 3.56.10@ruvector/wasm 0.2.1metaharness 0.4.17sgit-ai 0.21.0Apache-2.0 (ours) · MIT (rUv's)

Two worlds, one stack: autonomy on the left, trust on the right, overlapping in the middle — Two halves of the same goal. Autonomy without a mandate is a liability; a mandate without autonomy is paperwork.

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 piece	Our piece	Together	Proof
Ruflo swarm: queens and 8 worker roles	One ABP row set per role	A swarm whose every role has a written mandate; the policy engine enforces it and writes receipts	POC1
RuVector / Ruflo memory	sgit vault	Agent memory that is encrypted client-side, versioned, branched per agent, merged, and cloned onto a fresh machine	POC2
RVM capabilities (7 rights)	ABP rows	Capability tokens compiled from a mandate, with the withheld rights listed and the reason kept	POC3
RuVector WASM in the browser	A page served from a vault	Ask "can the coder send email?" offline, and get the row, the decision and the receipt hash	POC4
MetaHarness governance settings	ABP	Policy as code (his) and policy as a signed document (ours), diffed both ways	POC5
Ruflo inside Claude Code (MCP or plugin)	Session record in a vault	A real swarm session, with its policy receipts, kept where only the key holder can read it	POC6

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 signed 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: Ruflo's default lets an agent send email; under the ABP it is denied, pushes need approval, and every decision has a receipt.

How →

USE CASE 2

Remember across runs

Agents write memory on their own vault branch, it merges, and a fresh runner restores it. RuVector's own docs list no encryption at rest and no versioning: this is that layer.

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 by Ruflo's default, stopped by the ABP (4 denied, 2 for approval)

2of those need a named human (approval)

11hash-chained receipts, ledger 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["RuVector / Ruflo memory
HNSW, sql.js"]
    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.