MOTIONVECTOR  /  A NEW WORLD  /  MANIFESTO 001

We taught machines
to think.
Then we made them
click buttons.

An agent can write a script, edit a scene and render a film. When the result is wrong, the answers are scattered: which version ran, what changed, who approved it? MotionVector is building a runtime where state, permissions and outcomes are explicit.

See the problem The engineering record ↗
01 / KNOWWhat exists right now?
02 / ACTWho may change it?
03 / REMEMBERWhat actually changed?
01 / THE HUMAN PROBLEM

One small edit.
Three different answers.

You ask an agent to make a short film from old photographs. It writes, edits and renders the first cut.

You ask for one change: extend the opening by two seconds. The editor shows ten seconds. The exported video shows eight.

Did the edit fail? Did the render use an older version? Did another agent overwrite it?

To find out, you now need the histories of the editor, render job and stored file. A small edit became an investigation.

ONE HUMAN REQUEST“Finish the opening scene.”
01 / WRITEScriptDraft + references
02 / MAKEScenesObjects + timing
03 / EXECUTERenderOutput + version
04 / DELIVERPublishPublish + access
THE FRAGILE PARTWhich version travels from one step to the next?

Each tool can be correct on its own. Without an agreed version and an account of changes, their results can disagree.

The same problem appears in code, spreadsheets, games and deployments.

02 / HOW WE GOT HERE

Five ways to act.
Different things to trust.

Agents work through screenshots, UI trees, APIs, programs and direct state. Each entry point is useful.

Who checks a result spanning several of them?

01 / SEE

Computer
use

Operates familiar software through pixels and input events.

CUA / screenshots
Hidden state can be missed.
02 / READ

Structured
interfaces

Finds controls through structure; may miss domain rules.

DOM / AX / CDP
A UI tree is a partial view.
03 / CALL

Declared
tools

Exposes named operations; guarantees depend on the service.

APIs / SDKs / MCP / WebMCP
Transactions do not automatically cross tools.
04 / PROGRAM

Code and
commands

Composes operations and can affect outside systems.

Shell / Python / JS
Side effects need controls.
05 / REACH

Direct
state

Touches stored data; unchecked writes may bypass rules.

State / data planes
Must respect invariants.
A successful tool call is not proof that the whole task succeeded.

Databases and services already enforce transactions, permissions and audit logs within their boundaries. The challenge is preserving those guarantees as work crosses boundaries. External integrations cannot promise what their host does not support.

03 / THE MISSING LAYER

An action happened.
What became true?

A click happened. An API returned success. A script exited cleanly.

Which objects and versions did those actions actually change?

A native MotionVector operation names the object and version it intends to change. The runtime checks permission, validates the effect and records the committed result. We want that contract to reach beyond one application.

FIGURE 01 / THE SHARED GROUNDCONCEPTUAL / PROPOSED
Visual
CUA
DOM /
AX
MCP /
API
CLI /
code
Direct
state
MOTIONVECTOR / STATE + EFFECTS
The same object. The same rules. A recorded result.
Identitywhat
Statenow
Actionschange
Authoritywho
Receiptsproof
Domain runtimes / adapters Existing software, systems and devices
Proposed architecture. An external API cannot inherit atomicity or rollback from MotionVector; those depend on its provider. Some outside effects require compensation rather than undo.
THE IDEA IN ONE SENTENCE
If an agent changes your work, you should be able to see what changed, who allowed it, and how to recover.

Screens, terminals and APIs remain useful. Within a native domain, they can operate on one authority-checked state.

04 / MAKE IT CONCRETE

One edit.
Five ways to request it.

Local simulation with pseudocode for the routes. It is not a live engine run or published API reference.
◉ scene_01  /  openingSHARED DOCUMENT STATE
OPENING / COASTLINE_01
OPENING SCENEDURATION 00:08
+2s
scene_01 / version 12CANONICAL STATE / ILLUSTRATION
THE HUMAN REQUEST
“Make the opening scene two seconds longer.”

A visual agent finds the scene in the editor and moves the timeline handle. The runtime still needs to check what changed.

REQUEST / VISUALUI event
Find opening scene → drag edge to 10s
→ submit proposed change
SYSTEM RESPONSE / SIMULATED RECEIPTREADY
object: scene_01
duration: 8.0s
version: 12
waiting for an operation…

The entry point changes. The checks stay the same. Try the edit, revoke write access, or submit a stale version. The local state changes only after validation.

MODEL / ILLUSTRATION ONLY

A timeline, a typed scene and a command can refer to the same object and version.

Third-party effects remain subject to the connected system’s own guarantees.

05 / WHAT EXISTS

We built the first test
inside a video engine.

A scene has named objects, editable timing and an output you can inspect.

The archived media engine implements this vertical slice. The wider system is ongoing work.

ENGINEERING SNAPSHOT / AUGUST 2026DOCUMENTED IMPLEMENTATION

A structured scene.
A shared operation library.

AUTHORDocIRScene objects, assets and timing
CHANGEValidate + patchValidation and addressed edits
EXECUTESceneIR + rendererGPU rendering and encoded output

The August architecture snapshot records one Rust operation library beneath CLI and MCP interfaces, plus a TypeScript SDK and a document-to-render pipeline. Current build and conformance status require verification against the live repository.

RECORDED CLI INTERFACEEXAMPLE COMMANDS / NOT EXECUTED HERE
# Validate a structured document
runtime-cli validate --ir film.json --json

# Apply a supplied patch to an object
runtime-cli patch film.json edit.json --out next.json

# Produce a rendered artifact
runtime-cli render --ir next.json --out film.mp4
01 / DOCUMENTED

The media foundation

Documented in the August snapshot: DocIR, SceneIR, validation, patches, renderer and CLI / SDK / MCP.

02 / IN PROGRESS

Beyond the editor

Browser, terminal, game and AgentSpace prototypes. Integration and cross-domain conformance remain open.

03 / RESEARCH GOAL

A wider computer

Accountable cross-domain state and effects, bounded by what each integration can enforce.

SCOPE OF THE EVIDENCE

The media implementation supports the authoring/rendering thesis. It does not prove cross-application transactions or a finished OS. The earlier interaction is a simulation. Read the architecture, boundaries and next experiments ↗

06 / THE SYSTEM

Agents propose changes.
The runtime enforces the rules.

A model proposes an action. Domain rules define validity. Explicit grants govern access and effects.

A proposal grants itself no authority.

01

Know what exists.

Give each supported object a stable identity and a known version.

02

Define what can change.

Define operations and validate their preconditions before commit.

03

Keep authority narrow.

Limit each agent to granted objects and actions.

04

Remember what happened.

Record committed changes and the evidence needed to inspect them.

01
People + agentsGOALS / INTENT / APPROVAL

Set goals, inspect outcomes and approve consequential actions.

02
AgentSpaceIDENTITY / ENVIRONMENT

A scoped environment on a supported host.

03
mvec-engineDOMAINS / STATE / VERBS

Typed state, operations and rendering.

04
mvec-osCAPABILITIES / HANDLES / EFFECTS

Identity, grants, handles and effects.

05
mvec-driversHOST / NATIVE ADAPTERS

Adapts established OS and hardware support.

THE PRODUCT IDEA, IN PLAIN WORDSBuild an object model once. Expose it through a UI, CLI or agent tool without duplicating its rules.

The media engine documents shared operations across interfaces. Extending that contract to other domains is the work ahead.

Proposed boundaries: narrow mvec-os; domain rules in mvec-engine; AgentSpace above; host adapters below. Read the technical architecture note ↗

07 / WHY THIS MATTERS

You should be able to
change your mind.

You might want to make a film you cannot animate, a game you cannot program or a tool no company would bother to build.

An agent can help. You should still be able to say: show me the change. Restore the earlier version. Stop before publishing. Let me use a different tool tomorrow.

More people should be able to create difficult things.
They should retain the right to inspect, correct and decide.

01 / BEGINBegin without mastering every tool.

Describe a result; work through defined operations.

02 / SHAPESee the work as it changes.

See the edited object. Approve consequential effects.

03 / KEEPKeep a usable history.

Carry state and history across sessions and compatible tools.

MOTIONVECTOR / A NEW WORLD

When the work changes,
you should know what happened.

Ask a machine to do difficult work. See what it did. Reject a mistake. Carry on. MotionVector is our effort to make that possible at the system level, starting with domains we can build and test.

We are building toward that computer.
Explore MotionVector See the foundations ↑Read the technical note ↗