Mercor’s Osvald Nitski on AI Training Data, Product and Customer Concentration

Harry Stebbings asks whether improving open models could cannibalize Mercor’s business supplying training and evaluation data. Head of product Osvald Nitski argues that such models raise the baseline of what customers expect, while labs still seek data for capabilities at the frontier. This is the company’s commercial view.

Stebbings suggests that open models might handle 90% of enterprise workflows. Nitski disputes that figure and says current usage may miss latent demand, such as a procurement agent working over a long period with limited supervision. That example is an aspiration, not evidence of widespread reliable deployment.

Asked about enterprise reluctance to share data, Nitski says sensitivity depends on the workflow. He distinguishes general functions from activities central to a company’s competitive position. The actual sensitivity of HR, procurement, legal and other data depends on the organization and use case.

The host asks about privacy when using open-weight models. Nitski says where inference runs matters: open weights can give an organization more control over deployment, but they do not automatically make a system secure. Configuration and operational choices remain important.

Nitski cites roughly 50% performance by leading models on Mercor’s Apex benchmark for long-horizon workflows. He also distinguishes tasks with a clear completion condition from work such as legal reasoning where quality may improve continuously. The benchmark result is specific to its tasks and methods, not a measurement of all enterprise workflows.

Stebbings asks whether every company will eventually use a specialized model. Nitski says he believes specialization will grow where the return justifies it, while acknowledging that this view also serves Mercor’s interest in selling enterprise-specific training and evaluation data.

On enterprise AI returns, Nitski says many organizations are still experimenting and may tolerate a delayed or uncertain calculation. He notes some pressure to control spending, but believes changing model prices and performance make the long-term economics difficult to judge. This is his assessment, not a universal finding.

Nitski says token budgets should depend on the use case. Spending on engineering tools may support future development, while a customer-service agent whose compute costs exceed the revenue it serves has a different economic problem. He draws on his experience at growth-stage companies.

Stebbings cites a reported Salesforce expenditure on Anthropic and asks what proportion of personnel cost AI spending might represent. Nitski says large organizations should distinguish research, solutions engineering and other teams when judging outcomes. The reported spending and comparison are not independently verified in the interview.

Nitski predicts that AI spending as a share of labor costs may rise. He says Mercor itself spends more on AI than on salaries and describes rapid headcount and revenue growth, attributing the spending to customer demand. These are company statements, not audited financial disclosures.

Faster development makes product management harder, Nitski says. When engineers can ship many features quickly, the team must resist expanding the product surface indefinitely and instead simplify workflows. In his view, deciding what not to build becomes more important.

He expects a higher ratio of product managers to engineers as coding tools increase engineering velocity. Understanding customers, business priorities and the effects of a product may become the constraint. This is a prediction based on Mercor’s experience rather than a rule for every organization.

Nitski says his team increasingly uses AI-assisted design tools and fewer separate applications. He places more emphasis on judgment and business impact than familiarity with a long list of tools. The observation describes Mercor’s current practice, not proof that any design product will be displaced.

A product mistake illustrates the tradeoff. Mercor built a highly flexible annotation platform to support many customer requests and data formats. Nitski says the resulting variety made hundreds of projects difficult to manage and that the team should have narrowed its supported workflows sooner.

The team now considers whether a requested workflow has enduring demand before investing in it. Nitski says the answer ultimately involves judgment, conversations with multiple labs and repeated hypothesis testing. He admits that predicting the form of data a year or two ahead is partly a guess.

On the company’s movement away from some design software, Nitski says teams choose the tools that work for them and that fewer licenses can reduce friction. He presents this as an internal trend rather than a verified industry-wide shift.

Stebbings asks whether services are the future of enterprise AI deployment. Nitski sees them as especially useful in the near term because expertise in deploying and evaluating agents remains unevenly distributed. He expects more of that knowledge to become a normal organizational capability over time.

The interviewer asks whether strong engineers want customer-facing roles. Nitski says communication, finding the underlying problem and simplifying it are valuable engineering skills, and can make someone effective in a forward-deployed role or as a founder.

Nitski says some colleagues have left to start companies. He values seeing people pursue those ambitions, while acknowledging that turnover makes management harder. His description of retention applies to the colleagues he mentions, not a company-wide retention statistic.

For product hiring, Nitski says Mercor has leaned toward candidates with enough experience to connect work to business outcomes. Stebbings challenges the risk of overvaluing seasoned operators; Nitski says he wants people who have done the work and remain motivated, rather than simply former executives.

Mercor uses an exercise to check familiarity with AI tools, then emphasizes whiteboard discussions. Nitski looks for experimental design, statistical understanding, judgment and systems thinking. His aim is to see whether candidates can reason independently rather than repeat an AI-generated answer.

Stebbings asks how people retain independent thought when AI tools are ubiquitous. Nitski distinguishes execution assistance from delegating judgment: he advises his team to check outputs and retain responsibility for decisions. This is his management practice, not a claim that every AI-assisted decision is unreliable.

Experiments do not always produce a clear relationship between effort and outcome. Nitski says the product team tries to choose informative tests, learn about users and connect changes to business effects over time. He acknowledges that results vary from week to week.

Mercor has two main product areas: a marketplace matching experts with work, and an annotation and evaluation platform used by experts, operations staff and customers. Nitski describes each as having a dedicated product group supported by data science and design.

He distinguishes a talent-only engagement, where a customer runs a project with experts Mercor sources, from a managed service, where Mercor organizes the work and delivers a dataset. The latter combines the marketplace with the annotation platform and requires more operational coordination.

Nitski describes small product pods and weekly meetings that align roadmaps while leaving individual groups to plan their own work. As the company grows, he expects product-management and engineering staffing to change, but says the teams must grow together.

The biggest coordination challenge is information moving between rapidly growing teams. A problem in the marketplace can affect the annotation experience and vice versa. Nitski says the company needs more cross-product collaboration without letting the number of communication channels overwhelm the work.

Asked how Mercor scales its supply of experts, Nitski credits three factors: the expert experience, referrals and a sourcing team that can find specialized people. He says timely, transparent and fair payment is important to that experience. These are company claims, not an independent assessment of every worker’s experience.

Nitski argues that a one-off high payment is not enough to retain experts. He says people also value visibility into future work, interesting projects, communication and the ability to develop skills. Clear instructions matter because remote annotation work can otherwise feel unfamiliar and difficult to navigate.

Stebbings asks about margins. Nitski does not give a margin figure; he says the product team focuses on customer value and expert experience while pricing reflects costs. Depending on the project, costs can include expert compensation and model usage for synthetic data or quality control.

Responding to criticism of Mercor’s revenue metrics, Nitski says the company adds substantial cash to its bank balance and considers the business healthy. This is an executive’s characterization, not audited revenue, profit or cash-flow data, and it does not resolve how the company recognizes revenue.

Stebbings asks about concentration among frontier-model labs. Nitski says Mercor wants to serve more enterprises and make smaller projects practical through better products and processes. He says the shift has reduced concentration, but provides no customer shares, time series or independent evidence.

Running human-data projects is difficult because customers must communicate detailed requirements to experts and resolve unexpected edge cases. Nitski says the operations team must align customers, experts and other stakeholders quickly while tracking quality, timing and bottlenecks.

He says data formats have changed from supervised fine-tuning and preference rankings to rubric-based work and reinforcement-learning environments. Each project can introduce new requirements. In his view, careful operations and clear communication are essential to scaling.

Nitski says environments are the company’s fastest-growing data type. He describes simulated applications, starting states containing files and tasks that ask agents to use tools. His claim that Mercor leads this category is a company assertion and is not independently substantiated in the interview.

A training environment should resemble the setting an agent encounters in deployment, Nitski explains. For example, a simulated business application may need a realistic interface, data and task conditions. Constructing and evaluating those environments can be complex, and definitions differ across providers.

On pricing, Nitski says labs still negotiate, but the value of better evaluation and training can make data spending attractive. His claim that such spending translates to customer revenue is a business argument; the interview does not establish a causal return for any specific customer.

Stebbings asks whether specialized data providers will proliferate. Nitski says some founders personally produce high-skill annotation and suggests venture capital can subsidize that work. He argues that scaling beyond the founders is difficult, a competitive assessment from an incumbent provider.

Mercor monitors competitors and customer feedback, Nitski says. He regards vendor comparisons as a way to identify where another provider is doing better and to improve his own service. The discussion does not provide an independent comparison of vendor quality or market share.

Stebbings discloses that he is an investor in legal AI company Legora and asks whether major model providers will compete directly with specialized applications. Nitski points to large technology companies entering many markets while focused competitors still emerge. He says the outcome remains to be seen.

Asked about a security incident, Nitski says he is not a security expert and that Mercor hired specialists and increased its investment in security. The conversation does not establish the incident’s cause, scope or remediation effectiveness.

Nitski expects demand for cybersecurity data to grow. He characterizes security as an adversarial field in which offensive and defensive capabilities continue to evolve, making a fixed sufficiency threshold less useful. This is a forecast and a description of the company’s opportunity, not a guarantee.

On hiring in San Francisco, Nitski says competition for talent and retention are difficult. He finds ownership and initiative especially hard to assess in interviews, and says the company values people who care about the work. His hiring preferences are personal and company-specific.

Reflecting on what changed his mind, Nitski says he initially doubted that training-environment projects could scale because they were difficult to deliver. He says demand and repeated experimentation helped the company make them work. The interview does not provide independent evidence of the outcomes.

For a computer science student, Nitski recommends an internship at a growing company to gain practical experience. He acknowledges his own bias toward fast-moving companies in San Francisco. That advice reflects his career path rather than the only viable route into technology.

Nitski estimates Mercor has around 500 employees and says it seeks to retain a startup culture despite its growth. He describes an office-centered, fast-moving environment. The headcount and cultural characterization are his statements at the time of the interview.

Asked to make the optimistic case for a much larger Mercor valuation, Nitski argues that better models and specialized enterprise applications could sustain demand for evaluation and training data. This is a hypothetical business case, not a verified valuation target or investment forecast.

He identifies physical-world data and robotics as a potential source of growth over the next three years. Mercor sometimes retains experts or creates data in advance when it believes future demand may justify it, he says. Those opportunities and resale outcomes remain uncertain.

Stebbings challenges the current state of robotics, citing slow demonstrations and human assistance. Nitski compares the development path with autonomous vehicles, which took years of testing and are still limited by geography and other constraints. His expectation of robotics progress is a prediction, not a timetable.

Nitski thinks robotics could have a significant adoption moment, but expects physical deployment to scale differently from software because hardware and operating environments are harder to expand. The discussion closes without claiming that current demonstrations prove general-purpose autonomous capability.