Inside Lone1.io: A Website with Soul, Powered by Faster Motion
Most AI-built websites today look like cousins. Same hero, same gradient, same scroll. Lone1.io doesn't — and it's because of a quietly radical engine running underneath: Faster Motion, the world's first declarative animation runtime designed for AI agents to author motion as freely as they author copy. Lone1's homepage is one .fmtion graph, 77 nodes wide, with a physics simulation and a custom cursor inside it.
The short answer: Lone1.io's homepage is choreographed by a single .fmtion graph — 77 nodes plus a reusable template, wired through 8 scroll-driven sections, including a real-time physics simulation and a custom interactive cursor. Faster Motion (v1.0.6) is the open, declarative, JSON-like format that orchestrates DOM data through the graph. Instead of templating motion, AI agents on Faster compose it node by node — every site gets a fingerprint, not a face-swap.
Sites built by AI tools are everywhere now. Most of them are competent. Almost none of them are memorable. The pattern is familiar: a generic hero, a tidy three-column features section, a soft fade-in on scroll, and a pricing table that could belong to anyone. The output is correct. The output is also forgettable.
Lone1, a strategic technology advisory firm based in Austin, came to Faster with an unusual brief: their brand needed to feel like the people behind it — senior, sharp, deliberate, no decks. The site couldn't whisper "template." So we built it on something that fundamentally rejects templating.
Meet Lone1.io
Lone1 is a senior-operator-led advisory firm — fractional CIO and CTO leadership, technical due diligence for PE and VC, technology strategy, and next-gen data center work for AI and HPC workloads. The voice is direct and editorial. "Sharpen Your Edge." "Technology, translated into outcomes." No boilerplate. No associate decks.
The design ask followed the voice. Spacious. Editorial. Slow on purpose. Numbered like a magazine. Headlines that don't all crash in at once — words that arrive on their own cadence. That kind of pacing is exactly where most site builders fall apart, because pacing isn't a component you can drop in. It's a composition.
What Is Faster Motion?
Faster Motion is the world's first declarative, node-graph animation engine purpose-built for AI agents. Its source format — the .fmtion file — is a JSON-like document that describes a graph: nodes, ports, wires, and parameters. The runtime evaluates that graph against the live DOM each frame, orchestrating transforms, opacity, paths, text, scroll, and state directly on real elements.
Think of it as the spiritual cousin of how shader graphs work in Houdini, or how Rive composes state machines — except the canvas isn't a contained surface. The canvas is the page itself, and the data flowing through the graph is the DOM.
The Core Ideas
- Declarative, not imperative. You don't write "animate this element from A to B." You describe a graph; the runtime decides how to evaluate it.
- Typed ports.
float,vec2,color,transform. Wires only connect compatible types — so motion stays composable, not chaotic. - 200+ node types. Inputs (scroll, mouse, time, DOM events), animation (timeline, tween, stagger, keyframe), procedural (wiggle, noise, spring, oscillator), constraints (follow, aim, drag, path-follow), state machines, paths, text, falloffs, distributions, solvers, media, integration.
- Boundary nodes. The graph reads transforms and properties from the DOM in, and writes them back out. The graph and the page are the same surface.
- Open documentation. The format spec, node registry, and wiring patterns are public — see the Faster Motion docs.
Templating animation is the same mistake as templating words. Both flatten what makes a brand recognizable. Faster Motion exists so AI agents on our platform never have to flatten the motion of a site to ship one.
Why a Graph, Why Now
There are dozens of ways to build a website. They mostly produce the same website. The reason is structural: every AI site builder we've seen treats motion as a finite menu — pick from "fade in," "slide up," "stagger," done. Pick the same five primitives and you get the same five sites.
A graph removes the menu. Faster Motion gives an agent primitives that compose, not presets that approximate. That's why the homepages we generate stop looking like one another. Lone1's hero text doesn't fade-up because every site fades up — it arrives the way it arrives because the agent stitched a specific graph for it. The motion is the brand.
Inside the Graph: A Phase-by-Phase Teardown
The Lone1.io homepage is a single .fmtion file: 77 nodes at the top level, plus one reusable template (titleSpring) instantiated per service tile. There's no hand-coded GSAP timeline, no exported keyframe JSON, no fragile selectors hard-coded against a templated component tree. Just a graph. Here's what's actually inside it.
Phase 1 — Hero entrance (load pulse → split text)
A loadPulse fires the moment the page is ready. It drives a 1.5s pulseTween with easeOutCubic easing. Two textStaggerAnimation nodes split the hero title into characters and stagger them in — translating from 100% → 0% on the Y axis while opacity goes 0 → 1 over a 0.5s total stagger window. A clipPathAnimation node simultaneously sweeps a mask across the hero. The headline doesn't fade in. It composes itself.
Phase 2 — Fixed hero, phased scroll (the "cream pane")
A scrollTrigger bound to .hero-spacer turns the scroll position into a normalized 0→1 signal. Multiple scrollTween nodes tap that signal in parallel: the cream content pane shrinks, the image pane grows full-bleed, the nav fades, the headline slides and fades, and an overlay caption + service labels fade in. None of these are pre-rendered keyframes. They're all live evaluations of a typed signal flowing through the graph.
Phase 3 — Team section rolls over the hero
A second scrollTrigger on .team-goal-words drives a word-by-word reveal — splitText + staggerWrite nodes stitch word offsets into the DOM as you scroll. The team section is layered above the fixed hero with z-index, so it visually "rolls over" the pinned panel below.
Phase 4 — Services pin (template instantiation in action)
The services track is pinned. An elementCount node reads how many services are in the DOM. An expression node converts the scroll progress into an active service index. Then the magic: indexedDispatch fires the titleSpring template once per service — each instance gets its own scoped selector and its own enter pulse via the template's overridable parameters. One reusable subgraph, dispatched dynamically. The same node graph that runs three services would run thirty.
Phase 5 — Portrait pin and the editorial pacing
A scrollTrigger on .pin-wrap pins a portrait section. An expression node remaps scroll progress to the Y-position of an after-element overlay; a domVariablesWrite pushes that value into a CSS custom property. This is the pacing that makes the site feel "slow on purpose" — math nodes hand-shaping the curve, not a preset.
Phase 6 — Why-Us: a real physics simulation, inline
This is the section that broke template-based site builders forever. The "why us" panel contains an actual physics simulation:
physicsWorld— a 2D physics scene with gravityphysicsStaticBody— the curved cup arc that catches the ballsphysicsBodyStagger— balls dropped in with a staggered cadencephysicsMouseDrag— the user can grab and throw the balls with their pointer
The whole simulation is wired into the same scroll-driven graph as the rest of the page. Drag a ball; the physics responds. Scroll past; the balls fade out via a scrollTween. No third-party physics library called from custom JS. The physics is a node type. You wire it like any other input.
Phase 7 — Testimonials with a custom cursor
The testimonials carousel is its own micro-application inside the same file. A cycleClock drives auto-advance. staggerAnimation nodes fade items and quotes. A pointer + hover input pair feeds a domPoseWrite that positions a custom cursor element. A clickStateDispatcher wires Prev / Next clicks through remap nodes into a bidirectionalCounter, then routes to a scrollTo action and a combined progress signal. Mouse position, click state, scroll, and time are all just typed signals being mixed by expressions.
Phase 8 — Outro reveal + vignette
The closing section uses one last scrollTrigger with a textRevealAnimation for the final headline and a propertyAnimation tween that darkens a vignette overlay. Same primitives. Different composition.
The runtime advantage: Because every signal is evaluated live, not pre-rendered, the entire choreography reflows when content changes. Add a service to the pinned track and elementCount + indexedDispatch spin up a new titleSpring instance for it automatically. Edit a headline; the splitText reveal still works. Reorder testimonials; the cycleClock keeps the cadence. Agents can rewrite copy without touching the motion layer.
The vocabulary, by the numbers
Lone1.io's graph uses 31 distinct node types from the Faster Motion 200+ node registry. The most-used categories tell the story:
- Scroll inputs and tweens — 8
scrollTrigger+ 8scrollTween. Scroll is the dominant interaction signal. - Expressions — 10
expressionnodes do all the math: remapping ranges, computing indices, mixing signals. - DOM writes — 7
domPropertyWrite+ 4domVariablesWrite. Boundary nodes pushing typed values straight into CSS variables and DOM properties. - Text choreography — 5
textStaggerAnimation, plussplitText,textRevealAnimation,textSequenceAnimation. Every editorial reveal on the page. - Property and stagger animations — 6
propertyAnimation+ 4staggerAnimation. Generic tweens reused across sections.
What This Unlocks for AI-Native Platforms
Faster is an AI-native CMS. The agents that write your blog, design your hero, and ship your campaign are the same agents that compose your motion. That only works if the motion layer is something AI can actually author, not just call.
Faster Motion is that layer. Three things change as soon as it's in the loop:
- Sites stop converging. Two clients with similar briefs no longer get cousins of the same theme. Their graphs diverge by the second node.
- Brand voice extends to motion. The way a Lone1 headline arrives is part of "no associate decks." A different brand's pacing would feel wrong on Lone1, and vice versa. The graph encodes that.
- Editing stays cheap. Because everything is a typed node graph, agents can swap parameters, replace inputs, or rewire entire sections without rebuilding from scratch. Iteration cost approaches zero.
Key Takeaways
- Most AI-built sites look the same because their motion vocabularies are the same.
- Faster Motion replaces presets with a 200+ node graph runtime authored in
.fmtionfiles (Lone1.io runs on package v1.0.6). - Lone1.io's homepage uses 77 nodes across 8 scroll-driven phases — including a real physics simulation and a custom interactive cursor — composed, not chosen.
- A typed, declarative graph is the only motion abstraction we've found that AI agents can confidently author and iterate on.
- Reusable templates (like
titleSpring) instantiated throughindexedDispatchlet one subgraph scale across N elements without copy-paste. - Open documentation: the spec and node registry live in the Faster Motion docs.
Frequently Asked Questions
What is a .fmtion file?
A .fmtion file is a JSON-like document that describes a Faster Motion node graph — its nodes, the wires between their typed ports, and parameters. The runtime loads the file and evaluates the graph against the live DOM each frame.
How is Faster Motion different from Lottie or Rive?
Lottie plays back a pre-authored animation tree. Rive runs a state machine inside a contained canvas. Faster Motion treats the page itself as the canvas — it reads from and writes to real DOM elements through boundary nodes, and exposes a 200+ node procedural toolkit rather than a fixed timeline.
Why is a graph better for AI agents than presets?
Presets give an agent a finite menu — N choices in, one of N outputs back. A graph gives the agent typed primitives that compose into combinatorially many shapes. The same agent, given the same brief, can produce motion that's specific to a brand instead of a style.
Is Faster Motion only for AI-built sites?
No. Designers and engineers can author .fmtion files directly — the format is human-readable, the docs are open, and the runtime is the same whether the graph was authored by a person or an agent.
Where can I read the docs?
The format specification, the node registry, and the wiring patterns are all public — see the Faster Motion docs for everything.
Is the physics simulation on Lone1.io really running through the same graph?
Yes — physicsWorld, physicsStaticBody, physicsBodyStagger, and physicsMouseDrag are all first-class node types in Faster Motion. They wire into the same expression-and-DOM-write fabric as the scroll tweens, the testimonials cursor, and the hero text. There's no second runtime; the physics is just another typed signal source.
Can the same graph run across web, mobile, and embedded?
The runtime is web-first today, with the DOM as the boundary surface. The .fmtion format itself is target-agnostic — node types like transforms, paths, and state machines map cleanly to non-DOM surfaces, and that's where the runtime is headed.
The Bigger Picture
A website is the most public surface of a brand. If an AI builds a thousand of them and they all look the same, the platform has failed the brand, not the other way around. Faster Motion is our answer to that — the runtime that lets agents on Faster express, instead of approximate.
Lone1.io is one of the first sites in the wild that proves it. It will not be the last.
