Don't just slap on a chatbot: building AI that works before you ask

Adding a chatbot gives users somewhere to ask for help. But does it help them with the work already in front of them? They still have to recognize a problem, formulate a request, and move into a conversation. That is the opening product-design problem: a place to ask is not the same as assistance at the moment of need.

Arthur Objartel, a product designer at Evil Martians focused on developer tools and AI, explored a different approach in Tegon, an AI issue tracker. Rather than make users initiate every interaction, the interface could notice when their current work presented an opportunity to help.

Arthur describes that approach as successful, though he supplies no quantitative evaluation. His historical reference is Clippy, the Office Assistant: the idea of anticipating a user’s needs was already decades old. In his assessment, Clippy suffered from poor execution and timing; modern AI creates an opportunity to revisit the interaction. The design question becomes: what could the product do without waiting for an explicit request?

Arthur introduces suggestion mode by describing someone reporting a legal issue: the AI notices the report and begins asking relevant follow-up questions without a separate request for assistance. The useful distinction is specificity. A generic invitation to ask for help leaves the next move entirely to the user; a contextual question identifies what the report still needs.

The visible example shows a logout report: users are logged out every two hours when switching dashboard tabs. Beneath the report, an inline suggestion asks about timing patterns and affected user groups. Those questions give the writer concrete information to add, in the same place they are already writing.

The mechanism is continuous attention to the draft. Tegon tracks what the user writes in real time, interprets the context, and introduces a question when it can move the issue forward. These interactions need no separate chat window; that does not mean every AI feature in Tegon uses the same interface.

The next example starts with an issue complex enough to split into sub-issues. Instead of waiting for the writer to request a decomposition, Tegon identifies the component tasks and suggests a more useful organization. Arthur attributes this to access to previous data and knowledge of how similar work was organized. The intended basis for the split is the team’s domain and history, rather than an arbitrary division of the text.

This is action mode: assistance moves beyond asking for missing information to proposing a change in how the work is structured. The demonstration then extends to timelines and resources. Arthur compares the experience to a project manager who is always paying attention, with the relevant questions and issue-management help appearing inside the existing workflow.

Question plus action mode combines clarification with changes to the work. The three modes differ in what they contribute:

The interface keeps those contributions close to the issue itself, without requiring extra windows or a separate conversation.

Proactive assistance raises an immediate question: who remains in charge? Arthur’s answer is that users can revert changes with one click. Initiative belongs to the assistant; authority stays with the user. Reversibility is part of the interaction, not something users must recover through another conversation.

The benefit is less work spent explaining what help is needed. The draft and its surrounding context already supply much of that explanation, allowing assistance to stay within the flow of creating and managing issues. Arthur proposes this as a pattern for professional tools beyond issue tracking.

The first two design rules establish the boundary:

• Supplement agency. Help users make and carry out decisions rather than replacing their decision-making role.
• Recommend, don’t force. Present useful options without making acceptance compulsory.

The third rule is to participate in the natural workflow without stopping it. A code editor, for example, could watch for common pitfalls and suggest improvements as a developer works. Arthur highlights developers learning a language or framework: they may benefit from guidance before they know which question to ask.

The same principle suggests other product possibilities:

• Design tools. Suggest accessibility improvements during creation, so the designer can address them while making the relevant choices rather than only checking afterward.
• Communication tools. Prepare relevant context before a meeting, or retrieve a document when someone mentions it on a call.

These are proposed applications. The communication-tool mockup makes the placement concrete: a sidebar containing notes and mentioned documents sits beside the call grid, keeping supporting material within the meeting interface.

The useful role is an advisor that leaves the user in control. To find where that advisor belongs, start with the work rather than with a chat surface:

1. Find the interruption. Identify places where users stop what they are doing to ask for help.
2. Look for repetition. Examine recurring behavior, usual assistance needs, and questions users ask repeatedly. These are clues for automation.
3. Inspect the context. Determine where users get stuck and what information is available at that moment. That is where timely assistance can contribute most.

AI interface design is still taking shape, so there is no fully formed playbook to copy. Arthur’s closing invitation is to experiment with unexpected interface solutions in real products. The opportunity is to design around a specific moment of friction: a question beneath an incomplete report, a proposed split beside a complex issue, or relevant material beside an ongoing call. Copying a chat interface alone does not resolve those design decisions.