Tal Peretz

Co-founder of Runlayer

Overview

Tal Peretz is a co-founder at Runlayer [1][4]. Peretz's LinkedIn profile identifies them as Founder @Runlayer and Creator of Zapier MCP [3]. Peretz maintains a presence on X at @talperetz_ [5].

Career history

  1. FounderAug 2025 to PresentRunlayer
  2. Staff AI EngineerAug 2024 to Jul 2025Zapier
  3. Senior AI EngineerAug 2023 to Aug 2024Zapier
  4. Fractional Head of AIDec 2022 to Jul 2025AI & Human Labs
  5. CTO, FounderOct 2019 to Sep 2022Magical by Supertools
  6. ML EngineerSep 2018 to Aug 2019Simplex
  7. Staff EngineerJul 2017 to Aug 2018Panorays
  8. ML Engineering ManagerOct 2015 to Apr 2017Ofek 324 Unit - IAF

Education

  1. MBA, Technology at Tel Aviv University2014 - 2016Education
  2. BSc (Accelerated Study), Mathematics and Computer Science2012 - 2013Ben-Gurion University of the Negev

Insights & ideas

The through-line

Across every conversation Tal Peretz returns to one argument: generative AI has not made selling easier, it has made it harder, and the only durable answer is better data underneath the model rather than more model on top of thin data. "AI basically makes sales in general much harder, not easier, because the noise to ratio right now basically go up" [2]. When ChatGPT landed and every vendor raced to bolt AI features onto existing products, he took the opposite route and spent months building what he calls the Onfire knowledge graph, the data layer that the AI workflows would later sit on. "This is probably you know the main IP of the company," he says, "and it took us a lot of months to you know bringing into the quality levels and the programs that we wanted to be, but once we have that in place and you learn on top of that the AI workflows this is where the true magic started" [2]. The payoff is stated simply: "now your AI is not generic. It's within your context with the right data" [2].

The second half of the through-line is narrowness. Rather than building a horizontal go-to-market tool for anyone with buyers to find, he picked the hardest audience in the market on purpose, companies selling to technical buyers, and treats that constraint as the source of advantage that competitors cannot copy [1][2]. The two commitments reinforce each other: a vertical audience makes a specific, deep data layer possible, and the data layer is what makes the vertical defensible. Everything else, the outbound tactics, the hiring bar, the product roadmap, follows from those two decisions.

On why the technical buyer is the right hard problem

He and his co-founders, Nitan and Shahar, deliberately chose the audience most resistant to being sold to. CTOs, CIOs and CISOs are "probably the toughest buyer out there," people who "have resistance to salespeople in general" and "always prefer to explore and working with the technology first" [2], "the ones that always prefer to build versus buy" [3]. He accepts the premise rather than fighting it: they "only want to be approached if they have a problem which makes sense" [4]. Having been a CTO himself, he treats that resistance as legitimate rather than an objection to be overcome [2].

The reason this audience is workable is that its resistance to sales coincides with unusual visibility. "At the same time they have probably the biggest public footprint," he says, and that footprint extends past the C-level to entire teams talking with peers about day-to-day problems in Reddit, Discord, X, Stack Overflow and Slack communities [2][3]. That is where the founding question came from: "What if we will know what the 50 million engineers are doing on a daily basis based on their public footprint" [2]. Because these buyers are not in the same places as everyone else, generic tooling misses them, and a vertical solution built on community and public-web signal has room to win [1][2].

On what context actually means

Context is his most-repeated word, and he is precise about what he means by it, because most teams think they already have it. "We have a term in the in the company that context is the king right now" [2]. It is not knowing a persona's generic pain points; it is "the ability to know each data point that you can dream of": which projects an account is running now, what problems they have, what the competitive landscape inside the account looks like, what they have in place today, when renewal cycles fall, and who actually sits on the buying committee, the champion, the influencer and the buyer for that specific product [3]. He warns that org charts mislead, "those titles are misleading because it can be like the head of security, but maybe your specific budget line is, you know, under the IT director" [3].

His sharpest illustration of context failure comes from an early customer using a leading technographics vendor. The customer cared about the security stack, cloud security and endpoint security, but the tool returned things like "hey, they're using Salesforce" and "hey, they're using HubSpot," data that is technically true and completely "out of context" [2]. The cost is double: missed revenue, and reps burning time on research to work out what is actually happening in the account. Once the same accounts ran through Onfire, they could see which cloud security and endpoint vendors were in place, "because this is what drive you know the revenue for them," and the whole organisation could become "laser focused on the goal" [2]. He is blunt that this has stopped being optional: what used to be a nice-to-have is now a must-have, and even the biggest enterprises are still leaning on what worked before without noticing the game shifted. "If you don't have this context and you don't have this visibility and you don't understand what is actually happening, you're going to lose the deal to the one that actually, you know, understand what's happening inside the scene" [3].

On building the data layer before the AI

The sequencing is the contrarian bet [5]. Rather than start from features, the team started from research, interviewing 275 revenue leaders before writing code, and heard consistently that existing tools were good but "not giving them the edge that they need" [2]. Only then did they build. He notes a structural advantage in their choice of source material: because the signal comes from the public web, there was no cold-start dependency on customer data. "We didn't need any you know customers data and we can start it by looking into the publicly available data," and once there was something to show, "it was pretty compelling starting from the beginning" [2].

Trust in the data is treated as a product requirement, not a footnote. One of the biggest problems he saw at the outset was that "people use a lot of tools that help them find great data, but they had a lack of understanding how they can trust it and on which data point is actually been built on" [3]. Onfire's answer is to show the rep the underlying public data points with full evidence, so they can see the Reddit post or the Slack thread behind the claim, query it in free language, and act on it inside existing workflows in the CRM and sales engagement platforms [3]. Architecturally he describes three layers: an AI engine surfacing public community data, ingestion of the customer's own history of past engagements, meetings and call transcripts, and a drafting layer that composes messaging from the relevant data points [4]. The agent experience on top is the piece he is proudest of, a ChatGPT-style interface carrying "the power of the entire organization context," where a rep can ask for in-market buyers with a given problem and get an enriched, fully contexted list back [4].

On the buyer's experience, and who not to approach

He frames the whole product as improving the buying experience, not just seller efficiency, "a win-win situation from both the seller and the buyer perspective" [4]. The contrast he draws is between the daily generic pitch, "hey, I am a salesman at ax, we are working with industry this and that," and outreach that knows you were in touch two years ago and that you are looking at a security solution right now [4]. The result is a buyer more open to the call who "will appreciate the research and he appreciate that his time is valuable" [4]. His favourite proof point is a friend, now a CEO, who took a meeting purely because he was impressed by the rep's research, and the rep turned out to be an Onfire user who said he knew everything about him and understood his pain [4].

The most interesting behaviour was one they did not design for. As usage grew from the first hundred users into the thousands, customers began using the intelligence in reverse, to work out who not to engage: accounts already using a stronger competitor, or where the chances are poor, so effort can be concentrated where it will pay [4]. He was candid that this surprised the team and is something they now need to examine internally [4].

On keeping AI output human

He built the company on a human-in-the-loop approach from the start and treats the machine's tone as an engineering problem [4]. Two mechanisms sit behind it. The model was trained on what good, human-sounding email looks like, drawn from tens of thousands of emails shared by customers [4]. On top of that sits what he calls "a human guard rails" layer, an additional pass of AI that pushes the output to feel more human, on the belief that recipients read AI generation in the subtext of a message [4]. The rep still adds their tone, tweaks and sends [4].

How far a company can push toward autonomy depends on its maturity, not on the tool. Some customers run fully autonomous motions, training the model to write like their top account executive or marketer and pushing on autopilot from data point to engagement; others keep a human reviewing the data, checking the draft and adjusting before it goes out [3]. He is explicit that AI agents deserve the same treatment as new hires: "The same way we treat our like reps, and we do some onboarding and training, in the AI era, we need to do the same for those AI agents" [3].

On becoming AI-native

He sorts marketing organisations into three tiers. The first still treats AI as a chat assistant, occasionally asking ChatGPT or Claude a question. The second has taken a single workflow, ads campaigns or prospecting, and automated it properly, working the prompting, setting up the environment and connecting it to HubSpot or Salesforce until it works. The third and most advanced are building their own applications: he describes two VPs of RevOps in a single week using Cloud Code hooked into Outreach, one of whom built an agent living inside the company Slack that queried Outreach on the back end [3]. His reaction was to tell that person he was at the cutting edge and that there would be a job for him at a company building these products [3]. He expects more marketers and sales reps to move to the building side, "because you know best what you need right now on top of the best context and data layer" [3].

For a small or early-stage company without budget or a rich data ecosystem, his advice is to start the culture anyway: automate a couple of small pieces of the workflow, build your own agents on the specific platforms you care about, tie them into other systems, and be ready for the next phase [3]. He practises this internally. Onfire's marketing and outbound team is small but generates the pipeline he would expect from five times the headcount, which he attributes directly to the data-first foundation plus agents that decide which account to go after next, taking each rep to roughly ten times their daily output [3]. In his view, "today this is probably the best time to start a company or build a company" [3].

On results, and why quality beats volume

The headline number he gives is roughly 4x new pipeline generated with the same headcount, but he insists the point is not volume alone [2]. Quantity and quality move together: finding the right buyers at the right time, with reps who understand the full context, produces more pipeline that also converts better, and the edge is compounded by competitors not doing it [2]. On engagement, he puts the minimum uplift in response rate and meeting rate at around 4x, with the best customers reaching something like 8x, while noting it depends on style, maturity and data domain [4]. Those engagement statistics are the leading indicator he tells customers to watch, specifically whether people are receptive on the call and whether email replies come back positive, as the early sign that the pain points and messaging are landing [4]. Underlying all of it is a customer-first stance: "we are not here just to build a cool technology or provide a cool product. We really want to put customer you know in the center of everything and make sure that they having and getting the value out of it" [4].

On going to market without a budget

Being vertical also changes how you can sell in crowded rooms. At an early AWS re:Invent with 500 vendors and 70,000 attendees, the three co-founders skipped buying a booth entirely and worked the floor instead [2]. The insight was about timing within the event: day one is peak energy, everyone is booking meetings and taking leads, but as the four days progress attention declines, and that is the moment to walk up to a specific booth, introduce yourself, ask for feedback and offer a 30-second demo tailored to that vendor's needs on an iPad [2]. Three days of that produced almost 200 meetings, and he estimates the team has now done close to 100 conferences in three years [2]. His conclusion: with a narrow focus "you can do pretty amazing you know stuff to jump above the noise without a big budget" [2].

He is equally frank about what did not work at first. The demo made "the classic mistakes of um technical founders": "We have been raving on our features and unique capabilities and and all that and and honestly people don't care about it" [2]. He also pushes back on the reflex to do everything at scale, since the goal is finding "the needle in the haststack" rather than mass output [2].

On hiring

He describes the company as permanently in hiring mode across engineering, finance, sales and marketing, and names three criteria in order [3]. First, values that match the company DNA: "we are looking for winners. People that used to win in the past and want to win in the future," independent of any AI experience [3]. Second, one question that exposes creativity: "What have you built or done with AI in the past 6 months?" That single answer separates people who occasionally ask ChatGPT something from those using it daily, building and shipping. What he is testing for is the instinct to automate one's own work unprompted so as to take more deals and build more pipeline, and he is happy if the example is personal rather than professional, even an internal system for family daycare shifts [3]. Third, coachability: people who want to win and understand technology but "know how to listen and, you know, to improve" [3].

On what drives him

Asked what gives him energy, he named family first, then building Onfire and taking the product to market [2]. The specific motivation he attaches to the work is changing the customer's point of view: in a crowded go-to-market technology space where buyers "mainly you know heard everything" from vendors and never got the transformation they were promised, the founding promise was to do it differently [2]. He frames the broader opportunity in the same terms, helping companies and people get a much better buying and shopping experience, which he calls "the lifetime opportunity that we have today" [4].

Takeaways

  • AI has raised the noise floor rather than lowered the effort: "AI basically makes sales in general much harder, not easier, because the noise to ratio right now basically go up" [2].
  • Build the data layer before the AI. Months went into the Onfire knowledge graph so that "now your AI is not generic. It's within your context with the right data" [2].
  • Choose the hardest vertical deliberately. Technical buyers resist sales but have the largest public footprint, in Reddit, Discord, X, Stack Overflow and Slack communities, which makes them addressable [2][3].
  • Context means account-level specifics, current projects, competing solutions in place, renewal cycles and the real buying committee, not generic persona pain points, and job titles mislead about where budget sits [3].
  • Show the evidence. Reps must see the underlying public data points to trust the output, because most tools give good data with no basis for confidence in it [3].
  • Treat AI agents like new reps: onboard them, train them, set a quality bar, and add a "human guard rails" layer so messages do not read as machine-generated [3][4].
  • Hire for winners, coachability, and one diagnostic question: "What have you built or done with AI in the past 6 months?" [3].
  • Narrow focus substitutes for budget: no booth at AWS re:Invent, tailored 30-second demos as attention declined across the event, nearly 200 meetings in three days [2].

Media & appearances

In the news

This page shows public professional information only, each fact cited. Is this you? send a correction, or ask for removal within 24 hours, no questions asked.