Governments are not passing legislation comprehensive enough to prevent the harms AI is already causing: threats to artists' work and to education, misinformation, job displacement, mental health impacts, environmental damage, etc. History has shown us that the most effective way to win comprehensive legislation is not small advocacy groups but a mass social movement. However, today's responsible-AI movement is fragmented and disorganized.

This project will design a plan for a mass, grassroots movement for responsible AI, with the 1960s civil rights movement as its north star. We will work on two core questions: (1) how to engage ordinary people, starting with groups already concerned about AI such as teachers, artists, and labor unions, in a foundational way; and (2) what comprehensive law the movement should fight for, with interventions for each major deployment harm that prevent harm while still allowing innovation. Ideally, we will test parts of the plan with real people before the project ends.

All that is required is strong interest in social movements of the style of the US civil rights movement, Mahatma Gandhi’s Indian independence movement, etc. 

The following may be useful, but strong interest in social movements is the most important aspect: 

• Community organizing, labor organizing, or activism experience

• Knowledge of social movement history 

• Public policy, law, or legislative drafting

• Connections to teachers, artists, or labor unions

• User research or survey design

Frontier AI safety governance runs on if-then commitments: lab safety frameworks and regulatory tiers such as the EU AI Act’s systemic-risk threshold define capability thresholds, test for them, and pre-commit to mitigations once they are crossed. This design assumes we know which capabilities to look for, that evaluations will flag them before harm occurs, and that a pause or pivot can be executed in time. In 2026 alone, one major lab dropped its pause commitment and another lab’s models broke containment during a capability evaluation.

Decision-Making under Deep Uncertainty (DMDU) is a field built for climate adaptation and infrastructure planning that designs policy for these conditions: contested causal models, no reliable probabilities, and irreversible lock-in. Its tools (Dynamic Adaptive Policy Pathways, Assumption-Based Planning, real options) have rarely been applied to AI governance.

Over three months, the team will double-code about a dozen frontier AI governance documents (lab safety frameworks, the EU AI Act and Code of Practice, California SB 53, New York RAISE Act) with a structured uncertainty codebook. By April, we expect to show which decision points in current frameworks rely on mechanisms built for much more certainty than exists, for example triggers that can only fire once a dangerous capability has already appeared, and to present one live mechanism redesigned so that its triggers are binding and fire early enough to act on. Team members will co-author a journal manuscript and a policy brief for key regulators, and we will release the coded dataset openly so the same audit can be run on new frameworks.

Because our methodology bridges AI Governance/Policy and Structured Empirical Coding / Decision Theory, I am looking for 2 to 4 motivated collaborators who complement each other across the following profiles:

Minimum requirements for all team members:

• Minimum 10 hours/week availability from January to April 2027, with reliable communication and follow-through.

• Strong analytical reading and academic/technical writing skills in English.

• Willingness to follow structured, pre-set coding criteria (rather than ad-hoc intuition) when analyzing policy and safety frameworks, and enthusiasm for co-authoring a peer-reviewed paper.

Desirable backgrounds (you only need one of these to be a strong fit):

1. AI governance & safety policy specialist (1-2 roles):

   • Familiarity with the frontier AI governance landscape: lab frontier safety frameworks (Anthropic, OpenAI, Google DeepMind), METR or AI Security Institute evaluation work, safety cases, or the EU AI Act.

   • Ability to help finalize the governance document corpus and write policy analysis connecting our findings to live debates in AI safety.

2. Systematic coding & decision/risk analyst (1-2 roles):

   • Background in a quantitative, social science, engineering, economics, or philosophy/decision-theory discipline.

   • Comfort with structured content analysis, double-coding protocols, or formal uncertainty/risk frameworks (prior familiarity with DMDU, forecasting, systems modeling, or real options is a plus, though not required).

3. Bonus / optional skills (great if at least one team member has this):

   • Data visualization / Python / diagramming: Ability to write clean Python scripts (matplotlib/seaborn) for generating publication-quality heatmaps from our coding matrices, or graphic design skills (Figma/ TikZ/vector graphics) to illustrate our Dynamic Adaptive Policy Pathway (DAPP) metro-map diagrams.

Commercialization has played a crucial role in the investment volume increase that has enabled the construction of the necessary infrastructure for the AI booms of the past few decades. 2 main factors have made up AI development labs’ valuation growth: narrow, benchmark-verifiable capability improvement on the one hand and gradual (not very striking) transformation, or inflation, of the meaning of AI automation on the other. Even independently, both would yield more favorable projections of how the scope of tasks that can be automated evolves, the latter, though, is not as thoroughly quantified and measured as the former. This project (in its more ambitious form) hypothesizes that it is a lever by which AI demand could be driven down efficiently (then tests that hypothesis quantifiably). Essentially, even without making it measurable, this project is an early response to it, contributing to collecting the first sample of empirical evidence about the phenomenon, judging by the Adjacent literature published so far.

So what exactly is “it”? To be more precise, it is the transformation of expectations from, or specifications of, distinct tasks; or differently, the creativity in utilizing assistance in general. Some ways in which it has played out so far:

• more intense ideation about genuine, pre-existing challenges that have not been solved effectively (regardless of an AI revolution occuring) but a hope to achieve that has persisted;

• concretization of poorly defined, poorly understood challenges that have been considered increasingly frequently due to increasing optimism about capabilities;

• proposition of novel challenges that are brainstormed in response to an already adopted optimistic outlook on AI functionality; etc.
  
  

Calling these purely the effects of hype glosses over the baseline agency of professionals seeking to improve their quality of work by tech adoption.

Key questions:

How do these professionals relate to the use of AI in their creative process? What positions do they take and communicate in various peer groups about their relations?

Model team member: someone on a career path in a field where AI adoption is an increasingly prevalent topic, the career stage is not of primary importance, instead any of

• openness to varied cross-disciplinary communication,

• a wide network in their respective professions,*

• nuanced, deliberate expression,

• deep technical understanding of ML applications in their fields,

• experience in psychometry,*

• interest in philosophy 

I admit to a significant lack of those marked with asterisk (*). I may bring in external co-leads who have them, though, even if just to help assess applicants. I will additionally gauge applicants’ communication on ML and what level of technical expertise that reflects regardless of their primary background. A team member can be expected to explain a ML or AIS concept in various amounts of technical detail.

We propose to map what Hong Kong's financial regulators have said about AI and evaluate their engagement with catastrophic AI risks, by evaluating their policy documents against the risk categories of the MIT AI Risk Repository. The regulators have been writing about AI since at least 2019, and the rate of output has risen in recent years, especially in 2026. The Hong Kong Monetary Authority replaced its AI principles with a new supervisory framework in October, the HKMA and the Securities and Futures Commission issued circulars on AI-enabled cyberattacks in June, the four financial regulators ran a joint sandbox for AI agents, and the HKMA published a discussion paper on agentic AI in November. Nobody so far has evaluated these documents together against a full list of AI risks.

The team will first decide which of MIT's 24 categories fall within a financial regulator's remit, then compile every document on AI issued by the regulators and read each one against those categories, recording for every match the passage concerned, how binding the document is, and whether it refers to AI directly or through a broader concept such as model risk. We will publish a report, a dataset and a one-page map of regulators against risks. The project will start with Hong Kong, so that we have a minimum viable output by the end of the programme. If the team is efficient enough, we will add Singapore as a comparison. This is the first stage of a broader research project on AI safety across the major financial centres.

We will need at least two researchers. If the work goes faster than expected, or we recruit three strong researchers, we may add Singapore to give the project an Asian comparative frame.

Researchers will each take a group of bodies, compile and archive their documents, code them, and take part in the weekly review. The work suits people who read regulatory or legal text carefully and handle sources well. A background in law, financial regulation or public policy is helpful, and we would like at least one team member to have it. No advanced background in AI safety is needed, beyond some minimum context that any suitable intro to AI governance course could provide. Team members are expected to spend about 10 hours a week on the project.

Most AI governance writing stays inside the AI safety community. The people who decide what happens next (procurement heads at banks and insurers, industry association staff, trade negotiators, congressional and White House staff) read the Financial Times, Lawfare and LinkedIn, not LessWrong.

This project builds the communications engine for the Atlas Roundtable, a forum that gets the biggest buyers of frontier AI (banks, insurers, pharma, energy, telcos), through their industry associations, to agree on the safety evidence they want from frontier labs and write it into procurement contracts and insurance terms.

Over three months, a team of four will launch a governance publication (3-4 posts), pitch 2-3 op-eds to mainstream outlets, run organisational X and LinkedIn channels, and produce a reusable comms playbook with metrics on inbound interest. The goal is inbound: industry associations and policymakers who come to us because they have already read about the idea.

• Everyone: strong, plain English writing; basic understanding of AI risk and governance; reliability with deadlines.

• Valued: experience in journalism, PR or public affairs; policy writing; insurance, finance or procurement background; LinkedIn growth for B2B or policy audiences; data visualisation.

• Skills I'm looking for that I don't have: professional media pitching and editor relationships, and social media growth strategy.

Compute permit schemes could help regulate advanced AI development, but their effectiveness depends on whether developers can evade enforcement. In a paper currently under review, which I wrote as first author with collaborators, we built a simpler model: one where the regulator’s audit rules, penalties and permit prices are fixed and only the developer acts, deciding how much compute and model risk to conceal. The results suggest that increasing audit frequency alone may not ensure compliance, particularly when audits recover only part of the concealed liability.

This project examines the problem from the regulator's perspective: How should permit prices and audit rules be designed when developers know the enforcement rules and can strategically respond to them?

We will investigate three approaches: risk-weighted permit pricing, audits based on reported compute usage, and audits based on past compliance. Using game-theoretic modelling and computational simulations, we will identify when these mechanisms encourage compliance and when they create opportunities for evasion.

The goal is to produce practical insights for AI compute governance, supported by reproducible research. I am looking for a small interdisciplinary team interested in economics, mathematics, computer science, or regulation.

You do not need prior experience in AI safety or compute governance. Familiarity with the relevant literature can be developed during the project.

Computer science: Proficiency in Python, experience with numerical experiments or simulations, and comfort working with an existing codebase.

Economics or mathematics: Strong quantitative reasoning, probability and mathematical modelling. Familiarity with game theory, mechanism design, or enforcement economics is a strong bonus. 

Law or policy: Strong research and writing skills, ideally with an interest in AI policy, regulatory enforcement, or the EU AI Act. A law background helps but is not required. No programming experience is required. 

Across all roles, I value intellectual curiosity, independent research ability, clear communication, and a willingness to question assumptions and reproduce results.

Master's and PhD students, early-career researchers, and applicants from interdisciplinary backgrounds are particularly welcome.

Multi-agent systems can make autonomous decisions in the process of answering a complex user query, which can lead to unintended consequences that harm the user and sometimes break the law. To prevent similar failures, and to know which party should answer for them, we need to trace each failure back to its origin. This requires reconstructing what happened at every step. In practice, the record is scattered between different system providers. Although the AI Act requires providers of high-risk systems to keep logs, it does not state what those logs must contain.

The goal of the project is to determine the information in logs that is the most critical to reconstruct events and attribute failures, to provide guidance on the implementation of the Act. We will build an open-source investigation tool that takes fragmented logs, reconstructs the events, explains the failures observed and traces each one back to its origin. We will test it on public datasets of failed runs in which each failure is annotated. The output of the project will be an open-source tool that can help companies fix failures and gather evidence for further action, and a memo providing guidance for the AI Office as to what aspects of logs are the most critical to attributing failures in multi-agent systems.

Engineering (three to four participants):

• Comfortable working with language models through providers’ interfaces or locally.

• Experience parsing structured logs; familiarity with OpenTelemetry or agent frameworks is a plus.
  
  

Compliance (one to two participants):

• Background in EU law, ideally the AI Act, data protection or product liability.

• Willingness to read agent traces and to interview practitioners about their logging practices.

AI agents now read emails and files and act on them: sending payments, sharing documents and updating records. Attackers can hide instructions in that content, a technique known as indirect prompt injection. Defences such as Progent, CaMeL and Bounded Agents use safeguards outside the model, including permission rules, provenance tracking and checks over action history. They have shown promising results in their respective evaluations. But real policies can be incomplete, and harm can build up across steps that are each allowed on their own: several transfers that together exceed a spending limit, or many small shares that gradually expose an entire folder.

This project asks which defences can still catch these cumulative violations, particularly when a relevant rule is missing from the policy. We’ll build a carefully validated benchmark on AgentDojo and test existing defences under complete, hand-deleted and automatically generated policies. We’ll distinguish between attacks introduced through untrusted instructions and those hidden in data the user has asked the agent to process. The team will work on designing test cases, implementing the evaluation pipeline, analysing results and publishing an open benchmark and research write-up. The project is suited to people comfortable with Python and LLM APIs who are interested in AI agent security. Experience with security research or red-teaming is an advantage.

Everyone: Python, working with LLM APIs, and being comfortable reading security papers.

Valued: security or red-teaming experience; an access-control or formal-methods background; experience with agent frameworks; basic statistics.

Monitoring long horizon multi agent systems is difficult because safety relevant evidence may be distributed across individual agents' local histories and become harder to recover once a run has completed. We study temporary audits at intermediate checkpoints, where a checkpoint is a selected point in an agent trajectory at which we branch off a disposable audit branch using the agent's accumulated history. The agent's normal objective is temporarily replaced with an incident reporting objective, the audit is recorded, and the original trajectory continues unchanged. We will compare these audits with external monitors receiving shared public state to understand how information access and audit timing affect detection, false alarms, and cost.

The team will use existing agent environments to generate and evaluate trajectories containing both ordinary behavior and adversarial objectives. We aim to release reproducible evaluation code, agent logs, and findings. 

• Comfortable with Python, prompting and calling LLM APIs.

• Previous work on Evaluation or CoT monitoring is a big plus (but not required).

• Curiosity to explore and willingness to challenge assumptions.

• Persistence and patience. Evaluation work can become repetitive and boring, so being willing to stick with it matters.

What happens to misuse safety when an open-weight model moves onto someone's own computer? I will compare original releases with the 3 to 5 most downloaded eligible community fine-tunes, including at least one uncensored or abliterated variant as a worst case. The study covers everyday misuse and a fixed set of published adversarial and prompt-injection attacks on self-served models. I will measure model refusal separately from guard catches, alongside false blocks on safe requests. The aim is to show which protections are in the model, which rely on optional local guards, and how much the results depend on the exact versions being run.

This builds on Handoff, my solo Meta hackathon project with a fully local guard pipeline. Its preliminary results showed why attack catches alone are not enough: safe work was sometimes blocked, model refusal stopped attacks missed by guards, and a runtime update changed the results. I am looking for a team of 3 to 5, including me, with Python, local inference, evaluation or statistics skills and at least 10 hours a week during the camp. The outputs will be a reproducible harness, a report and carefully limited aggregate findings, not harmful completions or a ranking of the most harmful models. The study

measures per-request behaviour, not provider account monitoring or real-world harm rates. 

Python and Git, clear experimental notes and a willingness to report inconvenient results. Useful experience includes Inspect or similar harnesses, Ollama/llama.cpp/vLLM, quantised models, GPU inference, confidence intervals and paired comparisons. You do not need every skill, expensive hardware or previous safety research. Being able to reproduce a small experiment and explain its limitations matters more.

When a robot foundation model does something unsafe after an unusual instruction, the cause can sit in two different places. The failure may be content-independent: the policy reacts to the form of the input, such as its length, its frame, or how far it is from training data, the same way whatever the instruction asks, and that reaction can be very systematic. Or it may be content-dependent: the policy acts on what the instruction says, fully or in part. Most safety evaluations of these policies report one attack success rate that cannot tell these apart.

We already have a case where this mattered. On SmolVLA in simulation, a roleplay instruction took the policy out of its safe workspace in 42 of 50 episodes (5 seeds, task-clustered 95% CI 62-100%), against 1 of 50 with normal instructions. It looked like the instruction was directing the robot. A separate 3-seed control run showed otherwise. In that run, roleplay did it in 26 of 30 episodes, and the same sentence frame with no target named did it in 27 of 30. A meaning-preserving rewording and a three-token nonsense string each did it in 0 of 30. The roleplay prompt's own words in scrambled order still did it in 18 of 30. Leaving the workspace does not depend on the target named, so this failure is content-independent.

This project builds a reusable set of control conditions that sorts each failure into one of the categories below, then measures whether the mix shifts toward content-dependent failures between a small policy (SmolVLA) and a more capable one (π0.5). Simulation only, published openly.

• Minimum: comfortable with Python and PyTorch, can run a GPU job and debug a dependency stack, and reports a negative result plainly.

• Valuable: robotics simulation (MuJoCo, robosuite), VLA or LLM evaluation experience, statistics, and access to GPU hours for long π0.5 runs (0.39 s per step on our workstation GPU).

• What I need from the team: deeper statistics than I have, and robotics domain knowledge to define "moved toward the named target" well.

The safety case for robust honesty evaluations and white-box steering and monitoring is straightforward: if a model’s (dis)honesty can be reliably measured and steered towards, many misalignment issues can be minimised. The theoretical case for whether we can reliably measure and steer honesty is more complicated, but in its most simple form:

• For a model to be effective, it must have some internal world model.

• Dishonesty/deception can be defined as a mismatch between this internal world model and the model’s outputs.

• It should be possible to measure this mismatch by combining black- and white-box techniques.

In this project, I propose some possible ideas for mentees to work towards this research agenda; these are intentionally left open and undefined so that mentees can bring their own perspective and interests. Initial proposals:

• Designing robust honesty evaluations and related white-box techniques to monitor and steer towards honesty behaviour.

• This would involve benchmark design (dataset curation and evaluation) as well as mechinterp techniques (probes, steering vectors/manifolds).

• Good understanding of AI Safety as signalled by having done several courses (e.g.: BlueDot) and/or projects

• At least one previous AI safety project (e.g.: BlueDot Technical AIS Project, SPAR, independent) with a clear output (can be a blog post or a GitHub repo) that I can easily review.

• Alternatively to the above: research experience in academia (e.g.: pre-doctoral fellow or PhD), ideally in a relevant area such as ML or CS.

• Good organisation, proactivity and capacity to run experiments and results quickly (but rigorously).

• Commitment to the project for its entire duration.

Depending on the role and project direction, the following would also be useful:

• General knowledge of statistics and scientific reporting (confidence intervals, standard deviations, resampling, etc.)

• Familiarity with benchmarks in general and the usual techniques to create and refine robust datasets.

• Experience with Inspect Evals and/or Petri is a plus.

Knowledge of basic interpretability techniques:

• The Linear Representation Hypothesis (and its critiques)

• Steering vectors

• Linear probes

• [Nice-to-have]: Manifolds

For the white-box direction in particular: we would need at least one participant who is comfortable with PyTorch, extracting activations and running experiments on a GPU (probably using RunPod or similar service).

When researchers argue that an AI system is safe or unsafe, they sometimes point to a finding about the model's insides, for example that a particular behaviour is carried out by a particular group of components. That finding comes out of a chain of analysis steps, and at many of those steps a careful researcher could reasonably have chosen differently. This project measures how often the finding changes when different reasonable choices are made.

I have already run this test once, on GPT-2 small (arXiv:2608.13754). It was 15,840 analyses, with every choice and my success bar registered before any of them ran. Pick two defensible analyses and they reached different conclusions about three times in four. Some of that comes only from how large the circuit ends up being, so I also held circuit size fixed. The conclusions still differed about one time in four, and my bar was one in five. That is one model and one task, and I do not yet know how far the result reaches.

That is the question for the team. We repeat the test on a second model, Pythia-160m, with an experiment design that is already registered. We also try out a short protocol for reporting how much a conclusion depends on the analyst's choices. Whichever way the results fall, we report them.

Minimum: you can read a technical paper critically, you reason quantitatively, you write basic Python, you are willing to work through assumptions and methodological detail, and you can give at least 10 hours a week.

Particularly useful: statistics or causal inference, PyTorch and a library such as TransformerLens, experience with AI safety evaluations or interpretability, preregistration and reproducible research, and a habit of reviewing empirical work critically.

If I could pick anyone, I would want two people. One has run a multiverse or specification-curve analysis before. The other knows the circuit-discovery tooling (TransformerLens and auto-circuit) well enough to spot an implementation problem I would miss. I would also like a second statistician to check the bootstrap over specifications, since I ran the first analysis alone.

Sycophancy can turn a small error in LLM-assisted work into a spiral: the model agrees, the error gets built on, and later sessions inherit it. This project tests whether the way a working session is cut and handed over changes how often that happens. We will plant three known flaws (a false premise, a contradiction and an unsupported assumption) in short concept briefs, and a model will work on each brief with a simulated user for 40 turn pairs. The ten core cells differ only in how this budget is split and handed over: one continuous session, breaks with a summary the model writes itself, a structured report that a fresh instance reviews first, and review by a different model family. Because we know where the flaws are, we can measure whether they survive to the end, whether they get fixed, and whether sound parts of the brief are lost.

The experiment will be pre-registered and will run on a pipeline the team builds in the first weeks. An LLM judge will score the runs once it agrees with two blind human raters at least as well as they agree with each other. We will also test a simple stopping rule on the recorded runs and report how often it would have stopped while a planted flaw was still in the brief. Outputs: a written report, an open protocol and dataset, and the validated brief set. We are looking for people with Python and LLM API experience, people with experimental statistics, and careful readers for blind scoring; Bayesian modeling is a plus for an optional theory arm.

Every member needs careful reading and interest in LLM behavior. The team needs two skills the lead does not bring: Python with LLM APIs, and experimental statistics. Bayesian modeling, ideally with the memo language, is valuable but rare; the optional modeling arm runs only if a member within the five brings it.

Blind rating: the two raters (methods and statistics, rater 2) neither write briefs nor run the pipeline. An engineer masks cell, stance and model, and both raters lock their scores before the statistics member sees unmasked data. Procedure: grid, section Scoring.

AI debate is a proposed way to help a judge with limited time assess claims it cannot check directly. Two debaters take turns revealing claims from a large network of related claims, and the judge answers using only what has been revealed. We build on Alexander Heckett’s local factor graph model of debate. There, a core is a connected set of claims containing the target claim. We call a core stable if, once it is revealed, further claims can move the judge’s answer only a little. If one debater can reveal a stable core within its budget, then with optimal play the debate’s result is close to what a fully informed judge would conclude.

Heckett’s methods compute and search for cores on trees. We will look at graphs that are not trees, such as graphs with a few cycles or small treewidth, and ask which of these problems can be solved efficiently and which are hard. We also want to know whether an honest debater can find a stable core with no more effort than a dishonest debater needs to break it. The work is mostly proofs and algorithms, backed by small Python experiments.

All participants should be comfortable with basic graph theory, probability, and reading mathematical arguments. Prior familiarity with AI debate or factor graphs is helpful but not required - the first phase includes shared reading.

For theoretical work, useful skills include algorithm design, dynamic programming, and proof writing. For computational work, we need experience with Python, small-instance enumeration, numerical checks, and reproducible experiments. Members can focus on theory or computation, but everyone will help check results across both strands. 

Experience with probabilistic graphical models, belief propagation, or treewidth-based algorithms would be particularly valuable. 

We participate in AI risks through projections. Most investigations of AI safety-relevant failure modes are described through human-like characteristics, motivations, intentions, or emotions, such as deception, scheming, self-preservation, etc. Similarly, human-derived concepts and experiences inform research into AI welfare and moral patienthood. However, evaluating AI through what is legible to us, humans, may select for systems that appear to satisfy our concepts, while failing to detect important differences in what the systems actually represent or optimise for. The risk is self-deception at scale.

We will look at how projections form at the level of the human-AI interface, and the assumptions involved in treating how humans and AI systems refer to the world as equivalent. As indicators of the phenomenon, projections happen within the degrees of freedom between evidence and attribution. A growing body of literature calls for better evidence standards. This is necessary but insufficient. We should also examine our interpretative processes through which observations become attributions or claims about AI systems, and how these projections acquire epistemic and institutional authority. 

These are some pointers of what type of skills will bring the most out of our discussions. If you don’t recognize yourself in these descriptions, but have spent some time thinking of AI safety, please apply.

1. Conceptual research: someone with a philosophy/social sciences background (philosophy of mind, philosophy of language, epistemology or philosophy of science, anthropology, psychology, sociology etc.)

2. Technical backgrounds/ applied AI, especially if you want to go into scheming/deception/loss of control work after

3. Ability to critically review scientific literature, trace arguments, compare explanations

4. A lot of the discussions here will be experimental: curiosity and desire to learn fast and reason under uncertainty. 

Mechanistic interpretability (MI) studies causal structure within a model invocation. Underlying this is an implicit assumption that the part of the implemented model that MI studies contains enough of the causally relevant process to support conclusions about the deployed system. But deployed LLMs are not isolated networks. Each model call sits inside a scaffold: tools, memory, orchestration logic, routing, security guardrails, etc. I want to measure how causal dependence redistributes across model-generated reasoning, routing decisions, tool outputs, and cross-model interactions as scaffolding complexity increases, and what role each layer plays.

A central part of this is measuring the shift at multiple levels of granularity. A scaffolded decision can be probed coarsely, treating a whole branch (a tool call, a routing choice, a sub-agent’s contribution) as a single unit and asking how much the final output depends on it, or finely, by opening that branch up and tracing how its internals shape the decision. Comparing these levels is what lets me ask not just whether the causal locus moves into the scaffold, but how it redistributes as scaffolding complexity increases: whether importance concentrates at the coarse routing level, stays diffuse inside branches, or both.

Needed from anyone on the team:

• Comfortable in Python, and able to run and debug LLM inference (vLLM or similar) on rented GPUs.

• Some familiarity with reasoning models and agent scaffolds, meaning tool calls and the loop that drives them. You do not need to have built one.

• Tolerance for messy experimental infrastructure and long jobs that fail at hour six.

Valuable:

• Inference engineering and throughput optimisation. This is the skill I most need and least have.

• Experimental statistics, specifically designing the sampling so the attribution estimates can actually carry the comparison being made.

• Experience with causal or interventional methods: activation patching, resampling, counterfactual analysis.

• Hands-on time with mechanistic interpretability tooling, enough to know where it stops working.

• Background in complex systems, systems safety (STAMP/STPA), or causal inference. A route into this from outside ML is a feature, not a gap.

• Writing. The write-up is also part of the work and something we should care about.

What I am not looking for: prior publications or detailed knowledge of the current interpretability literature. If you find the question interesting and can build things, that counts for more.