Jackson Barnes

This week I've been working on 2 features of the app and arguably the important to really nail. Version control (batch, checkpoints, revisions, etc.) and ordering of items in the context graph that have hierarchical edge relations using fractional indexing similar to how Figma does it (they actually have a good blog post here describing how they implemented it for their use case: Figma - Realtime Editing of Ordered Sequences).

What's really fun to watch is stress testing a single agent's ability to use the app's MCP tools to manipulate a context graph in real-time and have the change appear in the UI instantly, see what breaks, have it generate a comprehensive report and then feed that back into the agentic dev cycle to optimize tool usage. For example, here are some test cases of the prompt I'm using to validate agentic usage of the ordering system:

Fractional Indexing & Reordering Test Cases

Initial State & Flat Operations

Initial order verification (flat + nested hierarchy)
Move item using beforeChildId (insert before target)
Move item using afterChildId (insert after target)
Move to first position (edge case)
Move to last position (edge case)

Nested Level Operations

Reorder at Level 2 without affecting root or Level 3
Reorder at Level 3 without affecting parent levels
Cross-sibling isolation (changes in L1-A don't affect L1-B)
Deep nesting integrity (3+ levels maintain independence)

Ord Value Integrity

Ords are sortable and monotonic within each parent scope
No null/NaN/undefined ord values
Fractional ords preserve sort order ("a0", "a1", "a5", etc.)
Ord compression after full reorders (optimize to "1", "2", "3"...)
Same ord value can exist under different parents (namespace isolation)

Multi-Level Sequential Operations

Sequential reorders across different nesting levels maintain state
Ord updates at one level don't corrupt other levels
Mixed operations (root → L2 → L3) preserve hierarchy
Extracted ords match visual order in items-list

Edge Cases & Error Handling

No-op detection (move item before/after itself)
Edge position moves (first/last) maintain valid ords
30+ sequential random operations don't corrupt state
Concurrent operations at different levels (may fail, document behavior)

Hierarchical Isolation

Parent-child relationships preserved through all operations
No orphaned or duplicate items
Each parent's child ords are independently sortable
Changes at one level don't affect sibling branches

Performance & Consistency

All 27 items persist after 30+ operations
Ord encoding remains efficient (no exponential growth)
Items-list order always matches ord sort order
Data persistence across queries

As you can see there are a bunch! The history test cases follow a similar structure and format to validate things are properly working as intended. Here are some of the version control/history test cases that my agents use for validation:

History & Version Control Test Cases

Recording & Retrieval

Empty history at initialization
Batch created for each mutating operation
History list ordered chronologically (newest first)
All batches retrievable without loss

Batch Structure

Contains operation type (create/update/delete/reorder)
Includes timestamp and affected resources
Records before/after states for each change
Maintains referential integrity

Revert Operations

Single batch revert restores previous state exactly
Revert creates new batch (immutable history)
Multiple sequential reverts work correctly
Double-revert (undo-undo) returns to intermediate state

State Consistency

Reverted state matches pre-operation snapshot
Item creation reversible (item deletion)
Item updates reversible (property restoration)
Unrelated items unaffected by revert

Edge Cases

Read-only operations don't create batches
Invalid batch ID handled gracefully
Cross-space batch revert rejected
Performance acceptable at 100+ batches

Audit Trail

Complete record of all state changes
No missing operations or side effects
Batch metadata includes actor/principal
Multi-revision batches capture all changes

Next Steps

Version control/history had been on the roadmap and a requested feature as it's critical to be able to revert changes actors have made (agents or people) within the system. Having a full immutable audit trail of what operations have taken place can enable a lot of interesting use cases, and will be paramount for collaborative multi-agent knowledge/context capture that happen concurrently over lengthy runs.

Adding optimistic concurrency into the mix is where it becomes even more challenging for the multi-actor editing is what I'll be working on next! Cloudflare's Durable Objects being single threaded, and globally unique, so last write wins does make this a bit easier but collisions and race conditions are bound to happen.