No second assistant

A standard that is deliberately departed from here

New software products today start almost reflexively with a certain basic equipment: real-time updates instead of reloading, a modern technical substructure, and practically always an in-app chatbot of their own through which users can ask questions without leaving the application. By now that chatbot belongs to new software almost as self-evidently as a search bar.

For JiCo, this one building block is not a gap that will be filled in at some point once there is time for it. It is a deliberate, reasoned departure from the otherwise usual standard. The reason for it is not a question of effort, priority or budget — it is a structural consideration that could not be solved with more development time: JiCo is already the AI interface to Jira and Confluence. A second assistant alongside it, meant to answer additional questions about the software itself, would not cover a new, so far unmet need. It would serve the same need a second time — with twice the effort for half the benefit.

Why this is not only about effort, but about attitude

The standard that is departed from here formulates a certain basic attitude for an in-app assistant: "proposing, not executing" — the chatbot is meant to help and to make suggestions, but not to change anything on its own. For most products that is a sensible but ultimately voluntary design decision among several possible ones. For JiCo this very attitude is not one option among several but the actual reason the whole product exists, written down as an immovable rule: no write access without human approval, without exception — even when JiCo cannot reliably classify the exact nature of a tool. In that case it automatically counts as writing, never as harmless.

Where other products treat this restraint as one of several equivalent variants that can be dialled up or down depending on the target group, for JiCo it is the actual reason for the product's existence. A change that would soften this rule anywhere — even at an apparently unimportant side location such as a second, supposedly harmless chat window — would therefore, strictly speaking, not be a new feature. It would be a defect at the core of the product, regardless of how useful the new feature might appear in isolation.

The simpler calculation behind this decision

Two separate conversational surfaces for the same fundamental task mean, in practice: two places where personal data could enter a model context in the first place, instead of one. Two places where the approval logic would have to be kept consistent over time, with the risk that one of them is overlooked at the next change. Two places that an audit trail would have to record without gaps, instead of being able to concentrate on a single, well-understood path.

The simplest workable solution here is not the one with the most functions or the longest list of building blocks — it is the one with the single clearly traceable path that carries everything: one route from the AI client to Jira, through the same redaction, the same approval, the same complete evidence. A second, parallel route alongside would not usefully complement that one path. It would puncture its guarantee, and it would do so in a place that looks harmless at first glance, because after all only questions about the software itself are supposed to be asked there.

The difference from an ordinary software chatbot

An ordinary in-app chatbot in another product usually answers harmless questions about operation and rarely intervenes in the actual customer data in a changing way — it explains how a function is used, nothing more. With JiCo the situation would be different, and that is exactly what makes the difference so significant: a second assistant existing alongside the actual Jira connection would have hardly any sensible justification for existing without eventually gaining access to the same sensitive content that JiCo watches over — otherwise it would only be a glorified table of contents for the product's own documentation, with limited benefit.

But as soon as there were even the possibility that a second channel also came into contact with the same ticket content, the entire carefully built chain of redaction, approval and evidence would be halved at a stroke — not because the second channel would deliberately be built worse, but because structurally there would be two channels, both of which would have to be maintained, checked and kept in step, with twice the opportunity for an oversight.

What that means for users day to day

In practice it means: anyone who wants to know something about JiCo itself — how a setting works, what a particular status means, how an error is to be read — finds the answer in the manual, in the documentation in the customer portal, or directly in the panel itself, not in an additional chat window running alongside that would potentially answer the same questions through a second, less controlled channel. That is a deliberate sacrifice of convenience in one place so that nothing is diluted in the place that actually matters — the handling of personal data from Jira and Confluence.