Nebius is hiring FDEs to take Tavily into production

On 10 February 2026 Nebius announced an agreement to acquire Tavily, an agentic search provider serving Fortune 500 companies and many leading AI firms. Seven months later, in New York, Nebius advertised a role called Forward Deployed Engineer, Enterprise – Tavily. The core of the job is designing and deploying production integrations on Tavily’s API.

For FDEs, the job ad matters more than the deal. Search for agents is becoming a piece of infrastructure that companies buy, and they need people to connect it to their real systems. If you want to move into applied AI, this tool is a cheap way to practise exactly the skills the job description asks for.

What does Tavily actually do?

Tavily’s documentation describes the product as “the web layer for AI agents”. The API has four capabilities. Search finds fresh, relevant sources on the web. Extract pulls clean content from one or more URLs. Crawl reads many pages of the same website. Research returns a report with citations, synthesised from several sources.

According to SiliconANGLE, Tavily brings three jobs together in one API for developers: fast search, website crawling, and turning web page content into structured form. Named customers include IBM, Cohere and Groq. According to Nebius, Tavily keeps its brand and continues to serve existing customers. Tavily’s team, including founder and chief executive Rotem Weiss, moves to Nebius.

When does an FDE need it?

A language model knows nothing about what happened after its training cut-off. An internal RAG system knows only the customer’s own documents.

So whenever a use case needs changing information from outside the firewall, such as new regulations, competitors’ prices or news about suppliers, the agent needs a web access layer.

You can write that layer yourself or use an API such as Tavily. Writing it yourself means handling search, page fetching and stripping out junk HTML on your own. When working on site with a customer, an FDE’s time should go into the business problem, so an API that already bundles search, crawl and extract saves you from rebuilding that work.

A minimal example, end to end

Imagine the analytics team at an insurer wants an agent that summarises the week’s regulatory changes every Monday morning. What follows is a hypothetical scenario for you to copy the structure of, not real API output.

Step one: the agent turns the request into a query, such as “life insurance regulation changes this week”, and calls Search. What comes back is a list of sources with URLs. Suppose it includes a press release from regulator A, a financial news article and a blog post from a law firm.

Step two: the agent keeps only URLs on the regulator’s domain, then calls Extract. Instead of raw HTML mixed with menus and footers, you get the text of the release, for example the passage stating which clause was amended and the date it takes effect.

Step three is needed only when the regulator publishes many documents scattered across the same website. In that case you use Crawl to read multiple pages of that site.

Step four: the model writes the summary to a fixed template. A sample line: “Regulator A amends fee disclosure requirements, effective [date] — source: [press release URL].” The rule is simple: any point that cannot be tied to an extracted URL does not go into the summary, so that a compliance officer can click through and check each point.

Research can replace all four steps with a single call, because it returns a report with citations directly. Before choosing that route, check whether Research’s output shows you clearly enough which sources were used.

Advice: when prototyping, start with Search plus Extract and log every URL. Once you understand source quality, compare against Research before choosing. Look up exact parameter names in the official documentation; do not guess.

The prototype works. What does production need?

Nebius’s job ad describes the FDE working with customers’ engineering, data, product and AI teams to take use cases from prototype to production. An API call that runs on a laptop is only a prototype. Production has to answer three questions: what happens when the API is slow, who notices when a source is wrong, and who is accountable when a summary cites the wrong document.

For latency, set a timeout on every Search and Extract call. When it expires, the agent does not hang but switches to a fallback: use the saved results from the previous run with a “not yet updated” line, or say plainly that the sources could not be fetched.

For wrong sources, sit down with the customer’s compliance team to agree an allowlist of trusted domains, then filter URLs in your own code before the Extract step. The list should live in a config file, with a named owner on the customer’s side, so that adding or removing sources does not require a code change.

For accountability, add a citation check to your eval: for every point in the summary, confirm that the text extracted from the cited URL actually contains that information. The share of points that match their sources, measured on a sample set of questions with known answers, is the number to track daily, and a specific person must receive the alert when it drops.

What should you learn first?

The job ad spells out a requirement for strong hands-on engineering, especially Python, APIs and backend systems, plus experience with RAG and agents. The learning order is therefore fairly clear.

First, write an API client with timeouts, error handling and retries. Next, build a pipeline that fetches sources, filters them against an allowlist and feeds them into the model’s context. Finally, write an eval that checks citations match their sources.

On your profile: when reading job descriptions, look for phrases such as “production-ready integrations” or “prototype to production”. On a CV, a line like “took a web-search agent to production, measured citation accuracy on a set of 20 questions” carries far more weight than a line listing libraries. A small repo with URL logs and a scoring table makes it more convincing still.

Agents will increasingly have to read the web before they answer. The people who get paid are the ones who make that reading trustworthy, not the ones who write the first API call.