dotdotduck
Web agent that operates the page, not a sidebar chatbot
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'm working on dotdotduck, an AI interaction SDK for web apps.
The reason we started building it is pretty simple:
We felt that most AI features in software still feel disconnected from the actual product experience.
A chatbot can answer questions, but it usually sits beside the app. It does not always know what the user is looking at, what they are trying to do, or where they are stuck.
So we are testing a different approach.
What if AI became part of the interface itself?
With dotdotduck, users can interact with a web app through a Command Palette, Inline AI, Dwell interactions, and a Web Agent that can operate the page.
At the same time, these interactions create intent signals for the product team.
That part is important to us.
Clicks tell you what happened.
Intent signals may help explain what the user wanted to happen.
We are still early, and I do not want to pretend we have everything figured out.
We made the early version open source:
https://github.com/PerhapxinLab/dotdotduck
You can also try the live demo:
https://dddk.perhapxin.com/
And if you're curious about who we are and why we're building products like this, you can learn more about Perhaps Technology here:
https://perhapxin.com/
I would really appreciate feedback from other builders:
Is this a real problem you have seen in your own product?
Would you use this as an SDK?
What part sounds useful, and what part sounds unnecessary?
-
2
The framing of "clicks tell you what happened, intent signals tell you what the user wanted" is something I've felt as a builder but never articulated that cleanly.
As someone early in building a product, this is exactly the problem I'm dreading — the moment when you have analytics data but still can't confidently answer why users behave a certain way. Traditional tools seem to give you evidence without explanation.
What you're describing with dotdotduck is essentially making the product itself a continuous research instrument. That's a meaningful shift — not just AI as a feature, but AI as an observation layer baked into the experience from day one.
The approval-before-action model for the Web Agent also seems like the right call at this stage. Trust has to be earned incrementally, and giving users a veto keeps them in the loop without making the AI feel useless.
One thing I'm curious about: how do you handle cases where users interact very differently depending on whether they know they're being "observed"? Even passive intent signals can change behavior once users become aware of them. Has that come up in your testing yet?
-
0
That's a really interesting question, and honestly, we don't have a definitive answer yet. dotdotduck is our first product, so we're still learning how users feel about passive intent signals in real world usage.
I think there are two different questions here.
The first is whether users have the right to know they're being observed. User behavior analytics existed long before AI. Recently, the discussion around privacy has become more visible because of incidents like Meta's tracking controversy. At the same time, most people are perfectly comfortable with YouTube recommending videos based on their behavior. So I don't think the real issue is being observed. It's whether users know what's being collected, why it's being collected, and whether they receive value in return.
The second is whether users actually benefit from it. That's what we're trying to achieve with dotdotduck. We want intent signals to make the AI a better assistant, not a better observer. Today we can't personalize every workflow for every individual, but if those signals make the product genuinely easier to use, then we believe users will see the value.
We're still validating this assumption, but our belief is that trust comes from transparency and user benefit, not from hiding the fact that data is being collected.
-
2
The two-question breakdown is a useful lens. Most of the privacy debate collapses the two together and loses clarity.
One thing I'd push on: transparency alone may not be enough if the value return is delayed or invisible. Users tolerate YouTube's tracking because the feedback loop closes within seconds. If intent signals improve AI behavior over weeks, the connection between "I was observed" and "this got better" might never feel real to the user — even if it is.
We've been wrestling with a similar gap on our end — how to make behavioral feedback feel immediate and legible, not just quietly useful in the background. No clean answer yet, but will reach there soon.
-
-
-
1
"clicks tell you what happened, intent signals tell you what the user wanted to happen" — that's a genuinely sharp distinction and probably the most interesting part of what you're building.
the ambient AI layer that knows where the user is stuck without being asked is the right direction. most AI features feel bolted on because they are — separate chat window, separate context, separate mental model.
curious how you're handling the signal noise problem. intent inference at the UI level could easily generate too much data to act on. how do you surface what actually matters to the product team?
-
1
That's a good question.
UI level intent inference naturally generates a lot of data. Some of it becomes valuable insights, while some of it is just noise. The real challenge isn't collecting signals, it's figuring out which ones actually matter.
The Dashboard in our demo shows the signals we currently believe are useful for dotdotduck. They're our starting point, and we'll validate them through real usage.
From there, we think each product should be able to customize the Dashboard based on its own goals. An ecommerce product, a documentation site, and a developer tool won't care about exactly the same signals.
Our focus for Version 1 is collecting and validating those signals. In Version 2, we'll introduce data analysis features and integrate the signals that prove useful across most products into a more universal Dashboard.
-
-
1
The “intent signals” part is the most interesting to me. A chatbot beside the product is easy to ignore, but AI that understands what the user is trying to do inside the interface could become both UX assistance and product research at the same time.
The risk is that it becomes another layer of interaction users have to learn. I’d want the SDK to feel almost invisible until the exact moment the user gets stuck.
-
1
The "clicks tell you what happened, intent signals tell you what the user wanted" distinction is the most interesting part here. Most analytics tools stop at the first one.
The Command Palette + Web Agent combination makes sense, those two cover opposite ends: power users who know what they want and users who are stuck and need guidance.
I've been thinking about similar problems from a different angle, building a workspace where AI generates live tools inside documents. The challenge of making AI feel native rather than bolted on is real. Good luck with this.
-
1
The "chatbot sitting beside the app" problem is real and I've felt it as a user more than as a builder. You're context-switching constantly — app on one side, AI on the other — and the AI has no idea what you're actually looking at.
The intent signals angle is what stands out to me most here. Click data tells you what happened but not why the user hesitated, backtracked, or gave up. If dotdotduck can surface that gap between intended action and actual action, that's genuinely useful for product teams beyond just the AI interaction layer.
The Command Palette approach makes sense as an entry point — it's already a pattern developers and power users are comfortable with, so the learning curve is lower.
My honest question: how do you handle cases where the AI misreads intent and takes an action the user didn't want? Especially with the Web Agent operating the page — recovery from wrong actions seems like it could break trust fast if not handled carefully.
Going to look at the GitHub repo. Curious how the SDK integrates with existing component libraries.
-
1
Thanks! That's a great question, and it's something we've spent a lot of time thinking about.
Our approach is to avoid wrong actions before they happen. Before the Web Agent executes anything, it asks for the user's approval. We don't think fully autonomous AI is ready today. AI might handle 95% of the work, but we believe the final 5% should stay with the user.
Users can approve or reject the Web Agent's suggestion, or interrupt it at any time by double clicking on an empty area of the page. Besides preventing unwanted actions, this also helps users feel they're still in control.
We're not claiming this is the perfect answer. It's simply the approach we believe provides a better user experience, and it still needs market validation.
There's another benefit too. Every rejected suggestion becomes an intent signal. Those rejections tell us where the AI misunderstood the user, giving us valuable feedback to improve future interactions without creating a frustrating experience.
-
-
1
This is a brilliant SDK, Lin_Kuei_Kuei. You nailed the exact frustration I have with current AI features: checkboxes and chatbots sitting awkwardly beside the product layout. Clicks show action, but Intent Signals show the soul.
I’m currently building Echo, an AI-mediated social sandbox using backend AI for deep intent analysis to map connections under masks. I read your post and immediately thought: 'Damn, I need this for Echo.'
But here is my biggest headache: We are building on React Native (RN) for mobile, and your SDK seems strictly scoped for web apps right now. Mobile app builders desperately need this exact type of inline AI and intent-signal orchestration because screen real estate on phones is way more punishing than web browsers. A chatbot drawer kills a mobile UI instantly.
Is an RN or native mobile wrapper anywhere on your roadmap? If you ever bring dotdotduck to the mobile dev ecosystem, I’d gladly be your first closed-beta tester to stress-test it in our text sandbox.
Starred the repo. Incredible work.
-
1
Thanks so much! Really appreciate the kind words. Echo sounds like a fascinating use case.
We don't have an official React Native or native mobile wrapper on our roadmap at the moment. dotdotduck is currently built for the web, and we didn't build it around any specific framework, so it works with any web framework.
Feel free to make full use of the open source repo and experiment with it. If you run into any issues or have ideas, just open an issue on GitHub. We read every one of them. We'd love to hear how it goes if you decide to explore it with your own stack.
-
-
1
This resonates deeply with what I've been building. I'm working on useorca, a platform for service SMEs (construction, repairs), and the exact problem you're describing is our core challenge: most tools force their workflow onto users instead of embedding themselves into how people actually work.
Right now, our users are scattered across email, WhatsApp, spreadsheets, and invoicing tools. They don't need another app sitting beside their workflow. They need the platform to live where they already are.
What's clever about dotdotduck is the intent signal piece. We're thinking about this too: clicks and form submissions tell you what happened, but understanding why a user abandoned a budget or why they switched back to email tells you everything about design friction.
Two questions:1- For embedded SDKs like this, how do you handle the training data? If dotdotduck learns from intent signals across multiple products, does each product get its own model, or is there a way to share learnings without exposing user data?
2- For service businesses specifically (like our users), would this work for something like "understand why a client keeps requesting changes outside the original scope"? Right now we're tracking that manually with change logs in Notion.
I'd definitely test this. The demo link is helpful — is there a roadmap for Notion integrations?-
1
Those are great questions, and they're actually very close to how we're thinking about intent signals.
For us, the SDK isn't just collecting events. We try to design the interaction itself as the data format. When users approve or reject an action, choose between options, or interact with the web agent (or voice input), those interactions naturally become high quality signals for future SFT/RL style training. The goal is to generate useful data through the product experience itself, rather than relying on heavy post processing later.
That said, we're not really focused on training models today. Right now, our priority is collecting the right data. We believe small language models will continue to improve, and when that happens, companies that already have high quality intent data will have a huge advantage. You don't want to start thinking about your data only after the models are ready.
Whether it's one model per product or a shared model really depends on the use case. If you're building a small model for a single workflow, training on one product may be enough. If the goal is to reduce bias or build a model with broader capabilities, combining multiple products could make sense. We see intent signals as the interface for future training, rather than committing to one training strategy.
For your second question, the answer is partially yes.
Today, the SDK already exposes data hooks, so you can record things like user roadmaps, action trees, or any custom interaction with just a few lines of code. That means you could already collect the signals needed to study cases like repeated scope changes.
What's missing today is the analysis layer. Version 1 is mainly focused on making the web agent reliable and smooth. In Version 2, we're planning to introduce a standardized data platform that can process those interaction signals into analytics, recommendations, user preference labels, and eventually training datasets.
We hadn't considered the Notion change log use case before, but it's a good example. We'll keep it in mind as we shape the data platform in Version 2.
-
-
1
If AI becomes part of the interface itself, the whole way we interact with software changes.
Instead of opening apps and clicking through fixed menus, the interface becomes more dynamic — you just express intent, and the system assembles the workflow for you in real time.
That shifts interfaces from “tools you operate” to “systems that interpret you.” Buttons, dashboards, and even navigation start to matter less, because AI is handling translation between intent and execution.
But it also raises new challenges: transparency, control, and predictability. If the interface is generated on the fly, users need ways to see what’s happening, approve actions, and understand why certain paths were chosen.
So the real shift isn’t just “AI inside apps,” but apps becoming adaptive layers over AI — with design focusing more on trust and control than static UI.
-
1
I agree that trust and control become much more important once AI starts acting inside an interface.
That's exactly why we chose a different direction with dddk.
Instead of replacing the existing UI, we keep it. Familiar interfaces already provide transparency because users can see exactly where the agent is operating.
Every action requires explicit approval, so users stay in control instead of handing everything over to AI.
We also believe web agents should behave more like personal assistants than autonomous operators. Their job is to guide and execute, not silently make decisions.
In our view, AI shouldn't replace buttons or dashboards. It should make them easier to use while keeping interactions understandable and predictable.
Trust doesn't come from replacing interfaces with AI.
It comes from letting AI work inside interfaces people already understand.
-
-
1
This is a massive shift. In search marketing, keyword data is valuable because it represents unprompted customer intent. Bringing that "intent capture" directly inside the application interface bridges the gap between acquisition intent and product behavior. Feeding those in-app intent signals back into your landing pages and SEO strategy is a brilliant way to align marketing with product.
-
1
That's a really interesting perspective. I'm glad you mentioned the marketing side of it.
Right now, I'm using intent capture in a much simpler way. It's mostly helping us understand what users are actually doing, answer questions we already have, and spot things we didn't expect.
For example, every new user starts with the /introduce flow, but they can skip it. We thought most people would go through it because it unlocks the full demo and creates a much richer history in the dashboard. In reality, a lot of people skip it. That immediately made us ask whether we should require everyone to finish the introduction before exploring the rest of the demo.
My understanding is that marketing is a different challenge. To really learn from user intent, you probably need a working business model, a lot more data, and enough time to see how behavior changes across different audiences, seasons, campaigns, and so on.
That's one of the reasons we built the dashboard. We felt there might be a need for this kind of visibility, so it's really encouraging to hear someone from a marketing background see value in the idea.
I'd love to hear your thoughts. What kinds of data do you think would actually be useful for marketing?
-
-
1
One thing I'd be careful with:
The interesting question may not be whether users engage with AI inside the interface.
It may be what conclusion deserves confidence if they do.
Those sound similar, but they can lead to very different decisions about positioning, product direction, and what gets built next.
I wouldn't make that call casually this early.
-
1
I completely agree.
One of the risks here is mistaking usage for validation. At the moment we're only observing behavior, not drawing strong conclusions from it.
The real question is whether those interactions correlate with better outcomes, and that requires significantly more data, baselines, and controlled testing than we currently have.
For now, we're treating these signals as inputs for future research rather than proof of product direction.
-
1
That's exactly the part I'd be careful with.
A lot of products collect interesting usage data early on.
The hard part is deciding what that data actually means before it starts influencing bigger product decisions.
I've seen founders end up with plenty of evidence and still walk away with the wrong conclusion.
I wouldn't try to unpack that properly in a thread.
If you're curious, drop your email and I'll send over the tighter version.
-
1
I'd love to read it.
One thing I've been thinking about is that collecting signals feels relatively straightforward, but building a framework for interpreting those signals correctly is much harder.
You can send it to peipeishu93 [at] gmail [dot] com
Thanks for pushing on the nuance here, and I appreciate you taking the time to share your perspective.-
1
Sent you a note by email.
I think the interpretation decision matters more than the usage signals themselves right now.
-
-
-
-
-
1
Nice clear design but not sure what exactly it promising doing, the duck logo also I feel that doesn't match the design, just honest feedback
-
1
Thanks, this is fair feedback.
The product promise is: dotdotduck helps web apps bring AI into the product interface itself, while turning user interactions into structured intent signals.
Your comment also made me realize something. Although every new user starts with the /introduce flow, many people don't complete it, so they miss a big part of what the demo is trying to show. The introduction isn't just a tutorial—it builds the interaction history that powers the dashboard, making it much easier to see how user actions, questions, and decisions become structured intent signals.
On desktop, you can try Ctrl+K, Ask AI, complete /introduce, select text for Inline AI, or hold Space for voice input. On mobile, I'd recommend completing the /introduce flow first.
The project is open source on GitHub, and the demo is just one implementation. Builders can customize the UI, actions, prompts, and workflows to fit their own products.
-
7 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.