GENOMELENS / BUILD NOTES
Where does the agent belong?
Building GenomeLens: a local data workspace with a deliberately narrow role for AI.
- My role
- Personal project · Design & development
- Status
- Working prototype · In development
- Period
- 2026
The problem
A large genome file is difficult to explore directly. A conversational interface looks convenient, but it creates a design question: does the model need the data, or does it need a small set of ways to ask questions about it?
GenomeLens is my experiment in that distinction. It is a research and education project, not a clinical product. The aim is to make data inspectable while keeping the model’s responsibilities narrow.
The constraints shaped the architecture
The data stays in a local database. Importing, counting, filtering, and looking up coordinates are deterministic operations. An agent can select bounded, read-only tools and explain their results; it does not replace the underlying queries.
That separation is also useful without a model. The local web workspace supports dataset summaries and coordinate or region lookups directly.
Three choices that matter
1. Put the data path first
The first slice validates and streams a single-sample VCF file into DuckDB. Normalisation and retrieval have explicit contracts. A dependable query layer is useful before any conversational feature exists.
2. Give the agent a smaller surface
The model works through specific tools with bounded inputs and outputs. This makes it possible to inspect which operation was requested and whether the returned facts support the explanation.
3. Keep external evidence a separate decision
Looking up a public reference is a different capability from inspecting a private dataset. GenomeLens keeps that capability behind an explicit permission boundary. The local web workspace leaves remote models and public evidence off.
What I built
The project includes the local import and query pipeline, read-only tools, an agent runner, synthetic evaluation cases, and a web workspace for inspecting results. The evaluations check tool calls, required facts, inappropriate claims, and privacy boundaries. They use synthetic fixtures.
What exists today
There is a working local prototype. The interface supports importing a file, summaries, exact and regional queries, and a local tray for interesting variants. The interface and agent runner are separate surfaces at this stage. There is no hosted public demo here.
This is an implementation milestone, not evidence of clinical usefulness or a measured improvement in model reliability.
The useful lesson
Choosing the agent’s tools is part of designing the product. The question is not simply whether a model can answer. It is whether the system makes the answer traceable, keeps access limited, and remains useful when the model is absent.
← Back to workWhere does the agent belong?
- 01Local data
- 02Deterministic queries
- 03Bounded agent tools
Clear inputs. Limited access. Inspectable results.