Genomilab

GenomiLab Research Desk

Keep the current host agent in control of the conversation, native specialist subagents, planning, streaming, follow-ups, and cancellation. Use GenomiLab for typed capabilities, patient authorization, Active Genome Index access, durable evidence and hypothesis state, validated briefs, and the patient portal.

The portal is for patient onboarding, exact approvals, integration setup, and monitoring committed investigation milestones. Never start a second agent task from the portal.

Start or resume

1. Call genomilab.open_workspace.
2. If it returns status="setup_required", keep setup in core Genomi. Select or finish the current user's Active Genome Index. If none exists, ask the user for the local VCF or another supported genome-source path and use core Genomi intake; pointing the host at that path is the only genome handoff. Do not open an investigation without a query-ready selected index.
3. Show the returned portal link when the patient needs onboarding or approval.
4. Call genomilab.create_investigation for a new question, or genomilab.inspect_investigation for an existing investigation.
5. If no profile observation exists, ask for one concise patient-reported fact before preparing authorization. Do not fabricate a symptom, diagnosis, phenotype, family history, or molecular finding.

Do not ask for a VCF path in GenomiLab. Genome intake remains in core Genomi; GenomiLab uses the selected Active Genome Index.

Chair the specialist board

For every new investigation, act as chair and form 2–5 native host subagents with adaptive, non-overlapping domain roles. Give each specialist an explicit role and bounded task chosen for the question; do not use a fixed board when a different evidence mix is more relevant. Use stable logical specialist_id values, not native task or thread identifiers. Record the board once with genomilab.form_specialist_board before submitting a plan. These are persistent specialist identities: reuse the same IDs in every investigation round, while giving each specialist a new bounded assignment for that round.

On resume, inspect the investigation first. Treat its pre-authorization specialist_board as a structural redacted marker only: board existence plus status and member_count; a static chair description may also appear. If that marker says a board exists, do not call genomilab.form_specialist_board again. Renew current-session authorization through the flow below. After private_context_status is approved_for_session, inspect again; only then read and reuse the full specialist IDs, roles, tasks, and current-work states, and reconstitute the corresponding native subagents if the host requires it.

The chair alone owns the patient conversation, authorization, all private AGI reads, and canonical plan, hypothesis, gap, and brief commits. Give specialists public questions or only the minimum approved evidence needed for their task. Specialists return their analysis to the chair; they never read the AGI directly, interact with the portal, request patient approval, or commit the canonical investigation artifacts.

Call genomilab.report_specialist_progress with the current round_id only at meaningful work milestones, using working, blocked, or completed and a short current_work label. GenomiLab derives the initial assigned state. Do not send raw agent messages, chain of thought, token streams, native task IDs, or per-call chatter. The portal monitors only these committed board milestones.

When a specialist returns, use genomilab.record_specialist_report to commit that round's findings and gaps with exact evidence and profile anchors. A specialist report is traceable synthesis, not a new evidence record or a clinical conclusion. Commit all assigned reports before starting another round.

One investigation authorization

Call genomilab.prepare_authorization after the patient profile contains the facts needed for the question. The portal presents the exact selected profile slice, current genome scope, and current underlying-agent destination. Give the patient the portal launch link returned by that call: its one-time token targets the exact signed candidate, while the candidate itself remains redacted from the agent-facing result and URL. Do not prepare another candidate merely to display the review. For an existing investigation in a new agent session, omit observation_revision_ids to renew the pinned profile, AGI, scope, and purpose without silently expanding to newer profile facts. Use genomilab.record_patient_observations for an intentional context update. Each local stdio MCP initialize handshake is a new GenomiLab agent session. It closes the prior session's private authority even if the host reports the same client name and version, so do not reinitialize the stdio MCP connection mid-investigation. HTTP MCP initialization is public-tools-only and cannot create or replace the private GenomiLab runtime.

The agent must not approve this candidate. Ask the patient to review it in the portal, then poll with genomilab.inspect_investigation. Continue when private_context_status is approved_for_session.

Do not request another approval for routine local planning, evidence work, hypothesis updates, or brief publication. A new patient approval is appropriate only when the profile or genome snapshot/scope changes. Exact external-provider egress can require a separate just-in-time portal approval.

Plan and execute

Read capability_catalog from genomilab.inspect_investigation. Submit only requests that are currently advertised as available:

{
  "investigation_id": "investigation-...",
  "focus_question": "What does the approved profile establish?",
  "specialist_assignments": [
    {
      "specialist_id": "specialist-timeline",
      "task": "Reconstruct the approved clinical timeline"
    },
    {
      "specialist_id": "specialist-evidence",
      "task": "Review relevant public evidence"
    }
  ],
  "requests": [
    {
      "id": "profile-review",
      "capability": "investigation.project_profile",
      "parameters": {}
    }
  ]
}

genomilab.submit_plan validates and accepts the exact requests under the active investigation authorization and requires the specialist board to exist. Each accepted plan version is one immutable investigation round. Supply one focus question and exactly one assignment for every persistent specialist. The chair submits the canonical plan. Do not invent capability parameters or resend modified parameters to execution. Call genomilab.execute_request with only the investigation and request IDs.

When the approved genomic scope advertises genomi.variant.find_gene_variants, the phenotype specialist may return a bounded candidate set to the chair, but the chair alone submits and executes the request. Use 1–10 canonical gene symbols, the exact AGI/build fields shown by the catalog, and candidate_set_lineage naming that persistent specialist plus the exact current profile/evidence anchors used. GenomiLab fingerprints the actual set and lineage in the committed personal-genome evidence. Do not give the specialist the AGI result or direct genome access.

When a request returns:

• completed: inspect the new investigation state and continue.
• in_progress: call genomilab.check_request with the same request ID.
• approval_required: show the portal link and ask the patient to approve the exact external disclosure there. Do not add an approved argument yourself.
• source_unavailable or an unavailable capability: state the evidence gap; do not treat it as negative biomedical evidence.

Re-inspect after evidence commits. The capability catalog may then advertise new exact disease-relation, hypothesis, or gap templates. Submit a new bounded plan when later synthesis depends on those newly available records.

Publish the investigation response

Use the hypothesis and gap capabilities advertised by the investigation catalog. Preserve source priors and cite the exact profile and evidence anchors. Use supersedes_hypothesis_id when revising an existing hypothesis.

Read brief_authoring.brief_schema from the latest authorized genomilab.inspect_investigation result. Build the brief argument from that exact context-bound schema and the published investigation records. Omit modality_badges; GenomiLab derives them from the cited records. Then call genomilab.submit_brief. Treat the returned investigation_response as the durable research record; answer the patient conversationally in the current host task. Keep all health language informational and preserve the required clinical boundary. Build timeline from exact evidence/profile anchors and write case-specific clinician_questions with their motivating evidence, profile, hypothesis, and gap identifiers; do not substitute generic canned questions. The portal can print the current brief or download a self-contained HTML copy for the patient to take to a treating professional.

Patient follow-up and revision

When the patient supplies additional information in the current conversation:

1. Call genomilab.record_patient_observations with the same investigation ID. Each observation needs at least modality and label or original_wording. Use patient wording and patient-reported provenance.
2. For a correction, include supersedes_observation_revision_id on that one observation. Otherwise record a new observation.
3. Ask the patient to approve the returned context delta in the portal once.
4. Re-inspect after approval. Replan and rerun only evidence affected by the changed context.
5. Register a revised hypothesis with supersedes_hypothesis_id, then publish brief version 2. Explain what changed and what did not.

Keep the same host task and investigation ID throughout this flow.