Model Behavior Engineer, Reasoning and Decision Making

About Elicit

Elicit helps research and business teams investigate hard questions and make high-stakes decisions grounded in evidence.

Our ambition is to make high-quality reasoning under uncertainty available at a much greater scale in contexts where stakes are high and feedback is sparse. We're building AI systems whose work people can inspect, question, and improve, so that increasingly capable AI also makes us more wise.

Why we're hiring for this role

Some of the most valuable questions people face are also the hardest to answer well. Which research program should a team advance? What evidence would change its priorities? Which uncertainty is worth resolving before committing to a multi-year, $100 million dollar trial?

Today's models can contribute to these decisions, but they often miss a crucial consideration, make an assumption they should have checked, or reverse a recommendation too readily when presented with new information. Further, because they can perform increasing amounts of work autonomously, their process and reasoning is often poorly legible, so decision makers are wary to trust their outputs.

Helping with these problems requires a deep understanding of model behaviors, what matters for different types of decisions, the environments and cultures in which decisions are made, and how to evaluate complex, multiplayer systems with many human and agent interactions.

We're looking for someone to own that work: understand where our systems fall short, develop ways to evaluate them, and build improvements that help users make better decisions. You'll start with concrete problems in scientific R&D and commercial strategy, and develop approaches that apply across different kinds of decisions.

About the role

You'll join our engineering team and report to an Engineering Manager. You'll work on a cross-functional engineering team, collaborating closely with other engineers, product, design, and domain experts, taking problems from investigation and experimental design through implementation and use in the product.

The work combines careful reasoning, the ability to dive into domain specifics, and software design. You'll design agent environments and how agents represent problems, gather evidence, use tools, retain context, revise their conclusions, and coordinate with each other. You'll also make the engineering decisions that let us inspect those processes, test changes, and build on what works.

Most of the initial work will involve systems built around existing frontier models. Training or finetuning may be useful for particular problems, but the direction of the work will follow what helps users reason better.

What you'll own

Understand the decisions we're helping people make.

Work through real cases with users and domain experts. Identify their objectives, constraints, available evidence, and important unknowns. Learn enough about an unfamiliar problem to recognize when an answer misses the point.

Define and measure good reasoning.

Build evaluations for problems where success is initially underspecified. Combine close inspection of examples, expert judgment, and quantitative analysis. Investigate whether a better score reflects a meaningful improvement, and whether that improvement holds on new cases.

Improve the system's behavior.

Turn observed failures into hypotheses you can test. Experiment with problem decomposition, context, tools, and ways for agents to seek information or check their work. Follow promising results through to changes users can benefit from.

Design the software that makes this work reliable.

Choose useful abstractions, data structures, and component boundaries for reasoning workflows and evaluations. Make deliberate tradeoffs among simplicity, flexibility, reliability, latency, and cost. Build systems whose failures you and your teammates can diagnose.

Own the quality of what you ship.

Write maintainable code, participate in design and code reviews, and test and monitor your changes. Work with other engineers to integrate your systems into the product and improve them as you learn from real use.

Example projects

Build and evaluate a workflow that helps a research team compare potential protein targets they could nominate for drug development, works in light of their goals and decision frameworks, performs legible research against detailed and stress-tested theories of success, and stays up to date in light of new findings.

Investigate why an agent overreacts to newly introduced evidence when forecasting clinical trial readouts. Create an evaluation that distinguishes justified changes in judgment from inconsistent ones, then implement and test an improvement.

Design a representation of evidence, assumptions, and unresolved questions that an agent can update as a decision to acquire a new asset evolves, while preserving the information needed to inspect its work.

Improve an agent's ability to notice missing context and ask useful questions before making a recommendation.

Test whether an approach that improves R&D prioritization decisions transfers to business development strategy, and use the result to decide what belongs in a shared component.

What you bring to the role

• Rigorous thinking about ambiguous problems.
• You can make a vague question precise, identify hidden assumptions, weigh conflicting evidence, and explain what would change your mind. You can make progress while remaining clear about what you don't know. This might come from a range of backgrounds such as original research in economics or developing quantitative trading approaches under adversarial conditions.
• Curiosity across domains and clear communication.
• You enjoy getting to grips with unfamiliar subjects, learning from specialists, and explaining your reasoning to people with different expertise. A good sign is having leveraged domain expertise across multiple scientific domains or business specialities.
• Good experimental instincts.
• You can devise a useful test when there isn't an established benchmark, distinguish evidence from noise, and recognize when your evaluation is rewarding the wrong behavior. You're willing to inspect individual failures in detail.
• The ability to implement your ideas.
• You can independently write and debug code, work with data and model APIs, and take an experiment into a maintained codebase. You're comfortable with Python or a comparable language and willing to work across the relevant parts of our stack.
• Practical familiarity with language models.
• You've explored their capabilities and limitations enough to have informed ideas about how to improve them. You can choose an approach based on the problem and update it as models change.
• Strong engineering and architectural judgment.
• You can design a coherent system, explain your choices, and recognize when an abstraction helps or adds unnecessary complexity. You've built software that others can understand, use, and extend. Experience may come from products, research systems, or other substantial technical projects; a full-stack engineering background is not required.
• Effective use of coding assistants.
• You use AI tools to increase what you can build while taking responsibility for understanding the design and verifying the result.
• We care about evidence of these abilities. Substantial projects, thoughtful experiments, and clear explanations of technical decisions are useful ways to show us how you work.
• Am I a good fit?
• You might enjoy this role if you find yourself wanting to work through questions like these:
• A model's recommendation sounds convincing to non-experts, but an expert thinks it is supported by slop. How would you investigate the disagreement and turn what you learn into a useful evaluation?
• An agent has acquired new evidence. How should the agent identify which conclusions need revisiting, and how would you test that it does so correctly? How does this scale as the amount of evidence grows to tens of thousands of documents?
• A workflow succeeds on a handful of simple examples. What would you need to learn before using it for customers, and which parts of the implementation would you change first?