Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/aipoch/open-science/llms.txt

Use this file to discover all available pages before exploring further.

This roadmap is a living document — priorities shift as the project grows and the community contributes. It reflects the current codebase and design docs, and is updated as the project evolves. Phase kickoffs and priority calls are announced on X (@aipoch_ai) first and debated in Discord before they land here.

​
Current Status

Open Science is early alpha. The core plan → execute → produce → preview loop works end to end today, but the properties that would make this a genuinely science-grade tool — reproducibility guarantees, multi-model routing, a connector ecosystem, remote compute, and a skills commons — are mostly still ahead.
The following capabilities are working in the current codebase:
  • ✅ Agent runtime — a full plan/execute/tool-call loop, wrapped over the Agent Client Protocol (ACP)
  • ✅ Desktop shell — Electron + React + TypeScript with a shadcn-based design system
  • ✅ Multi-session workspace — parallel sessions with typed tool-activity visualization (diffs, code blocks, web search rows)
  • ✅ Project layer — per-project, per-file session storage with migration from the legacy single-file format and a home page
  • ✅ Persistent Python kernel — a durable notebook kernel with replayable run history
  • ✅ Artifact storage — files organized by session / message / run
  • ✅ Rich file previews — in-app rendering for CSV, FASTA, HTML, image, JSON, Markdown, and plain text
  • ✅ Attachment uploads and permission-approval UI — file ingestion wired into agent context, with an explicit tool-call approval gate for higher-risk actions

​
Delivery Phases

The foundation phase. Deliverables: this roadmap, the Product Requirements Document, the design system, the eight core design principles, and initial community formation.This phase established the architectural boundaries that all subsequent phases build on: a model-agnostic orchestration core, local-first data sovereignty, a skills-as-plain-files philosophy, and a human-in-the-loop permission model.
The working desktop application. Deliverables: the Electron + React desktop shell, the single-agent ACP runtime, project and session persistence, a Python notebook kernel, artifact storage, and rich in-app file previews — all shipping today.Still open in this phase:
  • A model-agnostic gateway — today’s runtime is wired to a single agent backend (Claude via ACP); multi-LLM routing is not yet implemented
  • A CLI / SDK entry point for scripting and embedding
  • A file-based skill runtime for loading and executing versioned agent skills
The project’s core scientific differentiation — and the highest-priority phase for contributors who want to make the biggest structural dent.Planned deliverables:
  • Artifact versioning and a full provenance chain — code, execution log, dependency graph, environment snapshot, and conversation context tied to every output
  • Additional execution kernels — an R kernel and a REPL control plane, alongside the existing Python kernel
  • Environment management — create, switch, snapshot, and register reproducible compute environments (Conda-style)
  • Specialist sub-agents alongside the generalist coordinator — genomics, proteomics, structural biology, cheminformatics, and non-life-science domains
Pick anything in this phase, open an Issue describing your approach, and start a Discussion if you want to debate the design before writing code.
Extending the workbench with scientific data and reusable skills.Planned deliverables:
  • Skills commons — versioned, forkable, human-readable skills with lexical discovery and explicit loading, designed to interoperate with aipoch/medical-research-skills
  • Pre-built data connectors to open scientific databases and literature (PubMed, UniProt, PDB, Ensembl, ClinVar, ChEMBL, GEO, arXiv/bioRxiv) callable from an isolated execution context
  • Savable specialist roles — bundles of instructions, skills, connectors, and permissions that define a reusable agent persona
Making Open Science credible for serious scientific workloads.Planned deliverables:
  • Remote compute — first-class support for SSH, Slurm/HPC clusters, and cloud GPU providers, with async job notification and sub-agent fan-out
  • Reviewer / verifier agent — an open, inspectable layer that checks citations, units, and statistical methods before output ships
  • Full security stack — scoped permission tiers (single-use / session / project / global), network allowlisting, directory-level file sandboxing, and a credential vault
  • Pluggable multi-agent-framework backend — so the runtime is not locked to one agent implementation
The open infrastructure endgame.Planned deliverables:
  • Open Science Commons — a public skills marketplace and optional hosted offering with institutional governance and audit features
  • Spatially-anchored annotations — feedback anchored to positions on images, PDFs, text, and HTML surfaces
  • Interactive scientific viewers — molecule/structure editors, genome browsers, and other domain-specific visualizations
  • Dynamic context injection — skill-aware context compaction and history management so agents always work with the most relevant context

​
Long-Term Horizons

Underneath the delivery phases sits a longer arc — five horizons that describe what “done” looks like for AI-native science as a field, not just for this codebase. The current implementation is an early working stretch of Horizons 1 and 2.
  1. Scientific Connectivity — Ship a foundational access client that registers scientific data sources and life-science tooling as directly callable agent capabilities, turning scattered, siloed scientific databases into infrastructure an agent can reach immediately instead of a dozen browser tabs a human has to operate by hand.
  2. Agent Portability — Make scientific intelligence portable across models, frameworks, and research environments, so capability follows the scientist rather than being locked to one vendor’s interface. A skill, a workflow, or an analysis a lab builds should keep working when it moves to a different model, a different orchestration framework, or a different institution’s infrastructure.
  3. Context-Aware Discovery — Move from tool abundance to tool intelligence: an agent facing hundreds of available capabilities should discover, select, and compose only the ones a given task, its evidence, and the surrounding research context actually call for — not enumerate everything it could theoretically use.
  4. Closed-Loop Research — Connect literature, computation, simulation, notebooks, and verification into a single traceable discovery loop, where a hypothesis can be generated, challenged, executed, and refined without leaving the loop or losing its provenance at each handoff.
  5. Open Science Commons — Arrive at a shared intelligence layer for AI-native science — an open infrastructure where protocols, agents, datasets, workflows, and governance live in the open and compose across labs, models, and platforms, so reproducible discovery isn’t bottlenecked on any single one of them.

​
Non-Goals

Some limits are deliberate, not oversights:
  • Not a real-time multi-user collaboration editor. Open Science is single-researcher focused. Team workflows go through export / share / import, not live co-editing.
  • Computation and outputs, not research semantics. The system models code, data, and artifacts — it does not bake in “hypothesis / experiment / conclusion” as first-class structured entities.
  • Not a proxy or reskin of any closed-source product. Open Science shares no code with any single vendor’s client and is not designed to route around a vendor’s billing or terms of service — it is an independent, from-scratch implementation of the same category of tool, built to be self-hosted and fully inspectable.
  • Does not replace domain-expert judgment. Statistical validity, batch-effect analysis, and data-leakage risk are still calls a human researcher has to make. Open Science lowers the cost of executing and recording research, not the cost of judging it.
  • Reproducibility is best-effort and layered. Phase 2 provenance targets code, logs, dependencies, and environment snapshots. Exact skill-version pinning across time remains a known gap, not a solved problem.
Ready to contribute? Head to the Contributing Overview to learn about the development workflow, required checks, commit style, and how to open a pull request. The highest-impact work right now is in Phase 2 — pick any ⬜ or 🟡 item from the capability map, open an Issue, and start building.

Build docs developers (and LLMs) love

Get started for freeTalk to us