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.
A conversation needs something to act on
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.
The work rail and the conversation share one screen. Fictional demo data.
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 chat isn't a replacement for the underlying work. It's a way to move through it.
Put the task itself in the conversation
The important step is to render the actual task view, not just have the model describe it.
The request, task state and next actions are together. Fictional demo data.
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.
A deterministic app inside an assistant
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.
Approval should be a visible part of the work
A conversational workflow shouldn't end with "done" and leave you wondering what actually happened.
The prepared reply is visible before sending. The figures and people are fictional.
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.
The tradeoff: structure can help, or get in the way
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.
What I built with Claude Code
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?
Top comments (1)
I saw this on reddit, cool idea