AI Orchestrated IntelliLab — Project Story

Inspiration

The idea did not come from a whiteboard. It came from a Tuesday morning.

We work in an active aerospace research laboratory running experiments in flapping-wing aerodynamics, flow imaging, and CFD campaigns on shared GPU servers. On that Tuesday, three things happened simultaneously: a junior student could not set up their Python environment for post-processing, a lab instrument's calibration record was missing from any centralised location anyone could find, and a senior researcher needed a specific paragraph from a paper indexed months ago but could no longer locate.

None of these problems were hard. Together, they consumed nearly four hours of collective lab time.

We had already been experimenting with locally-deployed AI assistants — open-source LLMs running on lab GPU servers through Ollama, with a RAG pipeline backed by ChromaDB. These tools solved problems for individual researchers. But they did nothing for the lab as a system.

That gap — between a powerful AI tool available to one person and a zero-overhead intelligent system available to the entire lab — is what inspired IntelliLab. The deeper motivation is structural. A research lab is not just a collection of computers. It is a cyber-physical system: instruments, people, experimental data, knowledge, and institutional memory are tightly coupled. When that coupling is managed by email threads and shared folders, the lab runs below its potential. When it is managed by an AI that understands every layer of the lab simultaneously, the science can accelerate.

What It Does

AI Orchestrated IntelliLab is a concept and interactive demo for a locally-deployed, privacy-preserving AI ecosystem that replaces the fragmented tool landscape of a research lab with a single intelligent platform. The demo illustrates five interconnected modules:

1. Projects — AI-Agentic Research Management

Each ongoing project is paired with its own AI agent retaining the project's context: files, experiment logs, permitted directories, and summarised history. Projects are risk-classified (read-only, medium, high) so the AI exercises appropriate autonomy. A Separate Context mechanism decomposes a project into focused sub-threads — literature review, documentation, code history, experimental figures — each isolated but linked to the parent project.

2. Literature Study — Grounded Research Discussion

Researchers pose questions to the AI against a corpus of ingested lab documents. The system is RAG-grounded: the AI reasons only from what is indexed, not from general knowledge. Prior discussions are persistent and resumable — solving one of the most underappreciated problems in research labs: institutional memory loss at graduation.

3. Lab Resources — Agentic Physical Asset Management

Every physical and computational resource in the lab has a live status card: GPU queue depth, NAS storage utilisation, instrument calibration validity, SOP currency, software license seat count and renewal countdown. Resources can be queried individually or in combination, and the AI summarises status, identifies owners, surfaces metrics, and recommends safe next steps — in one call. Anomalies are flagged proactively (e.g., Archive NAS storage at 87% triggers a warning badge before it becomes a data loss event).

4. Assigned Tasks — Accountable Student Workflow

Tasks are created, assigned, and tracked within the platform. Students can escalate to the PI via a Draft Action workflow. Every handoff, request, and assignment is logged with a timestamp and attribution.

5. Logs — Full Audit Trail

Every action — agent query, storage check, license review, discussion note — is timestamped and attributed to a user account, giving PIs visibility without micromanagement and giving students a verifiable contribution record.

The Underlying Compute Argument

The structural argument behind IntelliLab is that centralised AI-orchestrated compute eliminates the heterogeneous workstation problem. Instead of each student installing and maintaining their own toolchain on machines of varying specification, a single server handles all compute and environments while students access it through a browser. The economics are straightforward:

$$C_{\text{conventional}} = n \times C_{\text{workstation}} + T_{\text{setup}} \times w$$

$$C_{\text{IntelliLab}} = C_{\text{server}} + n \times C_{\text{thin client}} + \epsilon_{\text{maintenance}}$$

For a 10-student lab, the cost crossover is immediate and the capability gap widens as models scale.

How We Built It

IntelliLab at this stage is an interactive demo built for the hackathon using Codex, designed to faithfully represent the intended user experience and system architecture — not a fully functional deployed system.

The demo was designed screen-by-screen to walk through every module a real lab user would encounter: sign-in, project management with sub-contexts, literature grounding, agentic lab resource status, assigned task tracking, and per-user audit logs. The UI reflects actual design decisions we intend to implement — dual role views (Researcher / PI), risk-level tagging on projects, live status badges on lab resources, and a palette chosen for legibility in lab environments.

The conceptual backend architecture — local LLMs served via Ollama, ChromaDB for RAG, Flask + Socket.IO for the web layer, per-user quota management, and a structured lab resource registry — is grounded in real prior work with locally-deployed AI tools already running in our lab context. IntelliLab is the multi-user, full-lab extension of that foundation.

The demo makes the vision concrete and testable before committing to the full build.

Challenges We Ran Into

Funding and support are the primary barriers — and they are real ones.

Running large local LLMs on dedicated GPU hardware requires capital expenditure that falls outside typical research lab budgets. A mid-range deployment — dual high-memory GPUs, a server-grade workstation, and fast NVMe RAID storage — is a significant investment. Without a dedicated grant earmarked for this infrastructure, the system has to run on shared or borrowed compute, which limits reliability for multi-user deployment.

Beyond hardware, institutional buy-in is a challenge. Convincing a lab to migrate away from ad-hoc tools, personal cloud storage, and individual software installations toward a centralised AI-managed system requires demonstrating clear value before the system exists. The demo was built precisely to address this: to make the case visually and concretely before asking anyone to commit budget or time.

There is also the quieter challenge of proposing infrastructure at institutional scale as early-career researchers. The technical vision is clear. The pathway from a working demo to a deployed system running across multiple labs requires navigating grant cycles, procurement timelines, and administrative processes that are largely outside a researcher's control.

Accomplishments That We're Proud Of

Translating a real, lived lab problem into a concrete, demonstrable system concept — the modules in the demo are not invented use-cases; they map directly to actual friction points experienced in active research labs over years of work.
The Separate Context architecture for projects — the insight that a single project should decompose into focused AI sub-contexts, each with its own file scope and agent instance while remaining linked to the parent, came from observing how researchers actually think. It is not how most RAG systems are designed.
The Lab Resources live status layer as a design pattern — showing that every physical and computational asset in a lab can be represented as a queryable, agent-readable record, and that the AI can reason across multiple assets simultaneously to give operational recommendations, is a design contribution independent of the implementation.
Grounding the pitch in real prior work — IntelliLab is not a pure hackathon idea. It is built on top of experience with locally-deployed AI tools already in use in our research context. That continuity between what exists and what is proposed gives the concept a credibility that a from-scratch demo rarely has.
Making the economic and scientific case clearly — the cost model, the compute argument, and the connection to AI for cyber-physical systems are all worked out. The proposal is ready to move forward the moment the right support is in place.

What We Learned

A demo is not a shortcut — it is a commitment. Building the demo forced every design decision to be made explicitly: what does the PI view show that the researcher view does not? What does "risk level" mean for an AI agent? What is the right granularity for a lab resource record? These are systems architecture questions. The demo answered them before a line of backend code was written.

The hardest problem in local AI deployment is not the AI — it is the data. Even in designing the demo, the question "where does this information come from, and who keeps it current?" had to be answered for every field on every screen. The Lab Resources module's value depends entirely on someone maintaining calibration dates, SOP versions, and ownership records. A system that surfaces stale data is worse than no system at all.

Funding is a technical constraint, not just an administrative one. The choice of which models to run, how many users to support, and what storage architecture to use are all downstream of what hardware can be acquired. Designing IntelliLab with a tiered hardware roadmap — entry-level at modest cost, mid-range for full capability, full-scale for a lab cluster — was a direct response to this reality: the system should be deployable at different resource levels, not only at full scale.

Privacy-preserving local deployment is not a limitation — it is the feature. Research labs handle unpublished results, grant-pending data, and proprietary experimental methods. No cloud API should see that data. The fully local stack — Ollama, ChromaDB, Flask, on-premise GPU — is not a workaround for lacking cloud access. It is the correct architecture for the problem.

What's Next for AI Orchestrated IntelliLab

The immediate next step is converting the demo into a funded project, framed as AI for cyber-physical lab environments.

Phase 1 — Infrastructure & Core System:

Deploy Ollama + ChromaDB + Flask stack on a central lab server
Launch multi-user access for a pilot lab (10 researchers, 3 active projects)

Phase 2 — Module Build-Out:

Projects module with per-project agent context and sub-context isolation
Literature Study with full RAG pipeline on the lab's paper and SOP corpus
Lab Resources live status layer with calibration tracker, warranty alerts, and maintenance management
Intelligent storage management: per-user quotas, content-hash deduplication, automated tiered backup with point-in-time restore
Student lifecycle module: onboarding automation, skills matrix, alumni knowledge transfer

Phase 3 — Validation & Scaling:

Measure against baselines: student onboarding time, equipment downtime from missed calibration, storage incidents, query resolution time
Deploy to a second lab with minimal reconfiguration to validate the template
Publish the architecture, results, and open-source the deployment stack

The long-term goal is not a product. It is a new operational standard for research labs — one where the science is never slowed down by tooling, administration, or institutional forgetting. Every lab running IntelliLab should be able to onboard a new student in an hour, surface any piece of lab knowledge in seconds, and never lose data to a storage failure that nobody noticed in time.

The demo shows what that looks like. The work starts when the support does.

AI Orchestrated IntelliLab | Hackathon Submission