diff --git a/content/posts/2026-08-10-aval-interactive-video-format/cover.png b/content/posts/2026-08-10-aval-interactive-video-format/cover.png
new file mode 100644
index 00000000..ef8a8800
Binary files /dev/null and b/content/posts/2026-08-10-aval-interactive-video-format/cover.png differ
diff --git a/content/posts/2026-08-10-aval-interactive-video-format/index.md b/content/posts/2026-08-10-aval-interactive-video-format/index.md
new file mode 100644
index 00000000..9953100e
--- /dev/null
+++ b/content/posts/2026-08-10-aval-interactive-video-format/index.md
@@ -0,0 +1,60 @@
+---
+title: 'Aval: an open source format for interactive video on the web'
+summary: 'I built Aval, an open source container and runtime for interactive video on the web: a built-in state machine, frame-accurate transitions, and packed alpha transparency, decoded through WebCodecs. Here''s what it does, why the web needed it, and what has landed since launch.'
+author: Alex Barashkov
+cover: cover.png
+category: Updates
+---
+
+I've just open sourced **Aval**, a new format for interactive video on the web. It ships with a built-in state machine, frame-accurate transitions, and packed alpha transparency, and it's probably the craziest thing I've ever built with Codex.
+
+I'd been dreaming about this technology for years, mostly because every time we wanted a piece of video on a landing page to *react* to something — a hover, a scroll position, a click, a state change in the UI — we ended up building a pile of workarounds instead of shipping the idea.
+
+## The problem: video on the web is a black box
+
+A `<video>` tag is great at one job: play this file from start to finish. The moment you want something more interactive, the cracks show up fast.
+
+Say you have a product hero: a 3D render of a device that sits idle, then smoothly opens when the user hovers a button, then loops in an "open" state until they move away, then closes. That's four pieces of motion — idle loop, open transition, active loop, close transition — and a set of rules about which one plays when.
+
+With plain HTML video, you have a few bad options:
+
+- **Multiple video files and swap the source.** Every swap means a new load, a new decode, and a visible flicker at the seam.
+- **One long video and seek to timecodes.** Browsers don't seek to exact frames reliably. You ask for 2.400s and land somewhere near it, and "near it" reads as a jump.
+- **Image sequences or sprite sheets.** Frame-accurate, but the file sizes are brutal — you're throwing away video compression entirely.
+- **Lottie or a vector animation.** Wonderful for illustration and UI motion, but it can't represent a rendered 3D scene or real footage.
+
+And then there's transparency. If you want video composited over a page background — a floating object with no rectangular box around it — your options in browsers have historically been narrow, inconsistent, and expensive.
+
+## What Aval is
+
+Aval is a container format (`.avl`), a compiler that produces it, and a runtime that plays it in the browser. Three ideas hold it together.
+
+**A built-in state machine.** Instead of a single timeline, an Aval file describes states and the transitions between them. Idle, opening, active, closing — declared inside the asset, not stitched together in your application code. The runtime exposes those states, so your app just says "go to active" and the format handles what has to play to get there. If you've used Rive for vector animation, the mental model is similar, except the source material can be any video the compiler can eat: a Blender render, screen capture, real footage.
+
+**Frame-accurate transitions.** The runtime doesn't ask the browser to seek. It decodes frames itself through WebCodecs — the low-level browser API that gives you direct access to the decoder instead of the opaque `<video>` element — and composites them on the GPU. That means a transition starts on the exact frame it's supposed to start on, and states join without a flash or a stall.
+
+**Packed alpha transparency.** Alpha channel support in web video codecs is patchy at best, so Aval sidesteps the problem: the compiler packs the alpha channel into the video frame alongside the color data, and the runtime recombines them at draw time. You get transparent video that survives normal video compression, in codecs browsers already decode in hardware.
+
+<Video src="https://video.twimg.com/amplify_video/2077405925183279104/vid/avc1/3840x2160/cPmxGScXFcFhivSb.mp4" width="3840" height="2160" controls muted poster="./video-cover-1.jpg"></Video>
+
+## How it got built
+
+This started as a weekend project with the 5.6 Sol Ultra model. Two things went into the queue: an agentic-first remote FFmpeg service, and a WebCodecs playback and compositing engine. The second one was the gamble.
+
+Codex worked for about 20 hours straight on it. I was honest about the odds at the time: either we get something really dope out of it for the whole community, or it's a complete waste of tokens. What convinced me to let it run is that the models have approached a level where a project like this is worth attempting solo — a custom container format, a compiler, and a GPU compositing runtime is not a weekend's worth of work by any historical measure, and it's the kind of thing that would previously have needed a small team and a quarter.
+
+The first project turned out to be genuinely useful on its own: a remote FFmpeg service designed to be driven by an agent rather than by a human typing flags. It optimizes videos, runs quick quality comparisons between encodes, and extracts stills from footage. If you've read our notes on [creating web-optimized video with FFmpeg using VP9 and H.265](/blog/web-optimized-video-ffmpeg), you know how much of that work is iterative guess-and-check — encode, look, adjust, encode again. Handing that loop to an agent with a service that can actually run the encodes and diff the results removes most of the tedium, and it fed directly into getting Aval's compiler output right.
+
+## What has landed since launch
+
+Thank you to everyone who's tried it and filed issues. Several updates are already in the repository:
+
+- **Safari compatibility fixes.** Multiple issues resolved. Safari's WebCodecs behavior differs from Chromium's in ways you only discover by running into them.
+- **H.265, AV1, and VP9 support** across the `.avl` container, the runtime, and the compiler. Aval no longer assumes one codec: you can pick based on the tradeoff you care about — hardware decode coverage, file size, or browser support — and the format carries that choice through the whole pipeline.
+
+## A word of caution
+
+This is still an early project. It's open source because I think the web needs a shared answer to interactive video, not because it's finished, hardened, and ready to carry your production traffic tomorrow. Expect rough edges, expect the format to change, and please open issues when you hit something.
+
+If you work with motion on the web — product heroes, in-page 3D, transparent overlays, anything that has to respond rather than just play — I'd love for you to try it and tell me where it breaks.
+
diff --git a/content/posts/2026-08-10-aval-interactive-video-format/video-cover-1.jpg b/content/posts/2026-08-10-aval-interactive-video-format/video-cover-1.jpg
new file mode 100644
index 00000000..41c9757b
Binary files /dev/null and b/content/posts/2026-08-10-aval-interactive-video-format/video-cover-1.jpg differ
diff --git a/content/posts/2026-08-10-four-creative-tools-we-built-with-toolcraft/cover.png b/content/posts/2026-08-10-four-creative-tools-we-built-with-toolcraft/cover.png
new file mode 100644
index 00000000..ef8a8800
Binary files /dev/null and b/content/posts/2026-08-10-four-creative-tools-we-built-with-toolcraft/cover.png differ
diff --git a/content/posts/2026-08-10-four-creative-tools-we-built-with-toolcraft/image-1.jpg b/content/posts/2026-08-10-four-creative-tools-we-built-with-toolcraft/image-1.jpg
new file mode 100644
index 00000000..a3c9ba59
Binary files /dev/null and b/content/posts/2026-08-10-four-creative-tools-we-built-with-toolcraft/image-1.jpg differ
diff --git a/content/posts/2026-08-10-four-creative-tools-we-built-with-toolcraft/image-2.jpg b/content/posts/2026-08-10-four-creative-tools-we-built-with-toolcraft/image-2.jpg
new file mode 100644
index 00000000..143f3b09
Binary files /dev/null and b/content/posts/2026-08-10-four-creative-tools-we-built-with-toolcraft/image-2.jpg differ
diff --git a/content/posts/2026-08-10-four-creative-tools-we-built-with-toolcraft/image-3.jpg b/content/posts/2026-08-10-four-creative-tools-we-built-with-toolcraft/image-3.jpg
new file mode 100644
index 00000000..d745fa0b
Binary files /dev/null and b/content/posts/2026-08-10-four-creative-tools-we-built-with-toolcraft/image-3.jpg differ
diff --git a/content/posts/2026-08-10-four-creative-tools-we-built-with-toolcraft/index.md b/content/posts/2026-08-10-four-creative-tools-we-built-with-toolcraft/index.md
new file mode 100644
index 00000000..d29990ce
--- /dev/null
+++ b/content/posts/2026-08-10-four-creative-tools-we-built-with-toolcraft/index.md
@@ -0,0 +1,72 @@
+---
+title: 'Four creative tools we built with Toolcraft, and why they aren''t toys'
+summary: 'Since publishing our Toolcraft starter kit, we''ve used it to build four real creative tools: a math-driven three.js scene, a sticker-and-shader mockup app, a web UI that renders in Blender, and a purpose-built animator for a single website section. Here''s what each one does and why it matters.'
+author: Alex Barashkov
+cover: cover.png
+category: Updates
+---
+
+When we published the [Toolcraft starter kit](/blog/how-to-craft-personal-design-tools-with-toolcraft), the idea was simple: instead of waiting for a SaaS product to support the exact thing you need, build the small tool yourself and throw it away when you're done. Since then we've been eating our own dog food while building Toolcraft's own website, and four tools came out of it.
+
+I'm sharing them because the most common reaction to anything made this way is "cute demo." A gradient generator. A pattern maker. Something you screenshot once and never open again. Fair enough — a lot of AI-built demos are exactly that. These four aren't, and the reasons why are worth unpacking.
+
+## The one that's actually about math
+
+If you look at the first demo and assume it's a render from Blender, look closer. It's not — and honestly, it's not that good. It's a [three.js](https://threejs.org/) app, which means everything you see is drawn live in the browser by your GPU.
+
+<Video src="https://video.twimg.com/amplify_video/2078121239156064256/vid/avc1/3840x2160/hKysjY-IaYAeGe10.mp4" width="3840" height="2160" controls muted poster="./video-cover-1.jpg"></Video>
+
+The interesting part isn't the rendering, it's where the shapes come from. Nobody modelled them. There's no mesh someone sculpted by hand in a 3D program. Every surface is the output of a formula — feed in a few numbers and you get a curve, twist it around an axis, repeat it, offset each copy by a fraction of a rotation, and you have a form that looks designed but is entirely computed.
+
+That's what makes it a tool rather than a picture. Because the geometry is math, every input is a parameter you can expose as a slider: number of segments, amplitude, rotation offset, thickness, easing. Move one and the whole thing re-forms instantly. You're not editing a shape, you're exploring a space of shapes, and you can drop the result into a hero section, an explainer animation, or a background loop.
+
+![A three.js scene of computed, repeating geometry rendered live in the browser, with parameter controls for the underlying formula](image-1.jpg)
+
+This is the sort of thing designers historically outsource: describe what you want, wait for a motion designer, get one variation back, ask for the same thing but slower. When the math is in front of you, that loop collapses to seconds.
+
+## Stickers, shaders, and product shots
+
+The second one started as a detour while working on Toolcraft's site. It was inspired by a post from [Fons Mans](https://x.com/FonsMans), mixed with [Paper shaders](https://github.com/paper-design/shaders).
+
+You upload a 3D model, drop your stickers onto it, tweak the shader settings, and shoot. "Shader" is the piece of jargon worth translating: it's a tiny program that runs on the GPU and decides the colour of every pixel. In practice it's what gives you the animated gradient behind the object, the grain, the iridescence, the way the light rolls across a surface. Paper shaders is a library of those effects with controls attached, so instead of writing GPU code you're moving sliders.
+
+<Video src="https://video.twimg.com/amplify_video/2077096663953408000/vid/avc1/3840x2160/DQGFY-Ji6WButLah.mp4" width="3840" height="2160" controls muted poster="./video-cover-2.jpg"></Video>
+
+Here's the concrete reason this earns its place. Say you're launching a feature and you want eight variations of the same 3D object for social, docs, and the changelog — same model, different sticker placement, different background treatment, consistent lighting. In a normal design workflow that's eight rounds of manual file wrangling. Here it's one upload and eight exports, and because the tool is yours, you can add whatever control you find yourself missing on the third export.
+
+![A 3D model in a web app with stickers applied to its surface and an animated shader background behind it](image-2.jpg)
+
+## Customise in the web, render in Blender
+
+The third tool is the one I'm most pleased with, because it steps outside the browser entirely.
+
+While everyone is vibe-coding flat pattern generators, or at best a three.js scene, we went one further: no three.js, no fake web-based depth of field, no emulated focal length. You customise in the web, and the actual frame is rendered by [Blender](https://www.blender.org/).
+
+<Video src="https://video.twimg.com/amplify_video/2074492797260870072/vid/avc1/3840x2160/jAsgCrGo2tZ4Dv29.mp4" width="3840" height="2160" controls muted poster="./video-cover-3.jpg"></Video>
+
+Why that distinction matters: browsers cheat at photography. Depth of field — the soft, out-of-focus falloff behind a subject — is usually faked in the browser with a blur applied after the fact. Focal length, the thing that makes a 35mm shot feel wide and a 105mm shot feel compressed and flattering, is often approximated too. It looks fine until you put it next to a real render, and then it looks like a website effect.
+
+Blender doesn't approximate. It simulates a camera with a real lens, so a wide aperture gives you genuine bokeh, and changing focal length changes perspective the way it would on a physical set. The tool's job is to hide all of that: the web UI is where you position the object, pick the lens, set the focus distance and the materials, and the render happens on the Blender side with the settings you chose.
+
+![A web interface with camera and material controls next to a Blender-rendered frame with real depth-of-field falloff](image-3.jpg)
+
+So instead of "here's my 3D scene, now let me learn Blender's UI," a marketer or designer gets three sliders and a render button, and the output is production quality rather than good-enough-for-a-tweet.
+
+## A tool built for exactly one website section
+
+I don't usually share work in progress, but this last one is the clearest example of the whole idea. It's a creative tool we built specifically to design and animate a single section of a website. Not a general-purpose animation editor. One section.
+
+<Video src="https://video.twimg.com/amplify_video/2079925057673994240/vid/avc1/2880x2160/oaOPNgsyXH_ubvxl.mp4" width="3840" height="2880" controls muted poster="./video-cover-4.jpg"></Video>
+
+Everything in it is under your control, and if a control is missing, you add it. That's the part that no off-the-shelf product can offer. When you're tuning a motion sequence, the thing you need on the fifth iteration is almost never in the menu — the stagger delay between items, the exact curve of the easing, the pause before the loop restarts. In Figma or a video editor you work around it. In a tool you own, you spend two minutes adding the slider and then spend your remaining attention on the design instead of the workaround.
+
+The result is a section that's tuned rather than approximated, and a build process where the designer, not a handoff document, decides how it moves.
+
+## What this set is meant to prove
+
+Taken together, these four cover a decent spread: computed geometry, GPU shader effects, a real offline render pipeline, and a single-purpose animation editor. None of them is a product. All of them solved a specific problem on a specific project faster than the alternative, and each took hours rather than sprints.
+
+That's the argument. The interesting question about AI-built software isn't whether it can produce another gradient generator — it's whether it lowers the cost of a bespoke tool far enough that building one becomes the obvious move. Once it does, the ceiling on what a small team can make stops being "what features does our design tool support" and starts being "what do we actually want."
+
+You can try the live demos for the first three on the Toolcraft site, and if you want to start building your own, the starter kit post has everything you need to get going.
+
diff --git a/content/posts/2026-08-10-four-creative-tools-we-built-with-toolcraft/video-cover-1.jpg b/content/posts/2026-08-10-four-creative-tools-we-built-with-toolcraft/video-cover-1.jpg
new file mode 100644
index 00000000..ef94d35b
Binary files /dev/null and b/content/posts/2026-08-10-four-creative-tools-we-built-with-toolcraft/video-cover-1.jpg differ
diff --git a/content/posts/2026-08-10-four-creative-tools-we-built-with-toolcraft/video-cover-2.jpg b/content/posts/2026-08-10-four-creative-tools-we-built-with-toolcraft/video-cover-2.jpg
new file mode 100644
index 00000000..f95dfcb0
Binary files /dev/null and b/content/posts/2026-08-10-four-creative-tools-we-built-with-toolcraft/video-cover-2.jpg differ
diff --git a/content/posts/2026-08-10-four-creative-tools-we-built-with-toolcraft/video-cover-3.jpg b/content/posts/2026-08-10-four-creative-tools-we-built-with-toolcraft/video-cover-3.jpg
new file mode 100644
index 00000000..12e43af6
Binary files /dev/null and b/content/posts/2026-08-10-four-creative-tools-we-built-with-toolcraft/video-cover-3.jpg differ
diff --git a/content/posts/2026-08-10-four-creative-tools-we-built-with-toolcraft/video-cover-4.jpg b/content/posts/2026-08-10-four-creative-tools-we-built-with-toolcraft/video-cover-4.jpg
new file mode 100644
index 00000000..c5452b88
Binary files /dev/null and b/content/posts/2026-08-10-four-creative-tools-we-built-with-toolcraft/video-cover-4.jpg differ
diff --git a/content/posts/2026-08-10-novu-databricks-railway-recent-launches/cover.png b/content/posts/2026-08-10-novu-databricks-railway-recent-launches/cover.png
new file mode 100644
index 00000000..ef8a8800
Binary files /dev/null and b/content/posts/2026-08-10-novu-databricks-railway-recent-launches/cover.png differ
diff --git a/content/posts/2026-08-10-novu-databricks-railway-recent-launches/index.md b/content/posts/2026-08-10-novu-databricks-railway-recent-launches/index.md
new file mode 100644
index 00000000..801e16ed
--- /dev/null
+++ b/content/posts/2026-08-10-novu-databricks-railway-recent-launches/index.md
@@ -0,0 +1,56 @@
+---
+title: 'Three recent launches: Novu, the Databricks Developer Portal, and a Railway launch video'
+summary: 'A look at three projects that shipped recently — a new homepage for Novu after four years of working together, brand and design work for the Databricks Developer Portal, and a launch video for Railway produced end to end in under two weeks.'
+author: Alex Barashkov
+cover: cover.png
+category: Updates
+---
+
+Three projects went live recently, and while they look different on the surface — a homepage redesign, a developer portal, and a launch video — they say something consistent about how we like to work. Here's each of them, and why the details matter.
+
+## A new homepage for Novu, four years in
+
+Meet the new Novu and its new homepage. I'm glad to have been part of that journey for four years already.
+
+For anyone without context: Novu is open-source notification infrastructure. It's the layer that handles the emails, in-app bells, push messages, and Slack pings your product needs to send — the kind of thing every team builds badly at least once before deciding to outsource it. Its audience is developers, which means the website has an unusually hard job. It has to be credible to someone who will read your docs before they read your pricing page.
+
+Four years is a long time in that market. Over that stretch, Novu's positioning has moved, the product has grown, the category itself has matured, and the homepage has had to keep pace each time. That's the part I find most valuable about long partnerships: by the fourth iteration, you're not relearning the product, the audience, or the constraints. You already know which sections of the page do the persuading, which ones people scroll past, and what the team means when they say something "doesn't feel technical enough."
+
+A new agency would spend the first month getting to that baseline. We spend it on the actual work.
+
+## Databricks Developer Portal: vibe coding, used the right way
+
+Enjoy our recent brand and design project for the Databricks Developer Portal.
+
+<Video src="https://video.twimg.com/amplify_video/2079181347784884224/vid/avc1/3840x2160/WI9dK8QDUzoAG0Lm.mp4" width="3840" height="2160" controls muted poster="./video-cover-1.jpg"></Video>
+
+There's a detail in this project worth talking about beyond the visuals. While many companies now prefer to fully vibe-code their websites, Databricks used vibe coding the right way — mainly for quick prototyping and for communicating the overall page structure and intent.
+
+If "vibe coding" is new to you: it's the practice of describing what you want to an AI coding tool and letting it generate a working page, rather than writing the code yourself. It's genuinely fast. In an afternoon you can have something clickable in a browser.
+
+The trap is treating that output as the finished website. AI-generated pages tend to be structurally plausible and visually generic — spacing that's almost right, a type scale that drifts, components that don't quite belong to the same family, and accessibility and performance treated as afterthoughts. On a marketing site for a company the size of Databricks, those small inconsistencies read as carelessness, and they compound across every page you add later.
+
+What Databricks did instead was use it as a communication tool. Here's the concrete version of that: imagine you want a developer portal landing page with a hero, a set of product entry points, a code sample that switches between languages, and a docs-and-community section. You can write that in a brief and hope everyone pictures the same thing, or you can generate a rough clickable page in an hour and say "this — this is the shape and the priority order, now make it good." The second option removes an enormous amount of ambiguity before design starts. Nobody argues about whether the code sample belongs above or below the product cards, because everyone has already seen both.
+
+Then the brand and design work happens properly, on top of a structure everyone already agreed on. Prototype fast, design deliberately. That's the sequence that works.
+
+## A launch video for Railway, start to finish in under two weeks
+
+Here's the behind the scenes of the launch video production for [Railway](https://railway.com) — from initial request to final release in less than two weeks.
+
+<Video src="https://video.twimg.com/amplify_video/2074843533224103936/vid/avc1/3840x2160/3dwFfHmMdahwtDw9.mp4" width="3840" height="2160" controls muted poster="./video-cover-2.jpg"></Video>
+
+Launch videos have a scheduling problem that's easy to underestimate. The launch date is fixed. The product is often still changing right up to it. And video is the least forgiving format to change late: rewrite one line of narration and you may be re-recording voiceover, re-timing animation, and re-rendering everything downstream of it.
+
+The usual response is to start months early, which doesn't work either, because you end up animating a version of the product that no longer exists by launch day. Two weeks from request to release is only possible if the pipeline is built for it — script, storyboard, 3D and motion, sound design, and revisions all overlapping rather than queued in a strict line, with the sequences most likely to change left flexible until the end.
+
+We've been doing this long enough to have that pipeline, and Railway's team was decisive about feedback, which matters just as much. A two-week turnaround dies the moment approvals sit in someone's inbox for four days.
+
+## The common thread
+
+None of these projects were about picking a nicer typeface. Novu needed a homepage that keeps up with a product and a category that keep moving. Databricks needed brand and design work that could absorb fast AI prototyping without inheriting its sloppiness. Railway needed a launch asset that landed on a date that couldn't slip.
+
+Speed and craft usually get framed as a trade-off. In practice, the teams that get both are the ones who put the fast, messy tools where they belong — early, for figuring out what to build — and keep the careful work for what ships.
+
+If you have a launch on the calendar and a site or video that isn't ready for it, [get in touch](https://pixelpoint.io/contact).
+
diff --git a/content/posts/2026-08-10-novu-databricks-railway-recent-launches/video-cover-1.jpg b/content/posts/2026-08-10-novu-databricks-railway-recent-launches/video-cover-1.jpg
new file mode 100644
index 00000000..3562d049
Binary files /dev/null and b/content/posts/2026-08-10-novu-databricks-railway-recent-launches/video-cover-1.jpg differ
diff --git a/content/posts/2026-08-10-novu-databricks-railway-recent-launches/video-cover-2.jpg b/content/posts/2026-08-10-novu-databricks-railway-recent-launches/video-cover-2.jpg
new file mode 100644
index 00000000..8b53d968
Binary files /dev/null and b/content/posts/2026-08-10-novu-databricks-railway-recent-launches/video-cover-2.jpg differ
diff --git a/content/posts/2026-08-10-text-animation-skill-for-ai-agents/cover.png b/content/posts/2026-08-10-text-animation-skill-for-ai-agents/cover.png
new file mode 100644
index 00000000..ef8a8800
Binary files /dev/null and b/content/posts/2026-08-10-text-animation-skill-for-ai-agents/cover.png differ
diff --git a/content/posts/2026-08-10-text-animation-skill-for-ai-agents/index.md b/content/posts/2026-08-10-text-animation-skill-for-ai-agents/index.md
new file mode 100644
index 00000000..c9d83efe
--- /dev/null
+++ b/content/posts/2026-08-10-text-animation-skill-for-ai-agents/index.md
@@ -0,0 +1,52 @@
+---
+title: 'A framework-agnostic text animation skill for AI agents'
+summary: 'AI agents can write animation code, but they can''t make it feel good — they default to linear fades and round-number durations. So we packaged our designers'' motion specifications into a skill that works with Remotion, GSAP, Motion, or native mobile, and hands your agent the timing, curves, and stagger values instead of leaving it to guess.'
+author: Alex Barashkov
+cover: cover.png
+category: Updates
+---
+
+Ask an AI coding agent to animate a headline and you'll get something that technically works. The text will appear. It will probably fade in over one second, linearly, all at once. It will look like a slide transition from 2007.
+
+This isn't a model problem. It's a knowledge problem. Nothing in a typical prompt tells the agent that a 1000ms fade reads as sluggish, that words revealing on a 40ms stagger feel alive while a 200ms stagger feels broken, or that `ease-out` and a hand-tuned cubic-bezier are not interchangeable. Motion design is a body of craft knowledge, and agents have very little of it. So they guess, and their guesses average out to "fine."
+
+We've been building marketing sites, product videos, and interface motion for long enough that our designers have opinions about all of this — opinions with numbers attached. So we wrote those numbers down in a form an agent can actually use.
+
+## What we shipped
+
+A text animation skill for AI agents. It's framework and language agnostic: whether you're working in Remotion, GSAP, Motion, or building a native mobile app, it helps your agent produce polished text animations instead of default ones.
+
+Every animation in it comes with timing, curves, and specifications crafted by designers — not inferred by a model from whatever animation code happened to be in its training data.
+
+<Video src="https://video.twimg.com/amplify_video/2081762526258176000/vid/avc1/3840x2160/Jnc5QPvPHeAxhGO1.mp4" width="3840" height="2160" controls muted poster="./video-cover-1.jpg"></Video>
+
+## What a "skill" is, if you haven't run into the term
+
+Agent skills are a fairly new idea and the naming doesn't help. Think of one as a reference manual you hand your agent before it starts working — a folder of structured instructions the agent loads into context when the task calls for it. Not a library you install, not an API you call. Knowledge.
+
+That distinction is what makes this approach portable. If we'd shipped an animation library, it would work in exactly one ecosystem, and you'd be stuck with our component API. Instead the skill describes animations the way a motion designer would spec them for a developer: this element, this property, over this duration, on this easing curve, offset by this much from the one before it. Your agent reads the spec and writes the implementation in whatever stack you're already in.
+
+Same spec, different output. In Remotion it becomes frame-based interpolation. In GSAP it becomes a timeline with a stagger config. In SwiftUI it becomes a sequence of animations with custom timing curves. The motion is identical because the numbers are identical.
+
+## A concrete example
+
+Say you're building a product launch video in Remotion and you want the headline "Ship faster" to land with some weight.
+
+Without any guidance, an agent typically gives you both words fading from opacity 0 to 1 over 30 frames, linear. It's not wrong. It's just inert.
+
+With the skill loaded, the agent has an actual specification to follow: each word animates independently, entering from 20px below with a slight blur, over 500ms, on a curve that starts fast and settles gently rather than moving at a constant speed. The second word starts 60ms after the first — enough to read as deliberate sequencing, not enough to feel like you're waiting. The blur clears slightly before the movement finishes, so the text feels like it's coming into focus rather than sliding into place.
+
+Those numbers are the entire difference between "an animation happened" and "this looks like someone made it." And they're precisely the kind of thing nobody types into a prompt, because if you knew them off the top of your head you probably wouldn't be asking an agent in the first place.
+
+## Why this matters beyond text
+
+We think this is the more interesting pattern in agent tooling right now: encoding craft, not just capability.
+
+Agents are already competent at the mechanical parts of frontend work. Where they fall down is taste — the accumulated set of small decisions that separates a competent implementation from a good one. Those decisions are learnable and, crucially, writable. A designer who knows why 40ms feels right can put that in a document, and from then on every agent run inherits it.
+
+That's a meaningful shift for teams without a dedicated motion designer. You don't need someone on staff who has spent years developing an instinct for easing curves. You need that instinct captured once, in a format your tools can read.
+
+Text animation is where we started because it's the highest-frequency need — hero headlines, video titles, onboarding copy, feature callouts. It's also where bad defaults are most visible. But the approach generalises to anything with an established craft behind it.
+
+Give it a try in whatever you're building, and tell us what breaks. We'd rather hear about the gaps than guess at them.
+
diff --git a/content/posts/2026-08-10-text-animation-skill-for-ai-agents/video-cover-1.jpg b/content/posts/2026-08-10-text-animation-skill-for-ai-agents/video-cover-1.jpg
new file mode 100644
index 00000000..11a622f2
Binary files /dev/null and b/content/posts/2026-08-10-text-animation-skill-for-ai-agents/video-cover-1.jpg differ
diff --git a/content/posts/2026-08-10-toolcraft-update-leaner-ai-harness-and-built-in-api/cover.png b/content/posts/2026-08-10-toolcraft-update-leaner-ai-harness-and-built-in-api/cover.png
new file mode 100644
index 00000000..ef8a8800
Binary files /dev/null and b/content/posts/2026-08-10-toolcraft-update-leaner-ai-harness-and-built-in-api/cover.png differ
diff --git a/content/posts/2026-08-10-toolcraft-update-leaner-ai-harness-and-built-in-api/index.md b/content/posts/2026-08-10-toolcraft-update-leaner-ai-harness-and-built-in-api/index.md
new file mode 100644
index 00000000..5f594648
--- /dev/null
+++ b/content/posts/2026-08-10-toolcraft-update-leaner-ai-harness-and-built-in-api/index.md
@@ -0,0 +1,46 @@
+---
+title: 'Toolcraft update: a leaner AI harness and a built-in API on the way'
+summary: 'A new version of Toolcraft is out, with a major overhaul of the AI harness so it burns fewer tokens and spends far less time re-running performance checks, plus component fixes throughout. Next up: a built-in API the CLI can talk to, so an agent can reproduce your presets with different assets.'
+author: Alex Barashkov
+cover: cover.png
+category: Updates
+---
+
+A new version of Toolcraft is out. The headline change is a major overhaul of the AI harness, plus a batch of smaller component improvements and bug fixes. If you've been generating tools with it, the difference you'll notice first is cost and speed: it should consume fewer tokens and spend a lot less time testing performance on subsequent runs.
+
+If you're coming to this cold, the [introduction to Toolcraft](/blog/how-to-craft-personal-design-tools-with-toolcraft) covers what it is and how you'd use it. This post is about what changed under the hood and where it's going next.
+
+<Video src="https://video.twimg.com/amplify_video/2083512258513027072/vid/avc1/1440x1080/QaAMFW64yTsayPOo.mp4" width="1440" height="1080" controls muted poster="./video-cover-1.jpg"></Video>
+
+## What the harness actually does
+
+"AI harness" sounds more mysterious than it is. It's the scaffolding around the model: the instructions, the context it gets, the order in which it builds things, and the checks it runs before it hands you a working tool. When you ask for a generative effect, the agent doesn't just write some code and stop. It has to understand the component it's assembling, wire up controls, then verify the result actually runs smoothly in a browser rather than dropping to a slideshow the moment you drag a slider.
+
+That verification step is where the cost was piling up. Real-time canvas and WebGL work has to be measured, not assumed — a shader that looks fine in a screenshot can still tank the frame rate on a laptop. So the harness would run performance passes, and it would run them again on the next iteration, and again on the one after that, re-learning things it had already established. Every one of those passes is tokens and wall-clock time you're paying for while you sit and wait.
+
+The overhaul reworks how that context and those results carry across runs. The first run still does the work of figuring out what performs well; the runs after it stop starting from zero. In practice that means iterating on a tool — nudging a parameter set, changing how a control behaves, adjusting the visual output — feels much closer to editing than to regenerating from scratch.
+
+<Video src="https://video.twimg.com/amplify_video/2083512352150802432/vid/avc1/1440x1080/7ZOuEl0AsF3vEj5m.mp4" width="1440" height="1080" controls muted poster="./video-cover-2.jpg"></Video>
+
+## Components and fixes
+
+Alongside the harness, several components got improvements and bug fixes. These are the unglamorous ones — controls behaving predictably, edge cases in how effects handle unusual inputs, output that matches what the preview promised. Individually they're small. Together they're the difference between a tool you trust enough to use on real work and a demo you show someone once.
+
+<Video src="https://video.twimg.com/amplify_video/2083512425114972160/vid/avc1/1440x1080/elsXOt7myIXd1FrV.mp4" width="1440" height="1080" controls muted poster="./video-cover-3.jpg"></Video>
+
+## Next: a built-in API the CLI can talk to
+
+The update I'm planning next is a built-in API, with our CLI able to interact with it. The point of that is presets.
+
+Right now, when you build a tool and dial it in until the output looks right, that configuration is yours — a specific combination of parameters that produces a specific look. Useful, but it lives inside the tool, and applying it to a new image means opening things up and doing it by hand.
+
+With an API in front of it, a preset becomes something an agent can drive. Say you've built a tool that dissolves a product shot into particles and you've tuned it until it matches your brand's look: the right density, the right easing, the right palette. Save that as a preset, and instead of repeating the process for the next twelve product shots, you point an agent at the CLI and ask it to reproduce that preset with different assets. Same look, new inputs, no manual re-tuning. The same pattern covers social variants, a set of blog headers, or every card in a component library that needs a generated background.
+
+That's the shape of it: the tool you crafted once becomes a repeatable operation rather than a one-off session in front of a canvas.
+
+<Video src="https://video.twimg.com/amplify_video/2083512454131159040/vid/avc1/1440x1080/J_YeA5bxcTy_-OFK.mp4" width="1440" height="1080" controls muted poster="./video-cover-4.jpg"></Video>
+
+## Try it
+
+The new version is available now — pull the latest and your next run should be cheaper and quicker than the last one. If you hit something that behaves oddly, or you have a preset workflow you'd want the API to support, I'd genuinely like to hear about it before that part is finalised. Enjoy!
+
diff --git a/content/posts/2026-08-10-toolcraft-update-leaner-ai-harness-and-built-in-api/video-cover-1.jpg b/content/posts/2026-08-10-toolcraft-update-leaner-ai-harness-and-built-in-api/video-cover-1.jpg
new file mode 100644
index 00000000..39d0a63f
Binary files /dev/null and b/content/posts/2026-08-10-toolcraft-update-leaner-ai-harness-and-built-in-api/video-cover-1.jpg differ
diff --git a/content/posts/2026-08-10-toolcraft-update-leaner-ai-harness-and-built-in-api/video-cover-2.jpg b/content/posts/2026-08-10-toolcraft-update-leaner-ai-harness-and-built-in-api/video-cover-2.jpg
new file mode 100644
index 00000000..d1951d57
Binary files /dev/null and b/content/posts/2026-08-10-toolcraft-update-leaner-ai-harness-and-built-in-api/video-cover-2.jpg differ
diff --git a/content/posts/2026-08-10-toolcraft-update-leaner-ai-harness-and-built-in-api/video-cover-3.jpg b/content/posts/2026-08-10-toolcraft-update-leaner-ai-harness-and-built-in-api/video-cover-3.jpg
new file mode 100644
index 00000000..095f0a9b
Binary files /dev/null and b/content/posts/2026-08-10-toolcraft-update-leaner-ai-harness-and-built-in-api/video-cover-3.jpg differ
diff --git a/content/posts/2026-08-10-toolcraft-update-leaner-ai-harness-and-built-in-api/video-cover-4.jpg b/content/posts/2026-08-10-toolcraft-update-leaner-ai-harness-and-built-in-api/video-cover-4.jpg
new file mode 100644
index 00000000..cf18a3e8
Binary files /dev/null and b/content/posts/2026-08-10-toolcraft-update-leaner-ai-harness-and-built-in-api/video-cover-4.jpg differ
diff --git a/content/posts/2026-08-10-web-native-grass-simulation-quixel-threejs/cover.png b/content/posts/2026-08-10-web-native-grass-simulation-quixel-threejs/cover.png
new file mode 100644
index 00000000..ef8a8800
Binary files /dev/null and b/content/posts/2026-08-10-web-native-grass-simulation-quixel-threejs/cover.png differ
diff --git a/content/posts/2026-08-10-web-native-grass-simulation-quixel-threejs/index.md b/content/posts/2026-08-10-web-native-grass-simulation-quixel-threejs/index.md
new file mode 100644
index 00000000..44eee892
--- /dev/null
+++ b/content/posts/2026-08-10-web-native-grass-simulation-quixel-threejs/index.md
@@ -0,0 +1,40 @@
+---
+title: 'A web-native grass simulation for $15 and a few million AI tokens'
+summary: 'I built a grass simulation that runs in the browser using Quixel Megascans assets and Three.js. Here''s what it cost, why photoscanned assets change the economics of 3D on the web, and where this kind of thing actually belongs on a site.'
+author: Alex Barashkov
+cover: cover.png
+category: Updates
+---
+
+It cost me $15 on the Epic Games Store and a few million AI tokens to build this web-native grass simulation. No 3D artist, no custom asset pipeline, no render farm. Just a paid asset pack, Three.js, and a lot of iteration.
+
+<Video src="https://video.twimg.com/amplify_video/2080310614300164096/vid/avc1/3840x2160/tOnsdTZwG9Z3UB3j.mp4" width="3840" height="2160" controls muted poster="./video-cover-1.jpg"></Video>
+
+## Why grass is a genuinely hard thing to render
+
+If you've never built anything in 3D, grass sounds like the most boring possible subject. It's the opposite. A convincing patch of grass is tens or hundreds of thousands of individual objects, each one thin, semi-transparent at the edges, catching light differently depending on which way it leans, and all of them moving slightly out of sync when wind passes through.
+
+Games solve this with years of engine work and a hardware budget you control. The browser is a much less forgiving place. You're sharing a GPU with the rest of the user's tabs, you have no idea whether you're on an M-series laptop or a three-year-old Android phone, and every megabyte you ship is a megabyte someone waits for before they see anything at all.
+
+So "web-native" here means something specific: this isn't a pre-rendered video of grass, and it isn't a Unreal Engine build wrapped in a page. It's real geometry, drawn live in WebGL, reacting to the camera and to simulated wind in real time. That distinction matters because a real simulation can respond to a user — scroll, cursor, click — in a way a video file never will.
+
+## What the $15 actually bought
+
+Epic Games owns Quixel, the company behind Megascans: a library of photoscanned real-world assets. Instead of an artist modelling a blade of grass from imagination, someone went outside, scanned actual plants with photogrammetry, and cleaned up the result into textures and meshes with real-world proportions and real-world colour data.
+
+That's the part you can't fake cheaply. The reason most hobby 3D scenes look like hobby 3D scenes is not the shader work — it's that the source material is invented rather than measured. Photoscanned assets skip that entire problem.
+
+The important detail for anyone reading this as a practical matter: those assets aren't locked to Unreal Engine. You can use them in Three.js, which is exactly what we did in this demo. The blade textures and geometry come straight out of the pack; everything around them — instancing so the GPU draws thousands of blades in one pass, a wind function in the vertex shader, thinning density out at distance so you're not paying for detail nobody can see — is ordinary web graphics work.
+
+The "few million AI tokens" is the other half of the cost. Shader work is a tight feedback loop of tiny numerical changes: adjust a noise frequency, look, adjust again. Having a model to draft and revise those passes is what let a project like this happen in evenings rather than over a quarter.
+
+## Where something like this belongs
+
+The fair question is whether any of this is more than a nice toy. It is, but only when the subject and the surface match.
+
+Concretely: imagine a landing page for an outdoor apparel brand, or a sustainability report for an agriculture company. Today that hero section is a stock photo of a field, or at best a looping video that starts playing after a two-second buffer and stops the moment the user scrolls. A live scene does things a video can't. The wind can respond to the cursor. The camera can travel as the user scrolls through the story. The time of day can shift to match a dark-mode toggle. Nothing has to be re-rendered and re-uploaded when marketing wants a different angle — you change a parameter.
+
+The same logic applies to product demos, game studio sites, and anything where the thing you're selling is a physical environment. The reason it hasn't been common is that it used to require a 3D pipeline and the people to run it. Photoscanned asset libraries plus AI-assisted shader iteration collapses that cost by an order of magnitude, and this demo is the cheapest possible proof of it.
+
+None of which means every site needs grass. Most don't. But the ceiling on what a browser can show has moved, and the price of finding out where that ceiling is now sits at roughly the cost of lunch.
+
diff --git a/content/posts/2026-08-10-web-native-grass-simulation-quixel-threejs/video-cover-1.jpg b/content/posts/2026-08-10-web-native-grass-simulation-quixel-threejs/video-cover-1.jpg
new file mode 100644
index 00000000..34ce1420
Binary files /dev/null and b/content/posts/2026-08-10-web-native-grass-simulation-quixel-threejs/video-cover-1.jpg differ