---
title: "Vision"
description: "The runtime model, research direction, and explicit limits of Svit."
---

> Documentation Index
> Fetch the complete documentation index at: https://svit.everruns.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Vision

Give the agent a space to remember, act, and evolve.

Svit keeps memory and executable behavior together in one structured,
self-reflective space. Agents can inspect it, script it, and evolve it through
bounded transactions.

That space should persist across activations and compose through snapshots,
forks, identities, capabilities, and messages.

Svit explores that space as a runtime for long-lived agent work. The goal is to
identify the primitives such work requires and design them together from first
principles.

## The model

A host application embeds one or more **Svit** instances. Each `Svit` owns a
reason/act loop, one durable conversation thread, and exactly one
**process**. The process is the serializable state machine: it contains the
memory tree, named scripts, address, limits, inbox, and committed thread state.
Everruns implements the current loop behind the Svit API, while a
**Reasoner** binds the selected model and provider. The broader model adds
delivery, authenticated identity, capabilities, schedules, projections, and
distributed ownership.

An **activation** is one bounded transition. It receives input, runs a named
script against a working copy, and either commits the resulting state and
effect intents together or commits nothing.

Controlled activations use **VAST: Versioned Atomic State Transitions**. A
request names the process version it observed. At the process serialization
point, it either commits one complete next version, is rejected without state
change, or conflicts because another transition already advanced the process.
VAST does not merge concurrent activations.

```mermaid
flowchart LR
Host["Host application"] --> Loop
Event["Inbox message"] --> Loop
subgraph Svit["Svit"]
    Loop["Reason/act loop"] --> Process
    Thread["Durable conversation thread"] --> Process
    subgraph Process["Process"]
        Activation["Bounded activation"] --> Space["Memory tree"]
        Space --> Memory["Memory"]
        Space --> Scripts["Script library"]
        Space --> Effects["Message intents"]
    end
end
Process --> Snapshot["Snapshot or fork"]
```

The process is portable data plus explicit transition semantics. A Svit
snapshot includes the committed conversation thread, so restore resumes its
history and fork creates an independent child process. The reason/act loop can
inspect the same space that Svit validates, commits, snapshots, and forks.

## One structured space

All guest-observable persistent state should be reachable through one
structured namespace. Memory and executable behavior live in the same value
model, giving the agent one variable space in which to remember and act.

A filesystem, network service, model, database, or other external resource may
be mounted into that space as a typed projection. A projection states its
authority, freshness, cost, and consistency explicitly. This lets the agent
work through one coherent interface while the runtime preserves the real
semantics of external state.

The current implementation supports both in-memory processes and a local Turso
adapter that durably stores one address-keyed stream of process transactions.
Each transaction mutates process state: memory, scripts, inbox/outbox, and
bounded `/thread` metadata. Canonical reasoning events use a separate paged
durable `EventLog`, while Everruns compaction checkpoints retain a compact
model context plus only its necessary raw suffix. Snapshots therefore remain
small. A durable fork shares the exact immutable event prefix and any checkpoint
within it; a process-only fork starts a fresh session.

The storage contract is designed so an object store such as S3 can store
immutable transaction objects and use a conditional head write as the commit
point. That mapping still needs an implemented adapter, single-owner fencing,
ambiguous-write recovery, durable control receipts, and executable distributed
evidence before Svit can claim Durable Object semantics.

## Scriptable and self-reflective

Scripts are process state. An agent can discover, inspect, create, validate,
and reuse its own functional library. Reflection is therefore a normal runtime
operation: the agent can understand its memory, available functions, limits,
and granted capabilities through the same structured space.

Svit Lisp is intended to be approachable and sufficiently general for agent
automation: math, text, collections, structured data, and reusable functions.
Its surface should grow from demonstrated agent tasks while remaining bounded,
versioned, and legible to both the agent and the host.

Memory and scripts evolve transactionally. A successful activation commits
validated memory, staged script changes, and buffered effect intents once. Any
failure preserves the previous committed space in full.

## Processes compose

A committed process can be snapshotted, restored, moved, or forked. A fork
starts a new process from the same committed state and then evolves
independently. This gives a child its own process with explicit lineage, state,
limits, and policy relationships.

Processes can commit addressed message intents. An address identifies where a
future dispatcher should send a message; it does not mean delivery occurred.
Identity, authentication, authorization, and reachability remain separate
concepts. Authority is represented by explicit, attenuable capabilities that
can govern projections, messages, and other effects.

The current implementation does not deliver those intents. Routing, delivery,
global addressing, identity, and capabilities remain future work.

## Security is part of the semantics

Resource limits, transaction boundaries, value validation, and authority
checks are not optional hardening. They define what an activation means.

The long-term goal is a runtime where important properties are stated precisely
and supported by the right evidence: tests, fuzzing, model checking, bounded
verification, or deductive proof. Claims must remain narrower than their
evidence. A sandboxed interpreter alone is not proof of hostile multi-tenant
isolation, and production deployments may still require a WebAssembly or
operating-system boundary.

## Research direction

The current implementation tests the smallest useful part of the idea:

- one process-owned conversation thread and reason/act loop implemented through
  Everruns;
- one serializable memory tree;
- named, self-authored Svit Lisp scripts;
- bounded transactional activations;
- atomic state, script, and outbox changes;
- snapshots, local durable replay, and isolated forks;
- reflection over memory and the script library;
- no ambient filesystem, network, process, environment, clock, or randomness.

The broader direction adds durable message delivery, schedules, globally
resolved process addresses, authenticated identity, capability-controlled
projections, object-store adapters, migration, structural sharing, and stronger
verification. Each addition must preserve a space the agent can inspect,
script, and evolve through explicit semantics.

## What success looks like

Svit succeeds if agents can perform long-lived work in a coherent space they
can understand and evolve, while hosts can bound, audit, persist, snapshot,
fork, and move that work through explicit semantics.

The research should also be allowed to fail. If restricted scripting is too
weak, reflection does not improve agent behavior, forks are not economical, or
secure containment costs too much, Svit may be more valuable as a focused
memory-and-automation capability than as a complete runtime for agent work.

See the [README](https://github.com/everruns/svit/blob/main/README.md) for the runnable implementation and its current
limitations.

Source: https://svit.everruns.com/vision/index.mdx