A tab feels like a natural way to organize AI work. Open Research, Design, and Implementation; move among them as you would in a browser. But a subtle mistake follows: if every tab becomes its own conversation, the interface has traded one stack of chat threads for another. The harder design question is how to make one workspace feel coherent when the work changes underneath it.

The first prototype solves the wrong half

Chat applications usually provide a list of conversations. A list is good at revisiting a finished exchange and weak at showing a live collection of tasks, data and artifacts. A tab bar improves orientation: the thing you are working on has a visible place.

That improvement is real. It also tempts the product to identify each tab with a separate conversation or agent session. Then the user must remember which tab knows the supplier, where the report request began, and why the approval appeared in a different room. We built a better filing cabinet, not necessarily a better work environment.

The distinction matters as soon as a person says, 'Compare this with the report I was looking at earlier.' If the product can answer only when both objects belong to the same chat, the organizational model is doing too much work.

Four identities instead of one

Think of four concepts as separate: Workspace, Conversation, Work Surface, and Execution. The Workspace is the environment and its ownership boundary. A global Conversation is a channel for communicating intent and receiving important updates. A Work Surface is a persistent view of a document, table, entity, or artifact. An Execution is an independently addressable unit of work that might calculate, delegate, wait, or ask for approval.

These things can be related without being identical. Closing a table tab does not cancel a supplier review. Starting a new investigation does not require inventing a new conversation. A result can update a surface even when the person has moved to a different part of the workspace.

This is a target architecture, not a claim that the current Artemis application already behaves exactly like this. The design is useful because the distinctions are explicit.

The visible tab is a clue, not the command

The selected surface can tell the system what the user is probably referring to. A highlighted invoice row, a spreadsheet selection, or an open document are valuable focus signals. They are not unconditional instructions.

Imagine that a customer table is focused and the user writes, 'Go back to that invoice and check the payment status.' The explicit reference should win over the current tab, provided the target can be resolved. If there are two plausible invoices, the correct response is to clarify rather than silently bind the request to whichever record happens to be visible.

Nor should focus grant authority. Opening a restricted financial view cannot create permission to edit the underlying records. Context and authorization need different owners.

Context is assembled, not inherited wholesale

A single conversation does not mean sending its entire history to every model call. The relevant context of a supplier investigation is different from the context of a design critique. History may help resolve references, but the working context should be assembled for the current operation from permitted, current sources and specific task state.

This is a harder problem than preserving a large chat transcript. The system must discover related objects, carry forward important decisions, distinguish durable memory from temporary state, and resist dragging irrelevant or sensitive information between activities.

It is worth the complexity because context becomes an accountable projection of work, not a side effect of which chat window happened to be open.

Concurrency without theatre

Multiple active tasks need visibility, not a dozen animation loops. A task might be running; another might be waiting for a document; a third might need approval. Those states should be accessible from a global control surface without stealing focus on every status change.

Tabs are presentation. Execution state is operational. A system may serialize compute while several work items remain independently addressable. Showing ten tabs is not evidence of ten truly parallel agents.

An honest interface also avoids progress percentages it cannot measure. 'Waiting for approval' is more useful than '92%' when the work is blocked by an external decision.

A better test than the tab bar

Try this sequence: open a supplier record, ask for a report, switch to a separate document, request a revision of the original report, and then respond to an approval from a third task. Ask what needs to stay true for this to feel like one continuous workspace.

The answer is not 'put a chat inside every tab.' It is stable references, dynamic context, independent execution, predictable attention, and user-facing software surfaces that preserve their state.

A tab bar is useful chrome. The real product architecture begins when the work can survive it.