What if the app lived inside the conversation?

Most discussions about AI interfaces start with the model: what it can answer, which tools it can call, how much work it can do. I'm interested in a different question: where does the actual app go? Does 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? That'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. All screenshots below show the real app using fictional demo data. An empty chat box gives you freedom, but it also gives you a job: decide what to ask next. For a work assistant, there is usually already something to deal with. A request arrived. A task is waiting. A reply needs review. The first screen should make that work visible, rather than asking you to reconstruct it in a prompt. In this example, requests from several sources arrive on one timeline. The assistant can bring an item into the conversation with its context intact. The important step is to render the actual task view, not just have the model describe it. Here, 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. You can click a choice, or use chat to ask about the task. That's the distinction I'm aiming for: a conversation around a real application object, rather than a conversation pretending to be the application. The user still has an open-ended interface, but doesn't have to invent a prompt for every ordinary step. By "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. The distinction is: Application state: what task is open, where its work stands, which draft is being reviewed. Explicit actions: the controls for moving on, drafting, starting work and approving a result. AI assistance: interpreting a request, answering questions and preparing text or work. The first two give the conversation structure. The third makes it useful when the request doesn't fit a button. This 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. A conversational workflow shouldn't end with "done" and leave you wondering what actually happened. In 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. That 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. I don't think every app should become a transcript. Comparing 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. The useful question is which moment benefits from conversation. Walking through one task and its next choices is different from surveying an entire project. The 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. I 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. The 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. Would you want to walk through work this way? Which parts would you keep in a conventional dashboard?