Topic Selection: Operating Systems × AI

Everything produced while narrowing from "operating systems and AI" to a specific thesis topic. This is the phase that happens before guide/01-scoping.md — you cannot write a falsifiable thesis statement until you have a topic worth making a claim about.

Literature verified 26 August 2026. Crowdedness decays faster than any other content in this repository. The root README declines to ship a reading list on the grounds that a stale bibliography is worse than none, and that concern applies here with force: agent-systems work in particular moved from an open field to a contested one in roughly six months. Treat every crowdedness verdict below as accurate on the date above and as a lower bound thereafter. Re-verify anything you are about to build on.

What is here

There is also an interactive version of the topic catalogue as a Cursor canvas at ~/.cursor/projects/Users-fadyyassa-Desktop-Masters/canvases/OS-AI-thesis-topic-guide.canvas.tsx. It scores topics against your constraints — compute, kernel depth, ML depth, time budget, publication ambition — and re-ranks as you change them. The markdown here is the portable record; the canvas is the tool for exploring trade-offs.

The one finding that matters

Of thirty-seven candidate topics checked across two passes against 2024–2026 proceedings, two rate as open, and both of those ratings rest only on absence of search hits. The rest are closed in their original framing or merely active.

This is the honest state of the OS/AI intersection in 2026: it is the most heavily worked area in systems, and industry labs with clusters are publishing in it continuously. Nothing in that sentence should discourage you, but it does dictate a method.

Every surviving opportunity has the same shape: not an unexplored problem, but a limitation an incumbent system states out loud and declines to fix.

That maps directly onto the gap taxonomy in guide/01-scoping.md. Almost every live option here is an unvalidated assumption or an unmeasured cost — not an unexplored regime. Which is convenient, because those are the two stronger kinds of gap.

The second pass added a wrinkle worth knowing about in advance. In 01-candidate-topics.md, the limitations were stated in papers' limitations sections, so you can cite them. In 04-new-candidates.md, most are stated in merged upstream code, kernel documentation, and mailing-list threads instead — Clang's context-analysis docs saying outright that it "does not infer context locks," khugepaged's maintainers disabling a tunable rather than fixing its failure mode. That is a stronger gap in one sense, because nobody can dispute a conceded limitation. It is weaker in another: there is no citation, you must measure the incumbent yourself, and the reviewer's objection shifts from "this is done" to "this is a tuning problem." Prepare for the second objection, not the first.

The practical consequence is how you pitch. "I want to work on agent sandboxing" invites your advisor to name three systems that already do it. "Santa and every tool like it assumes a stationary workload, and agent-generated code is not stationary" does not. Pitch the limitation, never the problem.

How to use this

1. Write down your constraints before you read the topics, not after. Compute you can rely on for the whole thesis, the kernel and ML work you can already do competently, your advisor's area, calendar time and whether it is full-time, and the shape of result you would be satisfied defending. Every topic here is gated on those five, and reading the catalogue first invites you to fall in love with something you cannot execute.
2. Read 01-candidate-topics.md and 04-new-candidates.md, and pick two or three Tier 1 entries that match. Ignore Tier 3 entirely.
3. Spend two days on the relevant entries in 03-reading-list.md. You are reading for limitations sections, not for mechanisms. Write notes as you go using templates/paper-note.md.
4. Re-verify the crowdedness of your top candidate yourself before committing. This is the "spend a deliberate afternoon trying to kill your own idea" step from guide/01-scoping.md, and the reports in reports/ tell you which vocabulary and venues to search. For anything in the agent lane, start with both AgenticOS programs.
5. Then move to guide/01-scoping.md and write the one-page problem statement. The two files in proposals/ are worked examples of what that document looks like.

Retracted: the note on the two agent-lane topics

An earlier version of this file recommended building a corpus of instrumented agent runs, on the grounds that it served two Tier 1 topics at once and would decide between them on evidence. That recommendation is withdrawn as of the second pass on 26 August 2026, because one of the two topics is gone: rollback of escaped effects is claimed by Externalization Barriers at AgenticOS @ SOSP 2026. With one topic left, the corpus no longer decides anything, and building shared infrastructure for a single destination is just a longer path to that destination.

The underlying advice was sound and the reason it failed is worth keeping. Infrastructure that serves two candidate topics is genuinely valuable — it converts a taste decision into an evidence decision, and it is a measurement contribution in its own right under Angle C. It is also a bet that both topics survive the eighteen months between your reading it and your defending. In this area, over six months, one of two did not.

What the two proposals assume about you

proposals/ contains full problem statements for two options, and they are not neutral documents. Both were written against a specific profile: shared-cluster GPU access with real queue time, eBPF as the only kernel skill already in hand, an OS/kernel advisor, roughly twelve part-time months, and a publication at a decent venue as the goal.

That profile drives their conclusions, and two of its consequences are worth stating because they are counterintuitive. First, the cluster is a liability rather than an asset — every topic that would use it needs exclusive, uncontended GPU time for tail-latency work, which shared-with-queue-time cannot supply, so both proposals deliberately choose topics where a single laptop is the correct platform. Second, twelve part-time months is roughly six full-time-equivalent, which eliminates every twelve-month entry in 01-candidate-topics.md regardless of merit.

If your constraints differ, the ranking changes and possibly the shortlist does. Re-derive it rather than inheriting it.