Yoav Naveh, Co-Founder and Co-CEO of Reindeer – Interview Series

Yoav Naveh is Co-Founder and Co-CEO of Reindeer, bringing experience building technology companies, scaling businesses, and investing in founders. Before Reindeer, he built ConvertMedia, continued his work within Taboola, and invested through INT3. His focus today is helping enterprises move from isolated AI deployments to agents that can handle complex operational work, learn from human expertise, and remain reliable as business processes change.

Reindeer develops enterprise AI agents for core operations across areas such as finance, supply chain, logistics, and shared services. Its platform combines workflow execution with expert feedback, evaluation, and human approval so agents can adapt to exceptions and evolving policies. In this interview, Naveh discusses the limits of engineering-heavy deployment models, how institutional knowledge becomes agent context, and the governance and measurement needed to reduce total human effort over time.

After building ConvertMedia, scaling within Taboola, and investing in other founders through INT3, what problem drew you back into building a company, and how did it shape your decision to co-found Reindeer?

The AI market was too exciting for us to watch from the sidelines. My co-founder Yair and I became very interested in the gap between how useful AI has become when we work with it individually and how difficult it remains for enterprises to adopt it at scale. The technology is advancing incredibly quickly, yet most organizations are still struggling to translate that potential into meaningful operational change.

AI will transform how companies operate, but getting there requires more than better technology. It requires leadership willing to rethink how work gets done and a practical way to bring AI into everyday operations without creating new layers of complexity.

That challenge shaped Reindeer. We built a platform that takes enterprises from their first agent to an entire herd of agents that learn from human feedback and improve over time. Our goal is to close the gap between AI’s potential and its real-world adoption, helping companies turn their core operations into an agentic AI workforce without having to rebuild or constantly maintain every agent.

You’ve argued that the forward-deployed engineering model risks turning enterprise AI into a labor-intensive services business. Where does embedded engineering create lasting value, and where does it become a dependency that prevents customers from scaling?

Forward-deployed engineers are valuable for complex integrations and getting initial agents into production. The problem begins when the work processes themselves change, and FDEs become permanently necessary to keep those agents doing that work running. Especially at scale. The FDE model works when you have 5 agents. It breaks down when you have a hundred agents.

If every new workflow or unexpected exception requires more engineering, you’re not scaling software, you’re scaling expensive human labor.

Most companies deploying FDEs claim their engineers eventually move on to different tasks. Enterprises should demand proof that is the case before signing a contract that requires FDEs. We’ve already seen how brittle RPA became as business processes evolved. We shouldn’t expect hand-built agents to be different.

Enterprise workflows often contain undocumented exceptions and conflicting practices across teams. How does Reindeer capture how work actually gets done while distinguishing useful institutional knowledge from habits that should not be automated?

Most enterprises have enormous amounts of institutional knowledge that isn’t documented anywhere. They’re kept in workers’ heads. Our agents begin with partial knowledge and learn through real cases, asking subject-matter experts for guidance when they encounter unfamiliar situations.

But learning from an employee doesn’t mean blindly replicating their behavior. Our system distinguishes individual exceptions from recurring patterns and proposes broader changes for human approval.

We’re not trying to automate every habit. We’re trying to turn valuable institutional knowledge into reliable intelligence without requiring engineers to anticipate every scenario beforehand.

Most agentic companies start with documenting, then coding the process by interviewing and meticulously looking at past data. But in reality the most effective way to learn a process is happening every time a new team member joins – they do not memorize a year’s worth of data or a 3,000 page SOP. They learn a few skills, see a few examples, start working, ask questions when they see something they do not understand, and build their knowledge. This is the process we built.

Agentic AI also gives companies the opportunity to reimagine a process instead of automating it as it stands. Human-only teams, rules-based automation, and traditional software each shaped processes around their own limits. With agents learning alongside experts, Reindeer helps enterprises rethink how a process should work, including which practices to keep, which to retire, and where agents and people each add the most value.

When you say Reindeer’s agents continuously learn in production, what actually changes: model weights, memory, workflow logic, or explicit policies? Could you walk us through an exception that teaches an agent to handle future cases differently?

What changes is the agent’s context and skills: the workflow logic, the policies, and the instructions on when to apply each one.

Take an invoice agent. It gets an invoice that’s 4% over the purchase order and can’t find a policy that covers it. Instead of processing it, the agent escalates to an expert. The expert explains that this supplier has an approved exception for fuel surcharges. The agent resolves that case, and the explanation is stored as context for that supplier only.

If the same type of exception comes up again with other suppliers, and other experts resolve it the same way, the system proposes a policy change, such as “fuel surcharges up to 5% are acceptable when the contract allows it.” That proposal goes through testing and human approval before the agent uses it. One expert’s answer resolves one case. A pattern across cases becomes a candidate for a new rule.

An employee’s decision may be appropriate for one customer or transaction without being suitable as a general rule. How do you determine when feedback should remain a one-time exception and when it should become a proposed policy change?

We separate resolving an individual case from changing how an agent operates going forward.

An employee might authorize an exception for one customer, but that doesn’t mean the same exception should apply universally. I would even argue two different employees may have a different resolution for the same customer’s exception. Our system evaluates the circumstances, identifies recurring patterns, reconciles contradictions and looks for potential conflicts with existing policies.

When there’s evidence supporting a broader change, we run the agent via our evaluation platform, a “Truman show” for agents if you will, and propose an update for human approval.

The goal is to learn from humans, not blindly replicate human decisions. Otherwise, you’re simply automating mistakes.

An agent can improve on recent cases while becoming less reliable on situations it previously handled correctly. What testing and approval process must a proposed change pass before reaching production, and how do you detect and reverse regressions?

Continuous learning without governance is dangerous, so every proposed change passes three safeguards: regression testing, human approval, and a confidence threshold that controls when the agent acts on its own.

Testing comes first, and it is harder than it sounds because operations work has no fixed answer key. We select representative cases from expert feedback, define criteria for comparing outputs, and replay those cases against both the current agent and the proposed version. Actions with side effects, such as sending an email, run in a simulator built from past runs, and test cases that no longer match current policy are retired. We’re able to measure a change’s true effect, agents have to believe they live in the real world, and their actions have real implications – a record inserted to SAP, or an email sent to a customer. That is the only way to build a true evaluation framework per agent.

A human manager then reviews the change, the evidence behind it, and the test results, and can approve, revise, or reject it. Nothing changes in how the agent operates until that approval.

The confidence threshold protects the business after a change goes live. The agent acts on its own only when its confidence clears the threshold, and anything below it goes to an expert. Operations teams tune that threshold themselves, so they can start conservatively and give the agent more autonomy as its track record builds.

If quality drops after a change, the system automatically tightens review thresholds so more cases go to experts, and their feedback surfaces the problem through the same loop that proposed the change. Every policy change is versioned, attributable, and logged, so a team can see what changed, who approved it, and why, and roll back to the previous version.

Reducing engineering work can still leave substantial work for operations teams reviewing exceptions and correcting agents. How do you measure whether Reindeer reduces the total human effort required, rather than shifting that effort to a different team?

The reality is that most companies already have a team of people doing this work manually. Our goal isn’t to shift that workload to another team, but to reduce it over time. We take the most experienced people from that existing team and empower them to teach the agent how to handle exceptions and make better decisions independently.

The problem with the FDE model is that it often moves work from relatively low-cost operational employees to expensive engineers. That’s not solving the labor problem, it’s making it more expensive. Reindeer doesn’t introduce engineers into that equation. Instead, we measure success by how much more work agents can resolve independently over time, and how much less human intervention is required across the entire process.

We track three things: the share of cases the agent resolves end to end without a human, the number of expert touches per case, and total handling time per case across agents and people combined. If the third number isn’t going down, we’re just moving the work around.

Could you take one deployment at Hellmann Worldwide Logistics or Papaya Global and explain what changed from launch through ongoing operation? What happened to accuracy, exception rates, turnaround time, and the amount of human intervention required?

Hellmann Worldwide Logistics is a great example of how agents can improve real-world operations over time. Their pricing team was spending enormous amounts of time manually processing shipping requests across emails, spreadsheets and other documents, often taking days to produce a quote.

We started with roughly 20 sample requests to understand the workflow and train the agent. From there, Hellmann’s pricing experts began working directly with the system, providing feedback and helping it navigate exceptions. We tracked accuracy and speed throughout testing and continued monitoring performance once the agent moved into production.

Today, routine requests are handled automatically, while more complex cases are escalated to the team. Critically, the agent recognizes when information is missing rather than making assumptions, allowing employees to intervene where their expertise is actually needed.

The result has been a reduction in quote turnaround time, with fewer manual data-entry tasks and more time for customer-facing work. Hellmann has also seen its quote win rate improve. The objective isn’t to eliminate humans from the process, but to continually reduce the amount of routine work requiring their intervention.

What have you learned about the limits of this approach? Which characteristics of a workflow indicate that it is ready for an adaptive agent, and which suggest the business should first redesign the process or retain conventional automation?

Not every process needs an AI agent. The strongest opportunities are repetitive, high-volume workflows that require contextual judgment, particularly where information spans multiple systems and employees regularly handle exceptions.

The clearest lesson from our deployments is that a new function is emerging inside enterprises, much as revenue operations emerged with CRM, and Dev Ops with Cloud. As companies move from a few agents to a herd, they need a person or team that manages agents the way a department head manages a workforce: accountable for their KPIs and ROI, deciding where agents should take on work and where they shouldn’t, and approving how they change. The companies already building this function are moving fastest, and they are the ones positioned to win.

Conflicting practices are not a reason to wait. Experts disagree in almost every operation, and our system is built to surface those contradictions and turn them into policy proposals. Resolving them is part of that owner’s job, which is another reason to establish the role before scaling agents.

There is also a limit to the approach itself. Core operations will not be fully automated, and we don’t aim for that. Agents expand their coverage gradually, and high-risk cases stay with people by design.

As foundation models and agent-building tools improve, which parts of enterprise deployment do you expect to become commodities, and where is Reindeer building an advantage that becomes stronger with each production deployment?

Foundation models will become increasingly interchangeable as they get cheaper, faster and more capable. Building basic agents and connecting them to enterprise systems is also already becoming easier.

But building an agent isn’t the same as making it reliable inside a complex business, over time.

The real competitive advantage is the proprietary knowledge of how an enterprise actually operates, which is a moving target. Every production case gives our agents an opportunity to learn, resolve future exceptions and reduce human intervention.

Models will get cheaper. Building agents will get easier.

The winners will eliminate the expensive human engineering infrastructure required to keep those agents working and relevant over time.

Thank you for the great interview, readers who wish to learn more about adaptive enterprise AI agents, operational automation, and human-guided learning should visit Reindeer.