Project Doggo

• Kagi's team takes user feedback unusually seriously. Despite those efforts, a response may take days, a fix years, and a reasonable but niche request may end in Nofix. Each request still takes developer attention to understand, investigate, explain, or reject.
• These costs appear even in simple requests. One user waited five days before learning that Kagi already had a setting to center search results. Another request, for search settings in a sidebar, was considered too niche to justify adding clutter to the shared product. Custom CSS eventually solved it, but only with help from an external coding agent.
• Kagi's team has to make a single product work for many users who want different things. One user may want more information on the page while another wants fewer distractions. Search results or an Assistant response that helps one user may frustrate another.
• When a Kagi product does not work as expected, users must help route their own problem. They may not know whether to rewrite their search query, find an existing feature, make a change just for themselves, or ask Kagi's team to change the shared product. The team must identify the kind of problem before the right work can begin.
• Kagi's team cannot add every requested change to the version everyone uses. A change that shows new information, rearranges results, or helps with one person's recurring task could help that user but make the shared product more complicated for everyone else. Kagi's small team cannot build a separate version for every user, either.
• Even when the right feature already exists, users may never find it. Users remain stuck, while Kagi's team spends time explaining something the team has already built.
• When the shared product needs to change, feedback may describe only a symptom or sketch a desired solution. Members should not have to design the right feature, while developers cannot deeply design every request merely to decide whether it belongs in the shared product. A promising need can stall before it becomes concrete enough to evaluate.
• Kagi can learn only from needs members take the time to report. Friction members abandon, work around, or solve personally may never become product signal, leaving recurring unmet needs invisible.
• Kagi offers general-purpose AI, but not an AI expert on Kagi itself. Members still have to diagnose their own problem, find the right feature, and make the change themselves. There is no gradual path from asking an AI a question to trusting it with a small, reviewable action.
• Kagi asks people to pay for services they can already get free elsewhere. Kagi may offer a better experience, but "free and good enough" remains a powerful alternative. Without a fundamentally new capability, growth depends on repeatedly convincing people that better versions of familiar services are worth paying for.

• Every request gets an immediate response and moves toward resolution. Doggo can surface an existing answer in seconds. Problems requiring diagnosis or a personal change can move toward resolution within minutes, without developer attention.
• Each user gets a Kagi that fits how they search and use Assistant. Reasonable but niche feature requests are fulfilled without changing Kagi for everyone else or adding unwanted clutter.
• Doggo deepens the customization Kagi already offers. It helps users discover existing options, then uses extension points controlled by Kagi when they need something more personal.
• Repeated personal needs become product-discovery evidence. They help Kagi's team decide what to explore next without letting usage or votes set the roadmap.
• Users can start by describing what feels wrong or what they want to do, without diagnosing the cause or designing a feature. Doggo turns that input into concrete options they can react to. They still get a useful result or a clear report to Kagi's team.
• Doggo is a Kagi expert first and an agent second. Members can stop after a Kagi-specific answer or gradually trust Doggo to preview a setting change, apply and undo it, help modify Custom CSS, and eventually create personal software. Stopping at any step is success.
• When the right answer is personal software rather than a setting or shared feature, Doggo can translate the conversation into a persistent tool. It can begin by helping the member author or modify Custom CSS. Proposed Kagi-controlled extension points could later support custom widgets and results-page changes, then tools that combine searches, notes, bookmarks, collections, and other member-approved data.
• Members may keep personal artifacts private or explicitly share them. A widely adopted and maintained personal change can help other members immediately while giving Kagi stronger evidence that the underlying need may deserve attention.
• Features Kagi's team has already built become easier to find and use when they matter. Users benefit sooner, while the team gets more value from work it has already completed.
• When the shared product must change, the user feedback includes what the user expected, what happened, what they tried, and relevant technical context such as screenshots, browser and OS versions, active settings, and search region. It also includes evidence and a candidate design developed with the member, including an example or mockup when useful. Users review what is shared, while Kagi's team receives details it would otherwise have to request. Developers get an informed starting point they can evaluate instead of another round of basic questions or a blank page.
• Developers spend less time triaging feedback, explaining existing features, and collecting missing details. They get more time and attention for evaluating and building shared improvements.
• For Kagi, Doggo creates a reason to subscribe beyond better versions of familiar services that people can already use free elsewhere.
• At its most ambitious, Doggo becomes the platform for personal software, much as Excel lets businesses build tools its designers never anticipated. That can make a Kagi subscription substantially more valuable, accelerate growth by attracting more users willing to pay more, and fund a larger team and better shared product sooner than steady growth alone.

• Doggo begins inside Kagi with two layers: an automated conversational layer that helps users immediately and escalates unresolved issues to Kagi's team, and a deep-personalization layer above Kagi's shared core. The first appears as Kagi's Success Agent, a chat users can open anywhere in Kagi when something is not working the way they need. The conversation can continue when the answer lies in Search, Assistant, settings, or Kagi Feedback.
• Doggo is a Kagi expert first and an agent second. Its answers are grounded in current Kagi features and documentation. With permission, it can also use the current page, query, and relevant settings to understand the member's actual situation instead of giving generic advice.
• The personalization layer starts by deepening the customization Kagi already offers, including settings, Custom CSS, Lenses, and controls for Kagi-provided widgets. Doggo helps users discover those options first. Proposed Kagi-controlled extension points could later support member-authored widgets and results-page transformations.
• Kagi customization is the gateway, not the boundary. The member owns the goal and approval decisions. Doggo carries that goal through the conversation and orchestrates a toolbelt of existing capabilities such as settings and Custom CSS, plus proposed widgets, results-page transformations, persistence, and connectors. Those capabilities may come from Kagi, general platform interfaces, or outside services.
• Personal artifacts remain inspectable, editable, exportable, and usable without the original Doggo conversation whenever possible. They can remain entirely private, with zero usage data collected unless the member explicitly chooses to share usage data.
• Users describe what is wrong or what they want to do in their own words. Doggo uses the current page and search query, plus any relevant settings the user allows it to see, instead of making users repeat that context. It then asks the questions needed to understand the problem.
• Doggo takes the first design pass. It separates the problem, desired outcome, constraints, and any proposed solution; offers alternatives; and creates an example, mockup, or personal prototype when useful. The member reacts to something concrete and controls what moves forward. Kagi's developers retain final authority over shared-product design.
• Doggo acts on every request. With the user's approval, it chooses the simplest useful action:
  1. Improve the current search query, explain why the results went wrong, or make a change that lasts for this search only.
  2. Find, explain, and apply a setting or feature already available in Kagi.
  3. Make a change just for that user. With today's capabilities, Doggo can help author or modify Custom CSS. Proposed Kagi APIs could later support custom widgets and SERP transformations, then persistent personal tools built from approved capabilities.
  4. If Doggo cannot resolve the request and the shared product must change, find an existing report or prepare a new one with the member's explanation, relevant evidence, approved technical details, and a candidate design developed from the member's input. The member reviews and approves what is shared.
• Across repeated interactions, Doggo also offers a trust ladder: answer without acting, preview a setting, apply and undo it, explain or modify Custom CSS, then later help modify a widget template or create a new personal artifact. Each step asks for only the authority it needs. Stopping at any step is success.
• Doggo handles the conversation, proposes what to do, and may author a personal addition. Kagi's team defines the APIs, permissions, information, and page changes Doggo may use. After the user approves, Kagi's software applies the change through those allowed controls.
• Before changing anything, Doggo shows the user what will happen and asks for approval. The user can try a change temporarily, save it, edit it, or undo it.
• A change needed by only one user can stay in that user's personal Kagi. When the version everyone uses must change, Kagi's team receives a clear, actionable report, and developers decide what to build.
• A later Kagi mod marketplace could let members explicitly publish personal artifacts. Kagi defines which aggregate metrics can be collected and their privacy safeguards; each member chooses whether to contribute any data. Zero collection remains possible.
• Marketplace signals remain distinct: installs, votes, sustained use, remixes, and maintenance. A widely used and maintained mod can reveal durable demand, but no one metric sets the roadmap. Kagi may keep it as a mod, strengthen the platform supporting it, or bring the underlying capability into the shared product.

Do users actually have these problems?

Real discussions on Kagi Feedback contain examples of confusing search results, existing features users could not find, niche requests marked Nofix to prevent clutter, and problems in the shared product that developers needed to fix. In one case, a user waited five days before learning that Kagi already had a setting to center search results. In another, a sidebar request was considered too niche for the shared product and eventually required Custom CSS plus an external coding agent.

Can a Kagi expert help more than a general-purpose assistant?

Replay real member questions and compare Doggo with a general-purpose assistant. Check whether Doggo identifies current Kagi features, uses relevant product context, avoids outdated or invented instructions, and recommends the simplest useful next step.

Can current AI create useful personal software?

Tools such as Lovable already let people describe a small piece of software and use the generated result, even when it is not polished. Google's Canvas in AI Mode is a closer precedent than AI Mode alone: it creates working interactive tools in a persistent side panel inside Search. Opal similarly creates reusable mini-apps from natural language.

Google's public descriptions do not expose member-authored transformations of the underlying SERP. AI Mode can generate a query-specific tool inside a response, Canvas places a project beside Search, and Opal produces a separate mini-app. Doggo's proposed distinction is a personal layer that can change Kagi itself. With suitable APIs, a member could create something like Kagi Translate or make translation part of how future result pages behave. This is a current product distinction, not a technical moat Google cannot cross.

Kagi's existing Custom CSS offers a constrained first test: Doggo can explain, generate, preview, and repair an inspectable personal artifact without requiring custom widget support. The working Custom CSS sidebar is a small example of this pattern: coding-agent help made a previously impractical personal change possible. Proposed Kagi APIs could later support custom widgets and SERP transformations. A personal change can be useful without meeting the polish required of a core feature provided to every user.

What keeps Doggo from breaking a user's Kagi?

Doggo shows each proposed change before applying it. The user can test the change temporarily, approve it, refine it, disable it, or undo it. If Doggo cannot figure out how to help, it helps the user bring the problem to Kagi's team.

Won't member-created personal software create more support work for Kagi?

Personal artifacts and shared changes do not automatically become fully supported Kagi features. Kagi's team provides best-effort support and decides which changes to review, promote, or support fully. Users who need dedicated help could also pay for assistance from a Kagi expert.

How can Kagi's team test whether Doggo works?

First, replay past feedback conversations to test whether Doggo asks useful questions, identifies what kind of problem the user has, and outperforms a general-purpose assistant at recommending a sensible next step. Then test whether a live prototype can resolve real problems involving searches, settings, existing features, and Custom CSS. If those work, test whether Doggo can author one kind of custom widget or SERP transformation through a proposed, constrained Kagi API. Finally, test whether unresolved requests become feedback developers can act on. Each stage tests another part of Doggo before the team invests in the next. Together, these stages test the Kagi gateway before a later prototype attempts one persistent personal tool beyond Kagi customization.

What results would justify continuing?

For each case, measure how long the user waits for a useful result and whether Doggo resolves the problem without developer attention, finds an existing feature, makes a useful personal change, or sends the problem to Kagi's team. For escalated cases, ask developers whether the report is complete, actionable, and includes a useful candidate design, example, or mockup developed from the member's input that they can evaluate without another round of basic questions. Separately measure the time Kagi spends reviewing, repairing, supporting, and maintaining Doggo's work. Rough personal changes can be useful, but broken ones cannot. Also measure whether patterns drawn from member-approved data across conversations and personal changes reveal recurring needs worth exploring without assuming recurrence alone makes them shared-product priorities. Doggo is worth continuing only if it saves Kagi's team more time than it adds.

Later validation can test the larger platform hypothesis: whether members use Doggo to create persistent tools beyond Kagi customization, continue using and refining them, explicitly share them with other members, and find the capability valuable enough to increase willingness to pay, subscription value, or growth. It can also test whether installs, sustained use, remixes, and maintenance provide useful product-discovery evidence under member-chosen privacy settings.

• Ask Kagi's team to approve or participate in a narrow Doggo validation.
• Use a fixed, representative set of real feedback cases.
• Begin with read-only Kagi questions and compare Doggo with a general-purpose assistant before granting it any ability to act.
• Define success for both sides: useful results delivered to users and developer attention saved or made more effective.
• Keep the requested time, access, and commitment proportional to the proposal's current status.
• Make clear that the first validation tests Kagi as Doggo's gateway, not the entire personal-software platform.
• Name the decision the validation would enable. If the Kagi-native test succeeds, decide whether to test one persistent personal tool beyond Kagi customization.