vela

---

Many teams already use AI, but the usage pattern is still highly individual: knowledge stays scattered across private chat histories, workflows are hard to reuse, and collaboration lacks a stable way to retain what works.

VelaClaw is an attempt to address exactly that.

It can run on your own machine, connect to the models you already use, and keep skills, memory, and workflows close to the local working environment. When a team joins, that model does not collapse into one shared pool: each member still keeps an isolated runtime and private memory, while useful experience is curated, reviewed, and gradually added back to the team's shared knowledge base.

It is not another chat window. It is a way to turn AI from a personal tool into a team capability that can compound over time.

✨ What VelaClaw adds

VelaClaw combines a local AI runtime, a self-evolving knowledge engine, and a governed team collaboration layer in one system.

🧬 Evolution engine

VelaClaw adds an evolution pipeline that can draft new shared assets from anonymized team digests and recurring session patterns.

👥 Team collaboration

VelaClaw is designed so knowledge can be shared while member runtimes remain isolated by container boundaries, policy, and explicit publication flow.

📊 Positioning

🎬 Demo

Demo	What it shows	Start here when
Demo 1	Local gateway, browser dashboard, first chat	You want to verify VelaClaw runs locally
Demo 2	Team workspace, member invite, control-plane UI	You want to see the team runtime model
Demo 3	Propose → review → publish shared knowledge	You want to understand the governance loop
Demo 4	Session digests → generated shared assets	You want to see how knowledge compounds over time

This demo takes you from a clean install to the browser Control UI. It is the fastest way to verify that VelaClaw can run locally, connect to a model provider, and keep a usable chat session through the gateway.

npm uninstall -g velaclaw
npm install -g velaclaw
velaclaw setup --wizard

Start the gateway in one terminal:

velaclaw gateway run

Open the dashboard from another terminal:

velaclaw dashboard

If the browser does not open automatically, open http://127.0.0.1:18789.

After the dashboard connects, it should look like this:

Try this first prompt in the Chat tab:

Summarize what VelaClaw can do in three bullets, then show one safe next step.

You should see the assistant response stream into the dashboard. When tools run, the Control UI shows live tool output cards, and the session remains available through the gateway after refresh.

This demo shows the team control plane: a manager creates a workspace, opens the team UI, invites a contributor, and verifies that the member is provisioned without sharing private chat history.

Start the team control plane in one terminal:

velaclaw init team-demo
cd team-demo
velaclaw start

The control plane listens on http://127.0.0.1:4318 by default.

From another terminal in the same team-demo directory:

velaclaw team create \
  --name "Product Team" \
  --slug product-team \
  --manager-label "Team Lead"

velaclaw team invitations create product-team \
  --invitee-label "Alice" \
  --member-email alice@example.com \
  --role contributor

velaclaw team invitations accept <invite-code> --identity-name "Alice"
velaclaw team show product-team
velaclaw team members list product-team

Expected result:

Created team: product-team (Product Team)
Invitation created: code=<invite-code> (alice-example-com-...)
Accepted: memberId=alice-example-com-... port=18800
Team: Product Team (product-team)
Members: 1
Pending invitations: 0

Open http://127.0.0.1:4318/team/product-team to inspect members, invitations, shared assets, evolution state, and the audit trail:

This is the handoff point from solo usage to governed team usage: every member gets an isolated runtime, while team-visible assets and actions go through the control plane.

This demo shows how reusable team knowledge moves through the governed shared-asset path. A contributor proposes a checklist, a manager approves it, and the asset becomes published team knowledge.

Start from the product-team workspace created in Demo 2. First get the member id:

velaclaw team members list product-team

Then propose a shared skill as that member:

velaclaw team assets propose product-team \
  --category shared-skills \
  --title "PR Review Checklist" \
  --submitted-by-member-id <member-id> \
  --content "Review pull requests by checking tests, migrations, auth boundaries, rollout risk, and rollback plan."

Check the review queue, approve the proposal, and verify that it is published:

velaclaw team assets list product-team
velaclaw team assets approve product-team <asset-id> --approved-by-member-id manager
velaclaw team assets list product-team
velaclaw team show product-team

Expected result:

Asset <asset-id> → pending_approval
<short-id> shared-skills [pending_approval] PR Review Checklist
Approved: <asset-id> → published
<short-id> shared-skills [published] PR Review Checklist
Assets — drafts: 0, pending: 0, published: 1

The team page now shows the asset in the shared library and records both the proposal and approval in the audit trail: