Building AI into real work instead of adding another chatbot

Most AI products begin with an empty box. You open the assistant, type a question, explain what you are working on, and if the answer is useful you copy it somewhere else, update the Task yourself or create the document. The AI may have helped with the thinking; the work still lives outside the conversation.

There is nothing wrong with that model. A general chatbot is excellent when the problem is broad: exploring an idea, drafting text or understanding a subject. The weakness appears when the question concerns work that already exists inside a business system. If the software knows which Task you are looking at, which Project it belongs to and which workspace you are in, asking you to describe all of that again is a strange place to start. That is the idea behind AI in Arkonkt: bring AI to the work while keeping the workspace’s boundaries around it.

Knowing language is not the same as knowing the work

Imagine asking an ordinary chatbot what to do about the overdue Task on the Anderson Project. Without context, the model has no idea which Project you mean, which Task is overdue, who owns it or whether you are permitted to see it. You can paste the Task into the chat, but now there are two versions of the information, and if the Task changes five minutes later the conversation quietly becomes stale.

Inside Arkonkt, the application can establish which authorised record the user is talking about before the model reasons about it. Workspace AI supports selecting specific Tasks, ToDos, Epics or Notes as context, so the answer can point back to the actual record rather than to something that merely sounds similar. That division of responsibility matters. Ordinary software is good at exact identity, permissions and structured state; language models are good at interpreting messy human requests. We prefer to let each do the part it is naturally reliable at instead of asking the model to rediscover facts the application already knows.

More context can make AI better and less safe

It is tempting to assume the best assistant is the one that can see everything. In a business workspace, that is a poor default. One Note may be private and another shared with a team. A Hiring workflow can contain applicant information that should never become general workspace context. Two people using the same AI feature may legitimately receive different answers because they are allowed to see different things.

The useful question is therefore not how much data can be given to the model, but what minimum authorised context is needed to answer the question well. A tightly controlled system may occasionally need to ask a follow-up question where an unrestricted model would simply make an assumption. We think that is a good trade in business software. A short clarification is usually better than a confident answer based on information the user should not have seen.

Arkonkt also gives users a choice between local and cloud AI for different kinds of work. Local processing can keep more sensitive content on the device and avoid depending on a provider connection, while cloud models are often stronger for difficult reasoning and do not depend on the hardware under the desk. Neither is automatically better. The point is that where the model runs and what it is allowed to see should be deliberate decisions, not details hidden behind an AI button.

A suggestion is not the same as a change

Work rarely ends with an answer. Reviewing a Note, you may want one of the points to become a Task. After a meeting, the useful follow-up should not depend on somebody remembering to copy it somewhere later. This is where AI inside a workspace becomes more interesting than a standalone chatbot, because the model can move from explanation toward a structured proposal.

There are two very different ways to implement that. One lets the AI act as soon as it decides what should happen, which makes an impressive demonstration because the user says one sentence and something changes. The other lets AI prepare the action and asks the user to confirm it. Arkonkt takes the second approach for the supported desktop actions that create a ToDo, Task or Note. The suggestion arrives as a draft that the user can read, edit, confirm or dismiss; nothing is written to the workspace until the user chooses to apply it.

The same principle appears in the Notes Template Builder. AI can draft or revise a reusable template, but the proposed revision is shown for review, and applying the proposal is still separate from saving the template itself. If the underlying draft changed while a proposal was waiting, the product warns before applying it rather than quietly overwriting newer work.

That confirmation step costs a little friction and buys a clear distinction between “the AI suggests this” and “the system has done this”. As models improve, it will become more tempting to remove that distinction. Our view is that capability should influence where approval is needed, but not erase the user’s awareness of consequential changes.

Sometimes the right answer should come from software, not AI

Another lesson from building Workspace AI is that not every question becomes better when a language model handles the whole problem. If a user asks which Tasks are assigned to them, the application can often determine that exactly from structured records. Letting a model search for an answer the database already knows adds uncertainty without adding intelligence.

A better design can establish the authorised records first, then let AI explain, summarise or discuss them where natural language genuinely helps. That is a useful division of labour: software handles the parts where exactness matters, and AI handles interpretation, synthesis and reasoning. Using less AI in the right place can produce a better AI experience overall.

The same argument is why we do not think every AI capability needs to be forced through one giant chat window. Writing a Note may call for review, suggested Tasks or a template. A meeting may need transcription, summary and follow-up. Hiring may use AI to prepare structured material under much stricter privacy expectations, without handing the employment decision to a model. A Knowledge Agent may publish selected knowledge outside a workspace only because an owner deliberately chose what may be exposed.

There is a reasonable argument for centralising all of that behind one assistant, and agents will increasingly coordinate several tools. The risk is that a universal interface can hide what happened: which information was used, which action is being prepared and which permission boundary matters. Users should not need to understand the architecture, but they should understand what the AI is doing on their behalf.

The goal is useful work, not an impressive chatbot

It is easy to be distracted by impressive output. A model writes a polished paragraph or answers something complicated, and that feels like progress. The more useful standard is whether the AI reduces the distance between understanding something and doing the right thing about it without weakening control over the work.

If an assistant tells you a Task needs attention but cannot take you back to the Task, something is missing. If it prepares an action but applies it before you see what it plans to do, something is missing. If it can answer only by reaching information the user should not see, something is badly wrong.

Today, people still notice when they are “using AI”. We do not think that remains the dominant experience. As AI becomes better integrated into software, a meeting can end with useful follow-up ready, a Task can be explained in the context of its Project, and a draft can be prepared where the work already lives. The interesting future is not software making more decisions while becoming less clear about how it made them. It is AI becoming more capable in the background while the product becomes clearer about context, evidence and control. That is the direction we want Arkonkt to take.