I’m building Vivacity with Aditya Bhatia and Pavitra Kushwaha. We’re working on the execution layer between an agent and the environments it needs to reason about.
The runtime gives an agent a persistent world: inspect its state, apply an action, simulate forward, fork alternatives, verify constraints, and commit a branch. Different domains can use different simulators behind that interface.
My focus is research and simulation infrastructure. The technical surface spans reasoning stacks, discrete diffusion, and the representation of state through an execution.
The execution loop
A branch starts from a parent state. Actions produce a trajectory; checks determine which outcomes can be committed.
World state→Action→Branches→Verify→Commit
world = create(spec)
state = world.observe()
branch = world.fork()
branch.act(action)
trace = branch.simulate(horizon)
report = branch.verify(constraints)
if report.passed:
world.commit(branch)
Conceptual interface based on Vivacity’s public runtime contract.
PRODUCT RUN / BROWSER-SIDE
An action. A bad outcome. A better branch.
Run the same small world through an explicit safety policy. The orbital dynamics and checks execute in this browser; the policy is illustrative, fixed logic, not an LLM, deployed Vivacity runtime, or customer run. The run is ephemeral and is not saved to a backend.
Live here: physics, branches, checks, replay, trace Illustrative: the rule-based agent policy
Vivacity / Research experiments / 001
Orbital dynamics workbench.
Apply an impulse, inspect the trajectory, and compare counterfactuals. Verify the physics before promoting a branch.
Vivacity / Orbital dynamicsEXPERIMENT 001
parent / two-body
r 1.800 R|v| 0.7454 R/τSTATE SAMPLE
State vector0 / 1600
x
1.80000
y
0.00000
vₓ
0.00000
vᵧ
0.74536
Position in R · velocity in R/τ
Energy residual |E(t) − E₀|0.00e+0
0 → 20.00 τMax 4.98e-11 · auto scale
Specific energy
-0.2778
Eccentricity
0.000
Periapsis
1.800 R
Each fork tests the selected impulse and two alternatives offset by ±12 percentage points. Branch impulses are capped at ±50%.
A circular orbit. Change the velocity, then compare the futures.
Interactive two-body model running in your browser. Illustrates Vivacity’s runtime loop; no production API connection.
Model, units & constraints
This local example integrates Newtonian two-body motion with velocity Verlet. The gravitational parameter μ and central-body radius R are both 1. The initial orbital radius is 1.8 R, with circular speed √(μ/r).
Each branch is simulated for up to 20 dimensionless time units at Δt = 0.0125. Integration stops if the body intersects the central surface. The model excludes drag, perturbations, and multi-body interactions.
Verification checks negative specific energy, analytic periapsis above 1 R, and maximum absolute energy drift below 0.001. Commit promotes the simulated endpoint. Rollback restores the previous parent. Reset restores the initial circular orbit.
State, observations, and rendering
A world state needs enough information to continue execution. In the orbital example, that is position and velocity under a fixed gravitational model. An observation reads some view of that state; the diagram is one such view.
Keeping these concerns separate lets an agent inspect quantities directly. A planning loop can compare energy or clearance without rendering a frame. Rendering becomes useful when a person or a vision model needs to see the result.
Routing an execution
Vivacity’s public architecture puts a router behind the runtime contract. Its backend families include exact physics, scientific solvers, robotics simulators, learned world models, game engines, and private domain backends.
Physics & scientific solvers
Domains with explicit laws, numerical methods, and quantities that can be checked.
Robotics & interactive environments
Contact, kinematics, sensors, geometry, and actions inside an environment.
Learned world models
Predicted observations and transitions, with model uncertainty carried into the decision.
The design question is which execution semantics a branch needs: what state the backend accepts, what an action means, and what guarantees accompany its output.
Verification belongs in the loop
Checks depend on the domain. The orbit above uses energy and periapsis. Other environments need their own constraints, units, tolerances, and failure conditions.
A fork keeps the original world available while an alternative is evaluated. A failed branch can be discarded or revised. A passing branch can become the new state. This makes the consequence of each decision inspectable.
Working on the runtime
Vivacity is taking design-partner conversations with teams building agents, robotics, scientific tools, and autonomy. The useful starting point is a real environment, the actions an agent should take, and the checks that make those actions acceptable.
Vivacity with Aditya Bhatia and Pavitra Kushwaha. We’re working on the execution layer between an agent and the environments it needs to reason about.