---
title: "How to Use Multica for Scientific Research"
description: "Real research runs on a self-hosted Multica workspace using K-Dense Scientific Agent Skills: trials, variants, literature, and cross-model review."
updatedAt: "2026-08-18"
author: "Timothy Kassis, PhD"
authorTwitter: "timothykassis"
authorLinkedIn: "https://www.linkedin.com/in/timothykassis/"
tags: ["AI", "Tutorial", "Open Source", "Scientific Agent Skills", "Research", "Multica"]
canonical: "https://www.k-dense.ai/blog/multica-scientific-research"
---
Most researchers now run more than one coding agent. Claude Code is open in one terminal tab, Codex or Cursor in another, and each one forgets everything the moment the session ends. The context you spent twenty minutes assembling, which dataset, which QC thresholds, which version of the reference, has to be rebuilt from scratch the next morning. Worse, when the analysis is finished there is no durable record of how it was produced beyond a scrollback buffer you will close by Friday.

[Multica](https://github.com/multica-ai/multica) is an open-source workspace built for that problem. You assign an issue to an agent the way you would assign it to a colleague, the agent picks it up, works on a machine you control, comments as it goes, and hands the result back for review. It supports 20 agent CLIs, it self-hosts on Docker or Helm, and it is Apache 2.0 with additional conditions covering hosted services and commercial embedding.

Multica is not a science platform and does not claim to be. Its documentation is written for engineering teams, and it ships no scientific capability at all: no connected databases, no bioinformatics tooling, no domain knowledge, no benchmark score for research work. Out of the box it coordinates agents that know nothing in particular about your field.

The gap is fillable. Multica's Skills feature imports `SKILL.md` bundles directly from GitHub, and K-Dense maintains [Scientific Agent Skills](https://github.com/K-Dense-AI/scientific-agent-skills), an open collection of 163 skills across 18 scientific domains in exactly that format. Put the two together and you have a self-hosted, model-agnostic research workspace where the scientific competence is a set of files you can read, audit, and modify.

The project's own [VISION.md](https://github.com/multica-ai/multica/blob/main/VISION.md) is explicit that this is in scope: "The same model applies wherever knowledge work moves through context, collaboration, and review. Agents can organise research, prepare customer briefs, draft content, progress support work, or coordinate client deliverables."

Everything below comes from an actual installation. We self-hosted Multica, imported the skills, and ran three analyses across clinical trials, human genetics, and the literature, put a fourth on a weekly schedule, and had a second model from a different vendor audit the first one. We checked the numbers against the source data ourselves throughout, and the whole exercise came to $7.00 in agent time.

**Disclosure:** K-Dense maintains Scientific Agent Skills and sells K-Dense Web, and the benchmark figures quoted in the comparison section are from our own published evaluations. We have linked those posts so you can read their methods and limitations, and the comparison section names the cases where Claude Science and Biomni Lab beat us.

## What the stack looks like

Each layer does one job. Multica provides the workspace layer: issues and assignment, agents bound to runtimes, autopilots on a cron, a replayable execution log, per-run token accounting, review gates, and self-hosting. Scientific Agent Skills provides the knowledge layer: 163 skills covering bioinformatics and genomics, cheminformatics, clinical research, medical imaging, machine learning, materials science, laboratory automation, scientific communication, and a `database-lookup` skill that documents more than 100 scientific databases. The agent CLI in the middle, whichever one you pick, provides the reasoning.

None of these three layers is locked to the others. You can swap the agent CLI per task, replace or fork any skill, and move the whole workspace to different infrastructure, because every piece is either open source or a file on your disk.

## Getting Multica running

We will not reproduce the install here, because Multica's own [quickstart](https://multica.ai/docs/cloud-quickstart) and [self-hosting guide](https://github.com/multica-ai/multica/blob/main/SELF_HOSTING.md) are current and ours would go stale. Everything below ran on a self-hosted instance, a Compose stack of Postgres with pgvector, a Go backend, and a Next.js frontend, on a laptop.

Multica starts a daemon on the machine, and the daemon scans for agent CLIs that are already installed and registers each one as a runtime. Four appeared without any configuration, backed by Claude Code, Cursor, Hermes, and Pi, and each became a provider an agent could be bound to. The work below uses three of them, including one that failed.

### Building the team

Agents live on an Agents page that reads like a staff directory. Each row is a name, a one-line description, the runtime it runs on, whether it is online, and how many runs it has done.

![Multica Agents page listing four agents with their runtimes, status, and run counts](./agents-roster.png)

*Four agents on four different runtimes. Curie does the analysis on Claude Code; the other three were built as second-opinion reviewers on Cursor, Pi, and Hermes.*

Creating one starts with a choice between configuring every field yourself and describing what you want to an agent builder that interviews you and drafts it. We took the manual route. The form asks for a name, a description, and then the part that matters for research work, a free-text Instructions box that the agent carries into every task it ever picks up.

![Multica agent creation form showing the instructions box and the control for attaching workspace skills](./agent-form.png)

*Behaviour and capabilities in one panel: standing instructions, then a picker for attaching workspace skills.*

Ours told Curie to work from primary sources, cite accession numbers and DOIs, never invent a number and stop instead if a value cannot be retrieved, save every artifact to the working directory, and state uncertainties before conclusions. Writing that once is the difference between an agent that behaves like a research assistant and one that behaves like a chatbot, and you never type it again.

Below that, an Execution panel picks the runtime, optionally overrides the model, and sets a thinking level. This is where the vendor-agnostic claim becomes a dropdown: the same agent definition can sit on Claude Code or Cursor, and swapping is a menu selection rather than a migration.

![Multica execution panel with runtime, model, thinking level, and access controls](./agent-runtime.png)

*Runtime, model, and reasoning level, plus who is allowed to start runs with this agent.*

### Importing the skills

Skills are added from the Skills page, which offers three routes: write a `SKILL.md` by hand, import one from a URL, or promote a skill already installed on your runtime. Import accepts ClawHub, Skills.sh, and GitHub, and the files are pulled server-side.

One limit is worth knowing before you start. Multica imports one skill at a time, and the URL has to point at a directory containing a `SKILL.md`. Pointing it at the root of a multi-skill repository fails, though the dialog tells you exactly what to do instead:

![Multica skill import dialog showing an inline error explaining that multi-skill repositories need a per-skill directory URL](./skill-import.png)

*Pasting the repository root produces a clear error and the corrected URL shape, with GitHub auto-detected as the source.*

So the workflow is one paste per skill, using `github.com/K-Dense-AI/scientific-agent-skills/tree/main/<skill-name>`. We imported eight: `database-lookup`, `exploratory-data-analysis`, `statistical-analysis`, `polars`, `matplotlib`, `scientific-writing`, `paper-lookup`, and `literature-review`. Importing a curated subset rather than all 163 keeps the agent's skill index small and makes the security review tractable, so it is probably what you want anyway. It does mean there is no one-click path from a catalogue to a working research agent.

![Skills page listing the eight imported Scientific Agent Skills and which agents use each one](./skills-imported.png)

*The Skills page after import. "Used by" tracks which agents each skill is attached to, since skills have to be attached explicitly rather than being available to everything by default.*

The import brings the whole skill, not just the instructions file. `database-lookup` landed as 25,982 characters of `SKILL.md` plus 80 supporting reference files, including the `references/clinicaltrials.md` that the analysis below depends on. Progressive disclosure survives the import, which is what makes a skill that size usable.

On the machine where the agent runs, those files are written into a content-addressed cache keyed by SHA-256, so the exact bytes an agent read on a given run are identifiable after the fact.

## What the workflows actually look like

### 1. Assign an analysis and get an auditable answer back

We filed a deliberately demanding issue: map the interventional ALS trial landscape on ClinicalTrials.gov for records first posted between 2015-01-01 and 2025-12-31, save the raw API response before analysing anything, report counts by phase, status, and sponsor class, produce a figure, and state missingness on every grouped field. The instruction ended with "If the API is unreachable or returns fewer records than expected, say so and stop rather than estimating."

You file it the way you would file any ticket: a title, a description, a priority. The only thing that makes it an agent task is the assignee, and the assignee menu lists people and agents together.

![Multica assignee picker showing members and agents in a single list](./assign-picker.png)

*One picker, one list. Members at the top, agents below. Choosing an agent is the same gesture as choosing a colleague.*

The composer says so directly at the bottom of the form: "Curie will start working right after creation." No run button, no separate dispatch step, no prompt window. The agent picked it up on its own and worked for 3 minutes 18 seconds, retrieving 478 records across three pages and producing a flattened CSV, a raw JSON archive, three Python scripts, and a figure. Its write-up opens with everything needed to repeat the query.

![Agent report in Multica showing retrieval date, API version, dataTimestamp, the exact query URL, and record count reconciliation](./report-provenance.png)

*Retrieval date, API version, the registry's own `dataTimestamp`, the exact query URL, and a record count reconciled against `totalCount` and page sizes, before a single result is discussed.*

![Stacked bar chart of ALS interventional trials by study start year and lead-sponsor class](./als-trials-figure.png)

*The figure the agent produced, unedited. Note that it shaded the first-posted window and added its own footnote explaining that the cohort axis and the plotted axis are not the same thing.*

We checked its work rather than trusting it. Recomputing every table directly from the CSV reproduced the agent's numbers exactly: 478 unique NCT IDs, zero non-interventional records, zero records outside the date window, 180 trials with no applicable phase, 196 completed, 288 academic or other sponsors. The `totalCount` in the raw API response was also 478, so the pagination was complete.

The limitations section went further than the instruction asked for. It flagged that `query.cond` uses the registry's server-side synonym expansion rather than a curated ALS list, and that this let at least two false positives into the cohort. We queried both directly against the API to check:

| NCT ID | Brief title | Registered condition |
|---|---|---|
| `NCT03455309` | Evaluation of NDV-3A Vaccine in Preventing S. Aureus Colonization | Staphylococcus Aureus |
| `NCT07002034` | RE104 Safety and Efficacy Study in Adjustment Disorder | Adjustment Disorder |

Both were exactly as described. The agent also noted that "NIH = 2" measures NIH as *lead sponsor* and understates NIH involvement, since nine further records list an NIH-family collaborator behind a non-NIH lead, and that "Unknown status" for 65 trials means the record passed its expected completion date without a sponsor update rather than anything knowable about the trial. It declined to silently drop the false positives, reporting instead that removing the two clear ones would give 476.

That behaviour came from the standing instructions and the `database-lookup` skill's insistence on documented endpoints, not from anything Multica did.

### 2. A different database, the same agent

The `database-lookup` skill documents more than 100 databases, so switching domains does not mean rebuilding anything. We assigned the same agent a genomics question: characterise the reported SOD1 variant landscape in ClinVar, cross-tabulate clinical significance against review status so it is visible how much of the pathogenic set has more than one submitter behind it, and produce a figure that makes the evidence-quality picture legible.

It retrieved 390 variation records through NCBI E-utilities, reconciled against `esearch` count 390 and four `esummary` batches of 100, 100, 100, and 90. The report gave the Entrez ClinVar build string, `Build260818-0035.1`, and noted that E-utilities does not expose the monthly FTP release label, so that build string is the closest available version identifier.

It also ran two control queries nobody asked for. A free-text `SOD1` search returned 403 rather than 390, and the extra 13 records were enumerated as variants in other genes that merely mention SOD1 in their condition text, LOX, CNTF, MATR3, UNC13A, SETX, ANG and others, correctly excluded by the `[gene]` filter. A `BRCA1[gene]` query returning 16,061 records confirmed the gene index was not silently truncating. We reproduced both control numbers, 390 and 403, directly against the API.

![Two-panel figure showing SOD1 ClinVar review status within each germline classification and evidence depth of pathogenic records](./sod1-clinvar-figure.png)

*Panel A breaks each classification down by review status, panel B shows how many submitted records sit behind the pathogenic and likely-pathogenic set. The source, retrieval date, and build string are in the subtitle.*

The headline result is about evidence quality: of 191 pathogenic or likely-pathogenic SOD1 records, 124 (65%) rest on a single submitted record, and no SOD1 record in ClinVar carries a 3-star expert-panel or 4-star practice-guideline review status at all.

The most-submitted variant in the set, `NM_000454.5(SOD1):c.272A>C (p.Asp91Ala)` with 24 submitted records, is filed under "Conflicting classifications of pathogenicity", and the agent identified it as the well-known reduced-penetrance case rather than a data-quality problem. We confirmed the variation ID, the submission count, and the classification against the retrieved records. It closed by warning that stars encode review provenance rather than the strength of the underlying functional or segregation evidence, that two labs applying ACMG rules to the same single family report still produce a 2-star record, and that concordance is not independence when submitters have all copied the same published evidence.

None of that comes from Multica; it comes from the skill and the standing instructions. What the workspace contributed was letting us point the same configured agent at a different database without changing anything about it.

### 3. Ask a question where the honest answer is "that number is not reliable"

The third analysis was bibliometric: how has ALS therapeutic research changed over 2015 to 2025? We asked for counts per year normalised against total publication volume, a breakdown by therapeutic modality, the ten most-cited papers, and an explicit statement of how the modality assignment was made and how reliable it is.

It queried PubMed and OpenAlex separately, 218 and 71 API calls respectively, and refused to merge them, keeping two corpus definitions apart because they trade recall against precision differently. A high-precision MeSH definition returned 2,678 records, a broader title/abstract definition returned 9,796, and the OpenAlex replicate returned 11,954.

![Four-panel figure of ALS therapeutic literature trends, normalised two ways, with a modality panel marking unreliable series](./als-literature-trend.png)

*Panel C plots raw counts, the denominator, and the normalised rate together, showing how much of the apparent growth is the database getting bigger.*

Raw counts roughly double over the window, but about half of that is database growth, so it declined to lead with the doubling. It led with the internally normalised finding instead: therapeutic work went from about 36.5% to 53.6% of all ALS literature, a ratio whose numerator and denominator share the same disease anchor, and one PubMed and OpenAlex agree on closely. We reproduced its 2015 PubMed count of 641 against the live API.

Asked to break the corpus down by modality, it built keyword and MeSH bucket definitions and then audited its own classifier before reporting anything: a systematic sample of 15 titles per bucket, read and judged individually. Two of the four buckets failed.

| Modality | Window total | Estimated precision | Usable |
|---|---:|---:|---|
| Small molecule | 988 | ~80% | Directionally |
| Cell therapy | 400 | ~67% | Directionally |
| ASO / gene therapy | 815 | ~53% | **No** |
| Biologic | 315 | ~33% | **No** |

The biologic sample was 5 of 15 on target, having pulled in an intermittent-fasting review, a cost study of a different neuropathy, and a colorectal cancer trial that happened to involve riluzole. 77% of the corpus matches no bucket at all, so the buckets are a lower bound on a minority of the corpus, not a partition of it, and 270 records fall into two or more buckets. The figure marks the failing series as dotted lines and annotates the panel with the caveat, so the chart carries its own warning if anyone lifts it out of context.

Each limitation was measured rather than gestured at. PubMed `[dp]` matches both electronic and print years, so one record can satisfy two adjacent year filters, which it quantified as 10,938 year-hits against 9,796 unique records and localised to specific adjacent-year pairs. MeSH indexing is not stable across the window, peaking in 2021 and declining through 2025 because of NLM indexing lag rather than any real decline, which is precisely why it did not use the MeSH definition for the trend. And "motor neuron disease" pulls in 144 spinal muscular atrophy records, 1.5% of the corpus.

An agent that hands you a modality chart and stays quiet about a 33% precision rate is worse than useless in a research setting, because a bad chart looks exactly as authoritative as a good one.

### 4. Have a second model check the first

Having 20 agent CLIs in one workspace makes a specific check cheap. We filed a review issue pointing at the raw artifacts from the first analysis on disk, told the reviewer to recompute the headline numbers without reusing the original CSV or scripts, and asked for a CONFIRMED, REFUTED, or PARTIAL verdict on five specific points. Then we assigned it to an agent on a different vendor's model.

The first attempt failed. Multica 0.4.29 invokes `cursor-agent` with a `--yolo` flag, and the installed cursor-agent build rejects it:

```
[cursor:stderr] error: unknown option '--yolo'
cursor-agent finished status=failed duration=443ms
task did not complete, reporting failure status=blocked failure_reason=agent_error.process_failure
```

Expect version drift between the workspace and 20 independently released CLIs; it is a standing maintenance cost. Multica handled it well enough: the task went to `blocked` with a stated reason instead of disappearing or silently returning nothing, and the exact stderr was preserved for diagnosis.

We reassigned the review to an agent on the Pi runtime instead, and that ran. It parsed the 14.9 MB raw JSON payload directly and confirmed every headline number: 478 records over three pages, 478 unique NCT IDs, 180 phase-NA, 196 completed, and the 288 academic/other group reconstructed from its `OTHER` 273, `OTHER_GOV` 13, `INDIV` 1, and `NETWORK` 1 components. All 478 records really were interventional and really did fall inside the first-posted window, and it reported the boundary dates it found.

Then it disagreed in two places.

![Cross-model review verdict marked PARTIAL, refuting the first agent's completeness claim, with the MeSH indexing mechanism explained](./cross-model-review.png)

*The reviewer's verdict on the false-positive question, including the indexing mechanism that let a Staphylococcus aureus vaccine trial into an ALS cohort.*

On the false positives it returned PARTIAL, explicitly refuting the first agent's completeness claim. It confirmed both cases the first agent had found, and explained the mechanism behind one of them: `NCT03455309` carries `Als3` in its keywords, the antigen name, and the registry's automated indexing mapped that to the MeSH term for "Amyotrophic Lateral Sclerosis 3", pulling a *Staphylococcus aureus* vaccine trial into an ALS cohort. We pulled the record ourselves and the keyword list is exactly `['Als3', 'SSTI', 'vaccine', 'NDV-3A', 'incident nasal colonization']`.

It also found one the first agent had missed. `NCT06711510` is a frontotemporal dementia study restricted to carriers of a pathogenic progranulin mutation, with "absence of any other neurological disease" as an inclusion criterion, and it lists `amyotrophic lateral sclerosis` as a keyword because of the TDP-43 overlap. We checked, and its registered conditions are frontotemporal dementia and GRN-related FTD, with ALS appearing only in the keyword list. The reviewer's conclusion was that the first agent's "removing the two clear false positives would give 476" should have been 475 or fewer.

It was harder on the limitations section than the first agent had been on itself. The large phase-NA fraction is the registry's standard coding for non-pharmacological interventions, which for ALS means brain-computer interfaces, non-invasive ventilation, communication devices, and caregiver studies. Reporting 37.7% "NA" without saying so makes a real feature of the ALS trial landscape look like a data-quality problem.

Two models from different vendors read the same raw file, and the second found a mistake in the first. A single-vendor chat product has no equivalent, and the check took a few minutes.

### 5. Read the execution log

When the run finished, the issue carried a complete replay of how it got there.

![Multica execution log showing 17 commands and 23 steps across a 3 minute 18 second run](./execution-log.png)

*Every command, timestamped, with model time and tool time separated.*

The log records 17 commands across 23 steps, and it is honest about the parts that did not go smoothly. You can see the agent load the skill (`Skill database-lookup`), read the reference file, hit a `400` from the API, run a step labelled `Diagnose 400 error`, and then `Re-run full pagination` successfully. A chat transcript would have shown you the same story only if the agent chose to narrate it.

Each run also carries its cost, which chat interfaces rarely expose.

![Issue detail panel showing the execution log summary of 953.3K tokens and $1.24](./issue-token-cost.png)

*953.3K tokens and $1.24 for the whole analysis, attributed to the issue and to the agent that did it.*

The accounting rolls up to the workspace, which is the number a PI or a core facility budgets against.

![Multica analytics showing $7.00 cost, 7M tokens, 30 minutes 46 seconds of run time across 6 tasks with 1 failed](./analytics-totals.png)

*Every run in this post came to $7.00 and just over 30 minutes of agent time across six tasks. The failed one is counted rather than hidden.*

One caveat on those figures. Cost is reported per provider, and the Pi-backed reviewer logged 1.3M tokens at `$0.00` because no pricing is attached to that runtime, so the workspace total understates what a mixed-vendor setup really costs. Token counts are reliable; treat the dollar column as provider-dependent.

### 6. Put a standing analysis on a cron

Literature and registry landscapes move. Autopilots run a prompt on a schedule and, set to "Create issue", file each result as a new issue so it lands on the same board as everything else.

The composer puts the whole thing on one screen. The left half is a runbook, described as what the agent reads on every run, and it opens with a Goal, Context, and Steps scaffold rather than an empty box. The right half sets the assignee, whether each run creates a tracked issue or runs silently, who gets subscribed to the issues it files, and the trigger.

![Multica autopilot composer showing the runbook scaffold alongside assignee, output mode, and trigger settings](./autopilot-form.png)

*A runbook on the left, delivery and scheduling on the right. The footer notes that once saved, it runs automatically until paused.*

The trigger is either a schedule or a webhook, and the schedule builder shows you the cron expression it is writing along with the next few fire times, so you can check it means what you think before saving.

![Multica autopilot schedule showing the generated cron expression 0 9 * * 1 and upcoming run times](./autopilot-schedule.png)

*The saved trigger: Monday at 09:00 in a named timezone, the generated `0 9 * * 1`, and the next run it will fire.*

We ran it once manually with the Run now button to confirm the loop closes. The prompt tells it to report nothing if nothing changed, and to escalate two specific events, any trial moving to terminated, suspended, or withdrawn, and any new phase 3 registration. A saved search cannot decide what deserves your attention; this can.

The run filed itself as a new issue and titled itself with its own result:

> **ALS interventional registry sweep, 2026-08-12 to 2026-08-18: 5 updates, 0 new registrations, 0 halts**

With the finding in the title, a month of sweeps can be triaged from the board without opening any of them. The body carried the reconciliation needed to trust that "0 new registrations" meant the query ran rather than silently failed: `totalCount` 5, five returned, `nextPageToken` null, single page complete, plus a separate cross-check against terminated, suspended, and withdrawn statuses that also returned zero. Its headline read "Nothing urgent", which is the right answer for a quiet week.

### The review gate

When the analysis finished, the issue moved to In Review, not Done.

![Multica board showing the completed analysis sitting in the In Review column](./board-in-review.png)

*The agent finished, and the work stopped in review rather than being marked complete.*

For scientific work that default is the right way round. A result nobody has read is not a result yet, and an agent that cannot mark its own output finished is different in kind from a chat window where the last message is the deliverable.

## Before you import anything: skills are executable code

Multica's own documentation is direct about this: "Imported content is handed to agents as-is, so the source needs to be trusted."

A skill is a folder that steers your agent's behaviour, and it can ship a `scripts/` directory the agent executes via bash without ever loading the contents into its context. In a research setting the credentials an agent can reach are often irreplaceable, a DNAnexus token tied to a specific IRB, a Benchling key attached to unpublished data, an AWS role with read access to patient imaging. We wrote a full guide to auditing skills before installation in [Security in the Science Agent Era](/blog/skill-security-before-you-install), and every point in it applies to our own repository as much as to anyone else's.

Self-hosting helps here in a way a hosted platform cannot: you decide what the machine running those skills can reach.

## How this compares to Claude Science and Biomni Lab

This compares architecture, not scientific ability. Claude Science and Biomni Lab are research platforms with the science built in. Multica plus Scientific Agent Skills is something you assemble, and its advantages are structural. None of them is a claim that it does better science.

| | Multica + Scientific Agent Skills | Claude Science | Biomni Lab |
|---|---|---|---|
| Where data lives | Your machine or your infra | Vendor cloud | Vendor cloud |
| Model choice | 20 agent CLIs, swappable per task | Anthropic models | Fixed |
| Cross-vendor checking | One model audits another's output | Not possible | Not possible |
| Science out of the box | None, imported as skills | Built in | Curated biomedical tooling |
| Provenance | Replayable execution log per run | Chat transcript | Platform-managed |
| Scheduled standing work | Autopilots on cron | No | No |
| Review before it counts | Review gate, work stops there | Read the output | Read the output |
| Cost visibility | Per agent, per issue | Subscription | Platform |
| Auditable capability | MIT skills you can read and fork | Closed | Closed |
| Setup cost | One-click desktop installer, or Docker to self-host | Zero | Zero |

Five of those rows are things a hosted platform cannot retrofit. Data residency is absolute rather than contractual, since every analysis above ran on a laptop against a Postgres container bound to localhost, which is a different kind of assurance from a data-processing agreement. Model choice means an expensive reasoning model on the hard analysis and a cheap one on the weekly sweep, decided per agent. Cross-vendor checking is the one we would defend hardest: a single-vendor platform cannot mark its own homework with a different model, and in our run that check caught a false positive the first agent had missed. Scheduled standing work has no equivalent in either comparison platform, since both are session-shaped. And a review gate is something a chat window cannot express, because the last message is always the deliverable.

### When to use something else instead

We would give the same advice to a colleague.

**Use Claude Science when the scientific reasoning itself is the hard part.** In our own [20-task comparison](/blog/k-dense-web-vs-claude-science), Claude Science earned the higher mean scientific-quality score, 55.3/75 against K-Dense Web's 53.1/75, and produced the single best result in the entire benchmark. K-Dense Web won the composite, 67.8 to 61.8, on the strength of research execution and auditable output, but that is a different axis. If your bottleneck is thinking rather than plumbing, the plumbing advantages here will not help you.

**Use Biomni Lab when you want curated biomedical tooling with zero setup.** It scores 88.7% on [BixBench-Verified-50](/blog/bixbench-verified-50) against K-Dense Web's 90.0%, which is close, and it gets there with nothing to install or operate. For a wet-lab group with no computational staff, that trade is usually correct.

**Use [K-Dense BYOK](https://github.com/K-Dense-AI/k-dense-byok) when you want the scientific surface Multica does not have.** This is the sharpest trade in the list, and it runs the other way from everything above. Multica is a general work surface: issues, comments, review columns. It has no idea what a chromatogram is. K-Dense BYOK is a free MIT-licensed desktop app, running on your own API keys against OpenRouter or a local Ollama install, and it is built for the parts of research that happen after the analysis finishes:

- A **living lab notebook** that records the reasoning trail as the agents work, logging hypotheses, methods, observations, decisions, confidence, code, and linked artifacts. Multica's execution log tells you what commands ran; a notebook tells you what you were thinking.
- A **LaTeX editor** with split source and PDF view, automatic compilation, pdfLaTeX, XeLaTeX and LuaLaTeX, inline errors, outline and word count, and two-way jumps between source and PDF. Multica has no manuscript surface at all.
- Previews for **60+ scientific formats**, including interactive 3D protein and molecular structures, 2D chemical structures, spectra and chromatograms, sequence alignments, phylogenetic trees, single-cell and array data, and DICOM, NIfTI and microscopy images. In Multica, a `.pdb` or a `.fcs` file is an opaque attachment.
- 149 scientific skills, 326 guided workflow templates across 22 disciplines, 229 data resources, and 21 specialists that take focused assignments such as statistical review, citation checking, or peer review.

What it does not give you is the multi-agent workspace: no assignment to a named teammate, no review gate, no autopilots, no shared board. If your bottleneck is looking at scientific data and writing it up, this is the better tool. If it is coordinating several agents and several people around a queue of work, Multica is.

**Use [K-Dense Web](https://app.k-dense.ai) when you want all of this assembled and maintained for you.** It is our hosted platform, and the honest trade is the one at the top of this section reversed: you give up self-hosting and model choice, and you get the skills, the compute, the connected databases, and auditable research bundles without operating anything. It scored 90.0% on BixBench-Verified-50 and led our 20-task benchmark on composite score.

**Skip the self-hosted route if nobody on the team wants to operate infrastructure.** The desktop installer is genuinely one click, and for a single researcher on one machine that is the whole setup. Running the full self-hosted stack is a different commitment, and it is the one worth thinking twice about: ours went smoothly because Docker, four agent CLIs, and their credentials were already in place. Starting from nothing, be honest about who maintains it in six months.

Multica plus imported skills also has no benchmark score as a research stack. We verified each analysis above against its own source data and they held up, and a second model audited one of them, but four tasks are a demonstration, not an evaluation.

## Getting started

Start with the layer that does the scientific work. It is free, you can read it, and it runs in whatever agent you already use:

```bash
npx skills add K-Dense-AI/scientific-agent-skills
```

That gives you 163 skills across 18 domains under an MIT licence, usable in Claude Code, Cursor, Codex, or any Agent Skills host, with or without Multica. Read a few `SKILL.md` files before you trust them, and read [our security guide](/blog/skill-security-before-you-install) first. For the workspace layer, Multica's [quickstart](https://multica.ai/docs/cloud-quickstart) and [self-hosting guide](https://github.com/multica-ai/multica/blob/main/SELF_HOSTING.md) cover the install.

If none of this sounds like something you want to operate, that reaction is reasonable. [K-Dense Web](https://app.k-dense.ai) is the same idea with the assembly already done: the skills, the compute, the databases, and auditable research bundles, without a daemon to babysit. We also wrote an [honest comparison of the hosted product against our own open-source skills](/blog/k-dense-web-vs-scientific-agent-skills), including the cases where the open-source route is genuinely the better call.

## The open-source pieces, and where each one plugs in

Multica gives an agent two fields that matter for research: an Instructions box and a set of attached skills. Everything below is free, MIT licensed unless noted, and exists to fill one of those two fields, or to do the part of the job Multica does not touch.

**[Scientific Agent Skills](https://github.com/K-Dense-AI/scientific-agent-skills)** fills the skills field. 163 skills across 18 domains, covering bioinformatics, cheminformatics, clinical research, imaging, materials science, and a `database-lookup` skill documenting more than 100 databases. This is the collection the four analyses in this post ran on, and it imports into Multica one directory at a time as shown above. It also works standalone in Claude Code, Cursor, or Codex if you never touch Multica at all.

**[Scientific Agents](https://github.com/K-Dense-AI/scientific-agents)** fills the Instructions box. These are expert-thinking `AGENTS.md` profiles that teach an agent to reason like a senior practitioner in a domain: how an expert frames the problem, picks tools and data, stress-tests a claim, troubleshoots, and reports what they found. The standing instructions we wrote for Curie by hand are a crude version of this. A profile from here is the researched version, and Multica's Instructions field is exactly where it goes.

**[Mimeo](https://github.com/K-Dense-AI/mimeo)** manufactures more of both. Point it at an expert and it reads their talks, essays, interviews, papers, and letters, then distills the recurring mental models into a `SKILL.md` or `AGENTS.md`. If your lab has a methods lead whose judgement everyone defers to, or a subfield with a canonical figure whose approach you want an agent to imitate, this is how you get that into a file Multica can import. It closes the loop: mimeo writes the skill, Multica imports it, the agent uses it, the execution log records what it did.

**[K-Dense BYOK](https://github.com/K-Dense-AI/k-dense-byok)** does not plug into Multica, and that is the point. It runs beside it as the scientific surface Multica lacks: the living lab notebook, the LaTeX editor with split source and PDF view, previews for 60+ scientific formats from 3D protein structures to spectra to DICOM, and 21 specialists for statistical review, citation checking, and peer review. A reasonable division is Multica for coordinating the work and BYOK for looking at the results and writing them up.

The through-line is that none of this is locked to anything. A skill is a folder, a profile is a Markdown file, and both are readable in the time it takes to finish this post. That is worth more in a research setting than any single feature, because it is what lets you check what you are running before you point it at data that took two years to collect.

Whichever route you take, the models were never the hard part in these four runs. What made the results usable was that the query URLs, the raw payloads, the costs, and the run that failed were all still on disk afterwards, so somebody else could check the work. That is the part a scrollback buffer does not give you.