We shipped dddk v0.2 — streaming, a non-DOM agent option, and field-specific inline AI
We just shipped dddk v0.2.
For anyone seeing this for the first time: dddk is an AI interaction SDK for web apps. The idea is simple — AI shouldn't only live in a sidebar chatbot. It should understand the current page, help users actually operate the interface, and become part of the product experience instead of just sitting next to it.
v0.1 was about proving the core interaction model. v0.2 is about making that model genuinely useful inside real-world products. Four main changes did most of the work:
1. Streaming
The agent used to feel like a black box — it went quiet, then came back with a result. Responses now stream as they happen, so users can watch the agent think and act. Small change, big difference in how "alive" the UI feels.
2. More built-in tools
We added more default tools, so developers get useful behavior out of the box instead of having to wire every single browser action by hand.
3. A non-DOM agent option
The DOM-based web agent is the safer, more grounded option — it works through the real page, scoped to the user's own permissions. The trade-off is cost and speed: reading the whole DOM uses more tokens, and a long page means a long context, which can soften the agent's performance. Not every product needs that, so v0.2 adds an agent mode that doesn't touch the page DOM at all — lighter and cheaper, for teams that want the AI reasoning without feeding it the whole page.
4. Field-specific inline AI
Inline AI used to behave the same across the board. Now each field can have its own scoped actions — a product-description box, a support-reply box, and a search input can each run entirely different AI behaviors instead of sharing one generic assistant.
We made a short video to show how it actually feels in use, instead of just describing it:
🎬 Video: https://youtu.be/IPc09oyHFis
It's completely open source if you want to read the code or break it:
GitHub: https://github.com/PerhapxinLab/dotdotduck
And you can try the live demo here:
Website: https://dddk.perhapxin.com/
We're also doing a coordinated relaunch on Product Hunt today. If you have a second, a look (or a comment) there genuinely helps us check whether this positioning is clear enough for people landing on it cold:
Product Hunt: https://www.producthunt.com/products/dotdotduck?utm_source=other&utm_medium=social
Quick question for the builders here:
If you were adding AI to your own SaaS, which trade-off would you take — the DOM agent (grounded in the real page and scoped to the user's permissions, but heavier and pricier as pages get long) or a non-DOM agent (lighter, cheaper, faster, but blind to the page)? And what's the biggest blocker keeping you from moving past the traditional sidebar chatbot?
Thanks for reading! Happy to dive into any of the technical details in the comments.
I ran the dddk page through PagePulse because you asked whether the positioning is clear enough for people landing on it.
A few things stood out:
- Fix the navigation language inconsistency — navbar items appearing in Korean on an English page is an immediate credibility and usability failure that can be fixed in minutes
- Make 'Try it live →' visually dominant by increasing button size, using a high-contrast fill color, and removing 'Read docs' and 'GitHub' from the same button row
- Move the 'Try it on this page, Press Ctrl+K' section immediately below the hero to deliver the product aha moment before visitors scroll away
My main read: the technical idea is interesting, but the first screen should probably translate it into the user outcome before the architecture. Something like "add field-specific AI actions inside your product" may land faster than leading with implementation details.
Hope useful — ping me once you've made changes and I'll re-run it
The non-DOM agent option is interesting — does that mean the agent operates on a serialized state representation rather than parsing the rendered DOM? I've been thinking about this from the LLM side: feeding models clean structured state is so much more reliable than asking them to interpret HTML, but the dev ergonomics get tricky fast. How are you exposing that state surface to the agent? Manual annotation, or inferred from the component tree?
let me untangle one thing first: the serialized-state approach is actually the DOM agent, not the non-DOM one.
WebAgent doesn't hand the model raw HTML. It serializes the live DOM into a compact, markdown-like representation with stable hash IDs per element — so the model gets clean structure + content and acts on the IDs, never the styling noise. That's exactly the "clean structured state beats interpreting HTML" reliability you're describing. And to your actual question: it's inferred automatically from the live DOM at runtime — not manual annotation, and not tied to a component tree (works the same on React, Vue, or plain HTML).
The non-DOM agent (TaskAgent) is the other extreme: it reads no page state at all. It runs purely on the prompt and tools you give it, so there's no "state surface" being exposed from the page — you hand it whatever structured context you want. That's the cheap/flexible path for tasks that don't need to see the UI, or screens where there's no usable DOM (canvas/WebGL).
So the dev-ergonomics split you're sensing is the design: WebAgent = auto-serialized page state for free (no annotation); TaskAgent = you fully control the context. What are you leaning toward — auto page-state, or feeding your own?
Thanks for such a thorough breakdown, that auto runtime DOM serialization without manual annotations solves a huge pain point for frontend AI tools
I’m currently building a unified LLM API aggregation layer for dev teams juggling multiple model providers, so this split between UI-aware WebAgent and lightweight stateless TaskAgent aligns perfectly with the two core use cases I see most builders hit
Right now I lean toward auto page-state for customer-facing SaaS tools where interface context matters most, custom controlled context only for background batch automation workflows
Curious, have you noticed big token cost gaps between the two agent modes in real production usage?
Curious: what repetitive laptop task still wastes time for you even with your current tools?
I’m researching this privately, not pitching anything.
The streaming update is a game changer - watching the agent "think" makes the experience feel less magical and more trustworthy. Your question about DOM vs non-DOM trade-offs is the real strategic decision many teams are grappling with. The field-specific inline AI sounds particularly valuable for complex forms where context matters. Open source + SDK approach puts you in a strong position vs the monolithic chat competitors.