Planned feature
This feature is not available yet. Here is what is planned, so you can tell whether it will cover your need — and tell us if it will not.
Status — in development
Planned availability — server mode only
Summary
An assistant in a side panel, asked in plain language to act on the project: add a tab, build a chart, prepare a cohort. It asks for confirmation before every sensitive action, and each turn can be undone. The decisive point is not what it can do, but which model drives it: with a model installed inside the institution, no data leaves.
Why an assistant inside Linkr
Some tasks are long without being hard, others are genuinely difficult. The assistant targets both, but for different reasons.
The clearest case is code. Writing an analysis in R or Python means knowing the library, the syntax, the quirks of the dataset. That is where an assistant really changes things: describe what you want, get a script to read, correct it, run it again.
Next comes building a cohort, where the assistant brings something a human does not have easily: it can query the database to discover which concepts are actually present, under which codes, with what frequencies. Someone unfamiliar with a warehouse’s data will miss equivalent codes; the assistant looks for them.
Finally, assembling a dashboard — picking a dataset, adding widgets, configuring them — which you can do perfectly well by hand, but which becomes pleasant to dictate when you are building several, or declining the same monitoring across three units.
What is planned
A panel, not a page
The assistant will live in a resizable side panel, next to whatever you are looking at — never full screen.
That choice is not cosmetic. If the assistant changed a dashboard you could no longer see, you would lose the one control that really matters: watching the change happen. Seeing it land is the oversight mechanism.
The panel will be shared across the project rather than tied to a page: a dashboard request needs datasets, which come from the pipeline, which comes from the warehouse. One conversation, one history.
Two levels of detail
The same actions, told two ways depending on your role.
Clinician mode
One line of plain language per action.
Developer mode
The same actions, unfolded.
The exact arguments of each call, command output, line-by-line file differences, and the full plan the assistant is following.
This is a display setting, not a capability one: both modes see the same actions, told in more or less detail.
Confirm, then undo
Two safeguards work together.
Before a sensitive action — running a script, say — the assistant stops and asks. The script is shown to you before it runs. This is a deliberate middle ground: neither free execution nor an outright ban. An assistant that writes an analysis should be able to run it, but never without you having seen it.
Afterwards, each turn of the conversation can be undone with one button, restoring the project to the state it was in before the request.
What the assistant will never be able to do
Some actions will stay out of reach by construction rather than by instruction — an important difference: an instruction can be talked around, an architecture cannot.
Forbidden by design
- Manage permissions and members — a model granting access to health data: a risk with no upside.
- Configure the language models themselves, which stay with the workspace owner.
- Delete a project or a workspace.
- Push to a remote git repository.
- Read secrets: connection passwords are encrypted and never returned.
On top of that comes a rule covering everything else: the assistant never has more rights than you. It acts with your permissions, re-checked on every action. If you cannot edit a dashboard, neither can the assistant you are driving.
None of this is an instruction given to the model: these are tools it is not handed. An assistant deprived of a tool does not refrain from using it, it is incapable of it.
The question of the model
This is the decision to make before any other, and it belongs to the institution.
Local model
A model installed on your own machines. Requests never leave the institution — and the assistant can then work on clinical data without particular restriction.
Remote model
A service hosted by a third party. Requests leave the institution. An “External API” badge stays permanently visible, and data rows are not sent: only structure and aggregates are.
The decisive safeguard is that remote models can be forbidden at the instance level, once and for all, by the administrator. It then becomes a technical impossibility rather than a matter of discipline: nobody can enable an external model, even by mistake.
Why server mode only
The assistant needs to run a program alongside Linkr, which a browser on its own cannot do. This feature will therefore be limited to installations with a backend. See Deployment modes.
What is not settled yet
- The workspace assistant — same engine, but administrative actions (create a project, install from the catalog). It will come after the project one, with a deliberately narrow scope, and never permissions or members.
- How far the assistant may write code, depending on the profile. An R widget producing a
ggplot2is exactly what serves a clinician, and withholding it on principle would be a shame. But letting an agent write and run arbitrary code is not the same as letting it fill in a widget whose result appears in front of you. The line is still to be drawn — most likely between writing code in a widget, which you see and can undo, and opening a terminal, which is another matter. - The exact reach of the available actions beyond dashboards: cohorts and datasets are planned, the rest will be decided in use.
Going further
- Model providers — configuring a local or remote model, and what that implies.
- Skills — the reusable procedures the assistant will know how to apply.
- Authoring through MCP — having an agent produce Linkr content outside the app.