{"slug": "what-if-the-app-lived-inside-the-conversation", "title": "What if the app lived inside the conversation?", "summary": "A developer built Taskuary, an open-source, local-first work assistant that embeds a conversational interface directly into a real application object rather than treating chat as a separate panel. The app, built with Python/FastAPI, React and SQLite and running locally, renders task cards with explicit controls — such as approve, reject or regenerate a drafted reply — so users can inspect proposed actions before they leave the app. The developer argues conversation should be the way through structured work, not a replacement for the underlying controls.", "body_md": "Most discussions about AI interfaces start with the model: what it can answer, which tools it can call, how much work it can do.\n\nI'm interested in a different question: where does the actual app go?\n\nDoes it remain a dashboard with a chat panel attached? Or can the conversation become the place where you use the app, with real controls and clear choices inside it?\n\nThat's the direction I'm exploring in Taskuary, a open source local-first work assistant. The example here is work arriving as email, chats, issues and reports. The broader question is how a conversational interface should handle structured work.\n\nAll screenshots below show the real app using fictional demo data.\n\nAn empty chat box gives you freedom, but it also gives you a job: decide what to ask next.\n\nFor a work assistant, there is usually already something to deal with. A request arrived. A task is waiting. A reply needs review.\n\nThe first screen should make that work visible, rather than asking you to reconstruct it in a prompt.\n\nThe work rail and the conversation share one screen. Fictional demo data.\n\nIn this example, requests from several sources arrive on one timeline. The assistant can bring an item into the conversation with its context intact.\n\nThe chat isn't a replacement for the underlying work. It's a way to move through it.\n\nThe important step is to render the actual task view, not just have the model describe it.\n\nThe request, task state and next actions are together. Fictional demo data.\n\nHere, the request is to prepare vendor spend numbers. The card shows what needs doing, the agent work and the close-out. Under it are explicit choices: *Next, **Write reply, **Start an agent*.\n\nYou can click a choice, or use chat to ask about the task.\n\nThat's the distinction I'm aiming for: a conversation around a real application object, rather than a conversation pretending to be the application.\n\nThe user still has an open-ended interface, but doesn't have to invent a prompt for every ordinary step.\n\nBy \"deterministic\" here, I mean the ordinary application layer: task state, named actions and visible controls. I don't mean that the language model becomes deterministic, or that putting a button on something proves it is safe.\n\nThe distinction is:\n\nThe first two give the conversation structure. The third makes it useful when the request doesn't fit a button.\n\nThis is an interface-design model, not a claim that every internal operation is formally verified. Free-text requests still need interpretation. Agents can still get things wrong.\n\nA conversational workflow shouldn't end with \"done\" and leave you wondering what actually happened.\n\nThe prepared reply is visible before sending. The figures and people are fictional.\n\nIn the example, the reply is presented as a draft with controls to approve, reject or regenerate it. The text and the action are both visible.\n\nThat is a different interaction from asking the assistant to send something and relying on its explanation afterward. The user can inspect the proposed result before it leaves the app.\n\nI don't think every app should become a transcript.\n\nComparing many rows, browsing a large dataset or keeping several tasks in view may still work better in a table or board. A conversation can become another long feed if everything gets pushed into it.\n\nThe useful question is which moment benefits from conversation. Walking through one task and its next choices is different from surveying an entire project.\n\nThe design I'm exploring keeps structured views, but brings the relevant one into the conversation when you're working on it. Chat is the way through the work, not an excuse to remove the controls.\n\nI used all sorts of AI for the whole app, including the backend, frontend and task-card interface. The stack is Python/FastAPI, React and SQLite, running locally.\n\nThe question I'm trying to answer is whether conversation can be the main interface to an app without losing the clarity of a normal application.\n\nWould you want to walk through work this way? Which parts would you keep in a conventional dashboard?", "url": "https://wpnews.pro/news/what-if-the-app-lived-inside-the-conversation", "canonical_source": "https://dev.to/moneky_do_2535fc4480c0cce/what-if-the-app-lived-inside-the-conversation-bl5", "published_at": "2026-10-01 12:01:14+00:00", "updated_at": "2026-10-01 12:14:35.201345+00:00", "lang": "en", "topics": ["ai-agents", "ai-products", "developer-tools", "ai-tools"], "entities": ["Taskuary", "Python", "FastAPI", "React", "SQLite"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/what-if-the-app-lived-inside-the-conversation", "markdown": "https://wpnews.pro/news/what-if-the-app-lived-inside-the-conversation.md", "text": "https://wpnews.pro/news/what-if-the-app-lived-inside-the-conversation.txt", "jsonld": "https://wpnews.pro/news/what-if-the-app-lived-inside-the-conversation.jsonld"}}