Team memory · Vartio

Know what your
teams are doing

What are your teams working on? What has changed? What needs a closer look? Vartio’s goal is to bring agent work across the organization into view, starting with verified run history and building toward live team visibility.

What it does
  1. The planned layer will check signed run packages and whether their signing keys were authorized before storing them.
  2. It will keep verified records in Ahti and recognize duplicate packages.
  3. It will build team views and comparison baselines from those stored records.
  4. It will record who accepted a baseline through a signed acceptance record.
  5. Raw evidence will stay on the originating machine unless an authorized person signs its release. These team-layer capabilities are specified, not implemented yet.
Where it sitsFull architecture →

Work

Taso

What is the task, and what counts as accepted?

Control

Ote

What stays live, and what must stop?

Continuity

Solu

What survives when an agent changes?

Observation

Selko

What actually ran?

Team memory

Vartio

What is happening across the teams?

Component roles: Taso declares and judges work; Ote supervises live resources; Solu preserves the work; Selko records activity; Vartio’s team memory is planned. This is a responsibility map, not a completed integration.
How it works

From individual runs to a team view.

Selko records on the machine and seals a run as a signed Behaviour Commit. Vartio’s specified ingest path will verify the package through Perusta’s canonical Rust implementation, then store verified members as generic records in Ahti.

Elixir/OTP supplies supervision and transport. Fleet views and baselines are projections over stored records. Acceptance adds a signed reference; changes of status append new records instead of rewriting history.

Current scope: the team layer is specified, not yet implemented. The current design covers signed run history and comparisons. Real-time visibility into ongoing work across teams is a further product direction, not an implemented or fully specified capability. The existing runtime has gRPC transport, GitHub and Kubernetes-audit webhook receivers, and a read-only operator UI from the earlier attribution product. Signed-commit ingest awaits the canonical trust types and Selko package push.

Read the Vartio repository →

Built with
Elixir/OTP, Ahti and a planned canonical Rust verification process.
Planned records
Verified commit packages, trust records and signed acceptance references.
On gaps
Missing evidence stays explicit; signatures do not imply complete capture.
Boundary
Remembers and accepts; local systems retain enforcement and authority.