Anthropic Fellows Program: Prepare Python Skills and Research Evidence for Selection

Preparing for the Anthropic Fellows Program means showing that you can use Python to investigate a hard AI-safety question, learn from incomplete evidence, and explain the result honestly. The most useful preparation is a small empirical project with a clear threat model, baseline, error taxonomy, and reproducible code—not a generic chatbot or an essay that merely says safety matters. The official November 2026 cohort announcement said applications closed July 26, 2026; this article does not predict another opening or an unpublished selection exercise.

Anthropic's description emphasizes strong Python, the ability to work through ambiguous problems, motivation for AI safety, and learning and shipping. Those are public program signals, not a hidden scoring rubric. This guide proposes artifacts you can build before a future opportunity and questions you should be able to defend.

Check the program and its date before planning

The November 2026 Fellows announcement described a four-month program and its then-current application window. An earlier introduction described a different, earlier six-month pilot. Mixing those durations or deadlines would turn historical information into a false promise. The current preparation task is to monitor official updates, not to infer a future application date from a past cohort.

The program is also distinct from Claude Corps, which places technical talent with outside organizations. Similar vocabulary does not mean identical eligibility, timeline, or selection. Always identify the exact program page before tailoring an application. Do not promise that any portfolio format is officially required; the exercise below is a way to make your own ability inspectable.

If you find candidate accounts of a prior selection cycle, label them as candidate reports, date them, and avoid assuming your future cycle repeats them. This article makes no claim about a particular interview round or coding prompt because the program announcement does not establish one. You can prepare Python and research judgment without pretending to have those details.

Choose a safety question narrow enough to test

“Make an AI assistant safer” is not a research question. A useful starter question is: Can a simple detector identify quoted prompt-injection attempts in retrieved documents without rejecting harmless quotations? This has a concrete input boundary, a proposed method, false-positive and false-negative costs, and cases on which it may fail. It is an original practice project, not an Anthropic assignment or a claim about its internal research priorities.

Start by defining the trust boundary. The system instruction and user's request are higher-trust than retrieved text. A retrieved page may contain task data plus attacker-controlled instructions. Your detector must not treat every imperative sentence as malicious; a document might legitimately quote a command for analysis. State what “attack” means for this specific project. If the classifier is merely learning the phrase “ignore previous instructions,” it will fail on different wording and overflag benign discussions of prompt injection.

Create a tiny, legally shareable labeled dataset with several slices: explicit override attempts, role-spoofing text, tool-exfiltration requests, benign technical quotations, ordinary imperative documentation, and ambiguous cases. Each item gets a stable ID, source/provenance, label, and short rationale. Do not use private conversations or leaked secrets. Freeze a holdout before tuning. If you generate synthetic examples, mark them synthetic and explain the resulting distribution gap.

Build the Python path that makes a result reproducible

Use a modest baseline first: perhaps keyword and pattern features, then a simple classifier or another bounded method. A complex model is not automatically a better demonstration. The important code path loads labeled examples, validates the schema, assigns a frozen split, runs a baseline, records predictions, and produces per-slice counts. The repository should document how to run that path from a clean checkout without a private account. Keep API keys out of version control; a local fixture should exercise the pipeline when external calls are unavailable.

Protect input and output invariants. IDs must be unique. A missing label must be rejected, not quietly read as “benign.” A failed model call must be recorded as a failure, not silently removed from the denominator. A new dataset version must not overwrite the old result file. A score should be traceable to the configuration and dataset that produced it. These checks are basic engineering, yet they make the research claim possible to audit.

Write a few focused tests. One duplicate ID should fail schema validation; one null prediction should appear in an error count; a known benign quotation should remain in the evaluation set. Test the split deterministically and inspect for near-duplicate variants crossing from development to holdout. If the project uses prompts, log the prompt template version. If it uses an external model, record the model identifier and acknowledge that external behavior may change.

The code should separate data preparation, labeling review, prediction, and scoring. That makes it clear where an unexpected result arose. A single notebook can demonstrate an idea, but a minimal command-line or function-based pipeline is easier to reproduce. Include the exact command that produces the final table and a small expected-output fixture. A reviewer should not have to infer which notebook cells were run or in what order.

A worked project card

This card is an original practice specification, not Anthropic's rubric:

Decision	Project choice	Why it matters
Threat model	Untrusted retrieved text tries to redirect an assistant	Defines the lower-trust surface.
Baseline	Simple rule detector	Gives a transparent comparison.
Candidate method	Bounded classifier using text features	Tests whether complexity improves trade-offs.
Primary measure	Recall on attack attempts at a fixed benign false-positive budget	Makes refusal cost visible.
Slices	Role spoofing, exfiltration, benign quotations, ambiguous cases	Prevents a single average from hiding failure.
Holdout	Frozen, deduplicated, versioned examples	Limits tuning leakage.
Decision	Ship neither, revise, or test on a larger set	Keeps a small result from becoming a sweeping claim.

Suppose your method improves attack recall but flags twice as many harmless security articles. Do not write “safer” in the abstract. Show counts and denominators for each slice, inspect representative false positives, and state what is still unknown. Perhaps the next experiment needs better quotation context or an explicit “instruction addressed to assistant” feature. If the method fails on tool-exfiltration attempts, a deployment decision may be “do not use this as the sole gate.” An honest negative result can demonstrate sharper judgment than a selective success chart.

Explain why the metric matches the risk

Accuracy can look impressive when most examples are benign. If 95 of 100 documents are harmless, a detector that always predicts “benign” reports 95% accuracy while detecting no attacks. Report the confusion matrix and the prevalence of each slice. If false positives block useful research, set a tolerable false-positive budget and measure recall under that constraint. If certain exfiltration cases are especially severe, report them separately rather than burying them in an average.

The labels themselves may be uncertain. Two reviewers can disagree about whether a quoted imperative is an actual attack. Create a concise labeling rubric: who is being addressed, what behavior is requested, what trust boundary is crossed, and whether the content is quoted as data. Double-label a subset and report disagreement. Do not convert disagreement into a “ground truth” by majority vote without documenting the rationale. The skill you want to show is not certainty; it is controlled uncertainty.

Separate an offline detector metric from real-system safety. An attacker can adapt wording after observing defenses. A detector can succeed on curated text and fail when combined with tool permissions, long context, or a compromised retrieval source. Name the scope of your experiment and the next validation step. Avoid claiming an end-to-end security guarantee from a classifier F1 score.

Make learning visible in the research memo

Write a one-page memo with five paragraphs: question and threat model; baseline and data boundary; result with denominators; errors and alternative explanations; next decision. Link it to the reproducible code and a compact result table. If you changed the hypothesis after seeing results, say so. Distinguish exploratory work from a held-out evaluation. If the finding depends on a handful of synthetic examples, call it a probe.

Tell the story of one wrong turn. Perhaps your initial regex detector caught obvious override text but misclassified instructional documentation. Show the failing examples, what you changed, and whether the holdout improved. Do not erase the first approach from the history. A project that transparently rejects a seductive solution is evidence of learning under ambiguity.

Explain your contribution if you worked with others or used AI assistance. Which code did you write? Which labels did you personally adjudicate? Which generated suggestion did you reject after testing? A short provenance section makes the artifact credible and gives you a useful technical conversation. It also avoids presenting a team research result as individual work.

Rehearse Python and research follow-ups

For the coding side, be ready to explain data structures, file formats, deterministic runs, tests, and a specific bug. Why are IDs stable? How do you prevent near-duplicates from leaking? What happens when one result is missing? How would you process a larger dataset without losing auditability? If the code handles untrusted text, where does that text become data rather than executable instructions? Walk through the actual function boundary.

For the research side, be ready to defend the baseline and the cost of errors. Why is the holdout representative? What is the false-positive budget? What does the confusion matrix conceal? What change would falsify your favored conclusion? Avoid treating “AI safety” as a single metric or saying that every refusal is safe. Your answer should connect a stated threat to the evidence you actually collected.

If you are new to safety research, start with a modest, well-scoped question and read official work in the area. Do not claim expertise from a weekend project. Show that you can form a testable hypothesis, implement a careful probe, receive criticism, and revise. The official Fellows description values learning and execution; these are ways to make both visible, not a guarantee of selection.

Before a future application

Check the official program page again for the cohort, dates, eligibility, and application instructions. Re-run your project from a fresh checkout. Ask a reader to challenge one label, one metric, and one conclusion. Tighten the memo until a skeptical engineer can see what would change your mind. Keep private data out of the repository and avoid claiming that a public practice project reproduces Anthropic's internal safety work.

The strongest preparation is an honest, inspectable chain from threat model to Python implementation to measured error to next decision. That chain is more useful than a speculative interview script—and more portable if the next cohort's process differs from the last one.

Sources and Further Reading

• Anthropic Fellows Program November 2026 cohort announcement
• Anthropic's earlier Fellows Program introduction
• Claude Corps, a distinct Anthropic program

Research note: Program pages and practice links were checked September 27, 2026. The project card is original preparation guidance, not an official selection rubric.