Building a Research OS with Django and Agentic AI: A Visual Guide to Talk Python Episode 560

The MUSIC study started in 2020, in the middle of COVID, which had already hit both hospital and research operations hard. The plan was to recruit about 200 people with IBD from three cities and multiple hospitals, and follow each of them up every three months. At every visit, the team would take extra blood, stool and saliva samples to run experiments on and work out what the immune system was doing.

Shaun, still in his registrar training, sat down and did the arithmetic: two hundred people, a visit every three months, three sample types per visit, over a couple of years. That came to roughly 30,000 samples.

So how do research teams normally keep track of that many? He asked everyone around him, and the answer was Microsoft Excel. Which is exactly the answer you'd fear, isn't it? How big does that workbook get, and how many tabs does it have?

Why not buy something proper? Most research teams don't have a lab system at all. The enterprise options are expensive to buy and, by Shaun's estimate, take something like six months to set up. They're also built for hospital operations handling millions of samples, not a one-off study spread across lots of different places. He looked at a few off-the-shelf options and none of them fit. So he bit the bullet and decided to write a web app in Django.

The first version was plain and practical. Print a QR code, stick it on the sample label, and scan it to register the sample in the database. When a sample moved between sites, scan it again and the record updated. Shaun calls it "nothing too amazing", just a basic operational problem that needed solving.

Nobody set out in 2020 to build a research operating system. The goal was a sample tracker that beat a spreadsheet, delivered inside a study with roughly a two-year window. The bigger platform grew out of it later, once the samples started turning into data.

“A simple back of the envelope calculation came to about 30,000 samples that we were going to generate over a couple of years.”

Shaun Chuah

Shaun is candid about where he started. He wasn't much of a programmer: he'd written websites in high school, typing the HTML tags by hand in Notepad, and later used R or Python scripts to make graphs for statistics. Going from that to a production web app for a multi-site clinical study was a big stretch.

So why Django? When he first visited the Django website, its tagline was "the web framework for perfectionists with deadlines", and he says that described his situation exactly. The study had about two years to deliver, and there was no time to spend forever on infrastructure.

The deeper reasons had to do with risk. In 2020, Django stood out as mature and batteries included. As a non-programmer handling patient data, Shaun wanted an authentication framework that was already battle tested, and built-in database migrations so the schema could change without losing anything. Those two alone persuaded him - "we haven't even come to the admin dashboard," as he put it. The admin was a bonus, not the reason.

How do you learn all that from scratch? Shaun credits the Django docs and tutorial, YouTube, this podcast (he's listened for five years) and a lot of books: Two Scoops of Django, Obey the Testing Goat for test-driven development, Martin Kleppmann's Designing Data-Intensive Applications, and later Ralph Kimball's The Data Warehouse Toolkit once the project became a data problem. His case for textbooks is that they give you the fundamentals as a whole, so you don't end up with gaps. Michael, who came to programming from math and research software himself, pointed out that self-taught developers often have exactly those gaps around data integrity and things like foreign key relationships.

The steepest climb, though, was going from localhost to production. Production means reliable, secure, accessible infrastructure with backups, and it meant learning Linux from a terminal. What made it manageable was CI/CD: GitHub Actions deploys continuously, so a fix reaches production in minutes instead of by hand. Michael argued that CI/CD is valuable for beginners, not only for big teams, since being able to push to GitHub and have the new version live takes a lot of intimidating complexity out. Shaun added that every time he teaches someone the terminal, he's reminded what a big jump the command line is for most people.

One piece of Django news came up too. Michael noted that Django is moving to yearly releases with calendar versions, every one of them long-term support, which should make the versioning simpler for newcomers to decipher.

“You want your authentication framework to be battle tested. Database and migration is incredibly important. You can't lose any data.”

Shaun Chuah

Tracking the tubes was the operational problem, and the harder one came right after it. Every sample eventually goes into an experimental pipeline, and what comes out the other end is data. Stool samples become microbiome data. Blood samples become genomics data. Every data type comes back in its own format, and some of it is very large.

To make this concrete, take Shaun's own research project from that time: sequencing cell-free DNA, the fragments of DNA floating around in the blood. Each participant's sequencing file was about 5 to 10 gigabytes of gzipped FASTQ, which then had to go through a bioinformatics pipeline. That wasn't run on all 30,000 samples, only on a subset of participants. Other assays, like genotyping, covered the whole study population. There are a lot of moving parts, and each one has its own little details.

So how much data is there? About 10 terabytes today. And that's with only a fraction of the 30,000 samples processed, because some pipelines take a person 12 hours to get through a couple of samples. There's a lot of work still ahead.

Before the platform, that data was scattered. A microbiome project lived on someone's laptop. Other data sat on a shared drive on a university file server. Someone running a specific experiment might make an Excel file of the readings, and that file was the dataset. Shaun sees that scattering as one of the big problems in biomedical research today.

It's going to get harder, too. Shaun pointed out that some newer technologies produce about a terabyte of data for a single sample. Michael raised the reproducibility angle: you can stamp a paper with the Excel file, the Parquet file and the Docker image it was built from, but at 100 terabytes, simply keeping it around is the hard part.

Which data is worth keeping, then? Shaun's view is that you may not need the raw files at all if you keep the processed ones, since "who wants to run another 100 terabyte pipeline anyway?" Grants usually cost data storage for 10 years, and beyond that it's an open question with no easy answers. Michael noted that storage has generally got much cheaper, though not over the last year and a half, and Shaun suspects the AI boom may not let that falling price curve continue as before.

“Some of the newer technologies are generating like a terabyte of data for a single sample.”

Shaun Chuah

How do you put endoscopy videos, MRI scans, digital pathology slides, genomics output and spreadsheets of clinical readings into one common model? Shaun has spent years on that question, and the answer his team landed on is almost disappointingly simple. All data exists as files.

That includes tabular data. They've tried loading tables into the database in the past, but going forward they keep it as CSV. Each type of data has its own file structure, but files are the universal denominator. What makes the files useful is the layer of metadata and relationship data the platform keeps on top of them. Coupling the two gives a model that generalizes across every dataset they handle.

Michael pointed out that tools like DuckDB and Parquet already let you treat files like databases, and asked about embedded databases like SQLite. Shaun said they use Parquet too, and that SQLite is an interesting idea, a whole database in a file. But his end users are scientists who live in Excel and CSV, so the team keeps the formats everyone already knows. There's a second payoff he called out: if everything's a file, an AI agent can run across all the files and pull out the data it needs.

The files live in Azure Blob Storage. That's a big change from the university setup, where you'd get a quota on a shared drive, maybe a terabyte, and have to email someone in IT to get it raised. With blob storage there's no hard limit, just a bill at the end of the month. Michael summed it up as "You have a bill instead of a limit."

Are limits all bad? Michael has a story about that. In his university days, the whole math research department shared a Silicon Graphics machine with no quotas. A grad student chasing a bug added logging, accidentally got the code into an infinite loop and left it running overnight. By morning, the machine wouldn't respond. The log had filled the hard drive to the very last byte, the operating system needed a few temp files to run, and it took a day or two to bring it back. Nobody had ever set a quota. Yikes!

“So we put files, and the thing that makes the files useful is putting a layer of metadata and relationship data on top of the file.”

Shaun Chuah

"AI" means two or three different things, and people often talk past each other because they use the same word for all of them. Michael's example: one person says they asked ChatGPT a math problem and it got it wrong. Another says they built serious software with something also called AI, which gets the math right because it writes Python to answer the question.

Helix, the assistant inside Foundry120, is firmly in the second camp. It's an agentic AI system, closer to Claude Code or Codex than to a chat window. Shaun's description of the paradigm is short: you give the AI a task, it looks at its tool set and at what you're trying to do, and then it goes away and works until it has an answer.

Why the confusion? Most people's experience of AI is a chatbot. You go to ChatGPT, ask a question and get an answer. Shaun estimates that 95% of people's experience is almost like a Google search: directions to a place, a recipe for something. That leaves a huge gap in understanding how capable agentic systems can be. In his view, the agentic work is what makes people like him think AI might not be a bubble at all.

How does Helix know about the research data, then? Was the model trained on it? No. Michael asked whether they retrain a model on the research files, and Shaun said they use tools to ground the AI instead. They don't train the AI for Foundry120 at all. Supervised fine-tuning or reinforcement learning on a base model costs a lot of money, and you need training data, which isn't easy to make either. Michael added that it doesn't generalize. Given how fast the big labs are moving, Shaun wants to be able to swap in the latest base model as each one comes out and get the improvements for free.

So the model does the reasoning, while the tools query the real database and run real code. The next section shows what that loop looks like on an actual question.

“In agentic AI, you give the AI a task, it looks at its tool set, it looks at what you're trying to do, and then it goes away and works at it until it gives you an answer.”

Shaun Chuah

Here's the kind of question a research team asks all the time. A colleague wants to know: do we have any samples from a participant who's been treated with a particular drug? Historically, someone took the clinical dataset, joined it with the sample database by hand, filtered the result and found the samples. That usually took a couple of days. For Shaun, it's a great use case for an agent: pull the data into a sandbox, write the code to do the join, and hand back the answer.

The one-minute screencast on the Foundry120 site shows two questions like that. The first asks what plasma samples the team has for the MUSIC study, broken down by disease group. To answer it, Helix has to join the clinical data frame with the sample database, work out which samples are unused and what type they are, then inspect the clinical data to see what disease groups exist before grouping. In the demo, it comes back with roughly 4,000 samples from people with Crohn's disease and 2,000 with ulcerative colitis.

Watching it, you see a rhythm: a tool call to get samples, a pause, some Python code to transform the result, then more data access and more code. Michael's point was that it isn't reading 100 terabytes of data. It can't: as Shaun put it, "you can't read all that data because the context window of your AI is limited." Instead it orchestrates tools and code it already knows how to write.

The second question asks for a plot of CRP, a common blood test for inflammation, against cell-free DNA, an experimental output. That means finding the clinical data, joining it with the science data and writing matplotlib code to draw the graph, along with a summary of what it found. Partway through, Helix hits an error. It reads the tool's output, corrects its approach and carries on. Shaun offered that as a demonstration of what an agentic system looks like.

The tools themselves are deterministic, and Shaun says designing them is one of the hardest parts of the whole system. How many tools do you expose? What should each one do? What makes a logical set, and how do you make sure the AI picks the right one? He calls tool design a huge topic in its own right.

“The tools are deterministic. And actually designing the tools is one of the most challenging things to do”

Shaun Chuah

Why go to all this trouble over permissions? Michael has a story that makes the case. He was working with Claude on some code, and it mentioned that he had two GitHub issues about the problem. He'd never given it access to GitHub. So how did it know? It had noticed the GitHub CLI was installed and already authenticated, because Michael had logged in at some point, and it simply used it. Later it offered to check something on his production server for him, having worked out from the code that it could SSH in. His reaction: "These AIs are sneaky. They will find a way to access the files."

He was careful to say they aren't malicious. They're trying to solve the problem you gave them, and more concrete data means a better answer. But the same eagerness could just as easily end with "we fixed the problem by resetting the database." Oh no, you didn't.

Now put patient data behind an agent like that. Foundry120's answer is to make Django the only door. Django enforces the permissions on the back end. When Helix wants to stage data or run code, that request goes through Django first. The AI never calls directly into the files or into a compute environment. Shaun describes it as putting Django in as a security guard between the AI and the raw data.

Because Helix's tools run on the back end rather than inside the model, the same role-based access controls that apply to a person apply to the agent. When a team member asks Helix a question, it can only see the files that person already has access to. That's a design choice driven by the governance rules around their data, and it's what lets Shaun say the security around data access is solid.

That lesson applies well outside medicine. Guardrails for an agent have to be enforced in your own code, outside the model, not by asking the model nicely to stay in its lane.

“So we've actually put Django in as a security guard between your AI and the raw data and the compute environments”

Shaun Chuah

So what actually happens when Helix wants to run an analysis? The flow has a few clear steps.

1. The files live in Azure Blob Storage.
2. When Helix wants to process a file, the request goes through Django, which screens the staged code and activates a virtual machine.
3. The file is transferred from blob storage into that VM.
4. The AI sends its analysis code into the VM, whether that's Python or another language, and the computation runs there.
5. The output goes back to Helix, and the results are stored back in blob storage.

Why build it this way? Partly for security: the VM puts a sandbox guardrail around the agent, so AI-written code runs against a copy of the data inside a fenced-off environment rather than on the storage or servers themselves. But it also lets the AI do real work. It can process data, generate new files and store them, all while everything stays inside the university's own Azure environment.

To be precise about the claims: Shaun described the sandbox as a guardrail and a design that fits the governance requirements on their datasets. He didn't describe it as a guarantee of zero risk, and the US health privacy law HIPAA came up only as Michael's American comparison, not as something Foundry120 claims.

The same machinery scales up. A small join runs in one VM, but a heavy genomics job can fan out across many machines, which is where the next section picks up.

“So by doing that, we put the sandbox guardrail around the AI agent for security purposes.”

Shaun Chuah

Universities used to keep a Cray or two in a basement, and anyone who needed serious computing got time on it. Michael remembers that from the 90s. Now the limit is mostly how much cloud capacity the university will pay for.

Some universities still build their own clusters, but Shaun thinks the economics favor the cloud by a wide margin. Why? Because so much university analysis is a one-off. You might process a huge dataset once, and then it's a year or two before you have that much to process again. Michael agreed. Hardware in a basement pays off for a steady workload, and research computing isn't steady.

AI makes the case stronger. Shaun noted that a single rack from NVIDIA costs a couple of million dollars, and you need a power plant to plug it into. He can't see universities building their own AI data centers, so in his view cloud adoption is inevitable. The exception is studies with specific governance requirements, and even then he'd expect a local AI company to run it and share it between businesses and universities, rather than each university going it alone.

The pair also speculated about the other direction. Michael wondered what happens if a $100 a month AI subscription became $2,000 a month: suddenly a $10,000 workstation that can run serious local models looks like a bargain. Shaun agreed there's a role for local AI, since small models keep getting more capable and not every workload needs a frontier model.

Foundry120 itself bursts. Michael asked whether something like Pyodide or JupyterLite could run some of the computing in users' browsers to save on server costs. It doesn't fit here. Files run to gigabytes, and genomics pipelines need lots of CPU and RAM. Foundry120 has access to about 350 CPUs on Azure. Ask Helix for a heavy analysis, say on a big transcriptomics dataset, and Django orchestrates a compute job that spins up as many CPUs as it needs. It might take half an hour or a couple of hours and report back when it's done.

Many biology problems are naturally parallel. With 200 participants at 5 gigabytes each, you might as well spin up 200 machines, process everything at once and tear it all down. Shaun's summary: "minimal cost for, you know, maximum impact."

There's one more reason to keep the computing on the server. Sample collection runs in hospitals across Scotland, where front-line IT isn't always the best. Shaun has used hospital computers that go back to 2010. A server-side app keeps things fast regardless.

“I can't see any university building their own AI data center in the future.”

Shaun Chuah

The original sample tracker was pure Django. Django templates handled registration and the create, read, update and delete workflows that a sample tracker is mostly made of. For that job, server-rendered pages were a good fit.

So what changed? AI. Shaun's reasoning is that AI is asynchronous by nature. Every model call takes a while to come back, sometimes what feels like forever, and an agent loop strings many of those calls together. A registration form is one request and one response. An agent conversation is many calls in a row, each with a wait that's hard to predict, and the screen has to stay responsive the whole time. In his view, TypeScript and JavaScript tend to suit that kind of interactive, async-heavy application better.

So Foundry120 now runs both. The front end is TypeScript and React. The back end is Django, exposed through Django REST Framework. Shaun calls it a great setup, because it gives the team the entire Python data science ecosystem on the server and the whole TypeScript and JavaScript ecosystem for the interactivity on the client.

Notice what stayed the same. Django still owns the data, the permissions and the orchestration of compute jobs, which is exactly where the earlier sections put the guardrails. The new front end changes how people talk to Helix, not who gets to see what.

“It gives us access to the entire Python data science ecosystem, while also giving us all the TypeScript and JavaScript ecosystem for handling all these asynchronous work”

Shaun Chuah

If you've read this far, you've seen governance shape almost every design choice. Here it is head on.

Foundry120 runs on the University of Glasgow's Azure tenancy. For their studies, data has to sit in specific places: most workloads run in the UK South data center, and EU-compliant work runs in Sweden. All AI inference happens inside Microsoft Azure, under GDPR-compliant controls. Shaun explained that because Azure's platform controls let them guarantee where everything happens, they can let the AI operate on the data safely.

That's also the answer to an obvious feature request. Michael asked whether they'd thought about an MCP server, so people could ask their own AI tools what Foundry says about something. Shaun finds MCP interesting, but governance is the limiting factor: the team isn't allowed to put data into Claude Code and send it across to Anthropic. Michael pointed out that GDPR matters to US companies too, if they have European customers.

Governance also explains why you can't just sign up. The platform is early stage. Over the last six to twelve months, the team has made the foundation general enough to work beyond Shaun's own group and beyond IBD, which meant building team management and permission assignment so a new group doesn't need Shaun to do it for them. Onboarding is still hands-on, though. It depends on what data a team handles, how much of it, and which kinds. And clinical research has strict rules about how data is handled, where it can sit and where it can be processed, all subject to each study's research ethics approval. The team wants to review all of that for compliance before anyone joins. Michael compared it to the IRB approvals and HIPAA rules researchers deal with in the US.

So instead of a monthly subscription, the Foundry120 site offers a platform walkthrough. Shaun says they're willing to do that review work to bring other teams on.

“we are not allowed to just put data into a Claude Code and send it across to Anthropic”

Shaun Chuah

Every new member of Shaun's team used to sit down with him to learn enough Python or R to get a graph out of an Excel file. Now they can hand that job to Helix and let it write the code. So the job changes. Instead of writing the analysis, the researcher checks that it's correct.

Can you trust the results? Shaun's answer is careful. He hopes reliability will go up over the coming years, but coding agents aren't 100% reliable today. Even the best models, he named Opus and Fable, still make mistakes. In his words, "we're not quite past the reliability threshold yet." That makes understanding what you're trying to do more important now than it was five years ago, because you need that understanding to supervise the AI at all.

Michael offered the other side. The alternative is a person doing the work, and people aren't 100% reliable either. He pointed to a recent dust-up over an AI tool used to pre-screen patches for the Linux kernel: some people didn't want to use it, and the response was that it's at least as good as the people often doing that job. His theory is that because it's a computer, "people expect it to be perfect." Software is usually deterministic: if it works once, it always works. AI isn't like that. But then, people aren't either.

Shaun likens an AI to a colleague on your team who writes code much faster and better than most people. He says Claude Code and Codex already write code faster and better than he does. But the human still supplies the strategic view and has to drive and direct it. He gives his scientific colleagues the same rule for Helix: the answers that come back need to pass the smell test. If you expect a number of a certain magnitude, check that you got one, because "sometimes the AI goes off and does funny things."

How much checking is enough? Michael suggested asking the AI to verify its work and write code to back it up, and treating it with the same healthy skepticism you'd give a colleague or a grad student. No professor sends a grad student's paper off to a journal without reading it. Shaun draws the line by stakes: "for disposable stuff, you can let the AI do more of that," but for critical workflows, you want to make sure every single step is correct.

“So instead of you as a researcher writing the analysis code, You get the AI to do the analysis for you. And then what you have to do is verify that it is correct.”

Shaun Chuah

Shaun describes Foundry120 as three ideas stacked on each other, and each one leans on the one before it:

• Organize. Samples, studies and participants go into a Django database, chosen for battle-tested authentication and migrations that don't lose data. See why a self-taught doctor chose Django.
• Centralize. Every data output, from endoscopy videos to sequencing files, lives as a file in Azure Blob Storage with metadata on top. See everything is a file.
• Operate. Once the context sits in one governed place, an agent can work on it. Helix writes and runs code in sandboxed VMs, behind Django's permissions. See how Helix answers questions and keeping an AI agent away from data it shouldn't see.

The order matters. The agent is only useful because the data was organized and centralized first, and it's only safe because the permissions live in Django rather than in the model. Even then, the answers still need a person to check them, as covered in from writing analysis code to verifying it.

Where does this go next? Shaun is optimistic, but grounded about it. Drug discovery is a very long process, and he thinks agentic AI has a real role in shortening some of its bottlenecks. He expects it to change how science is done and how clinical work operates. But in his view the real world is going to take a while to catch up to where the capabilities are today.

The gap is mostly about exposure. Most people listening to a Python podcast have used a coding agent. As Shaun put it, "almost everybody else in the population has never touched a coding agent." When he demos Helix to scientists, it's often the first agentic system they've seen. Their reaction is excitement: things that used to take them months, or a long chain of emails, now take minutes. There's still a lot of teaching ahead - how to use these systems, what they can do, and where their limits are.

What about Foundry120 itself? Shaun is open that they don't yet know whether it generalizes to other teams, or whether it stays hyper-personal software for his own group. Either way, he has shared the principles widely and is happy for other institutions to build their own systems from them. If you'd rather explore a partnership, Foundry120's website is the place to start, and Shaun's own site has his email, his GitHub and the writing about his journey into coding.

If you're a Python developer who has used these tools, you may be well placed to help the scientists, clinicians and researchers around you see what they can do.

To build the pieces yourself, Talk Python Training's Django: Getting Started covers the authentication and migrations that won Shaun over, plus models and the admin. Agentic AI Programming for Python is about working effectively with coding agents like Claude Code and Codex, and LLM Building Blocks for Python covers programming against LLMs from Python, including tool use, the foundation of an agent like Helix.

“So please feel free to just take the idea and run with it.”

Shaun Chuah