I’ve included whiteboard images below to make the big blocks of text easier to digest, focusing on FDPE’s, Private Equity, and Startup Founders as an audience.

1. We’re in a massive paradigm shift

2. Paradigm shifts require a Research & Development (R&D) approach

3. Consultant FDPEs are uniquely suited to execute R&D with Clients, because they learn the macro lessons across clients and are closest to the actual users

4. The role of Software Engineer is transforming into FDPE because execution is increasingly being handled by capable systems

5. Feedback loops define success or failure for all software endeavors

6. Execution was never the hard part of Engineering, building the right thing is the hard part, and embedded product-focused engineers have tight feedback loops

What FDPEs Need to Know

The role sits at the intersection of an embedded consultant and a product engineer who can operate probabilistic systems, and in mid-2026 three skills carry the weight.

AI-augmented (Cybernetic?) Execution

1. One engineer, one agent, one control loop: a persistent Hermes agent (Nous Research) extends the engineer’s capacity rather than replacing their judgment, and because the pairing is one-to-one, responsibility never diffuses. The engineer remains the governor of the system, answerable for every action the agent takes.

2. Speed does not come at the cost of rigor: verification and adversarial testing are preserved at the higher velocity rather than traded away for it.

3. The forward deployed distinction is the exit: effort should decline across successive deployments as the client team takes ownership, because flat effort is the signature of a dependency and declining effort is the signature of a transferred capability

Eval Engineering, above Everything Else

1. It is the discipline that separates the role from “a developer with AI tools.” Anyone can wire up a model; few can prove it works on a system that behaves differently every run.

2. The workflow is concrete: read production traces, build an error taxonomy from real failures, stand up a golden set of test cases, align an LLM judge with human review until they agree, and wire eval thresholds into release gates so a regression blocks a deploy.

3. The forward deployed engineer leaves the suite behind as the client’s instrument for keeping the system honest after the engagement ends.

Full-loop Ownership with Customer Context

1. They own the whole path from user problem to production behavior, and it starts before any code: sitting with lighthouse users to understand the actual problem rather than waiting for a spec.

2. The job is to define a testable goal, not “build a chatbot” but “cut time-to-first-draft from 40 minutes to 8 with at least 0.92 task success and under 1% hallucinated citations,” then instrument telemetry so the shipped system reports task success, cost variance, and user-trust signals.

3. Being forward deployed means doing this inside the client’s actual workflow and constraints, not from a spec handed across a wall.

What Private Equity needs to Know

The forward deployed AI product engineer is the unit of real AI capability inside an asset, and the same three skills that define the role map directly onto three things a buyer underwrites: whether the AI is provable, whether it is tied to a business outcome, and whether the capability stays with the company after the check clears.

Eval Engineering is your Proof-of-Function

1. The eval suite is the artifact that tells you whether the AI works, and it is durable IP the portfolio company operates long after the engagement ends.

2. A team with per-category pass rates and release gates that block a bad deploy knows whether its system holds up; a team that can only show a demo does not, and does not know that it does not.

3. In diligence, ask to see the eval suite. Its presence or absence is the finding.

Outcome-scoped Ownership is what makes the ROI Real

1. Work scoped to a measurable business metric is work you can underwrite: cut time-to-first-draft from 40 minutes to 8, hold task success at or above 0.92, keep hallucinated citations under 1%. “Build a chatbot” is not.

2. Telemetry on task success, cost variance, and user-trust signals lets you measure the return continuously rather than taking the demo on faith.

3. It is also how you catch an AI line item that quietly erodes margin before it shows up at exit.

Capability Transfer is the Exit Signal

1. Watch how the consulting bill changes over time. If the hours shrink with each project, the team has learned to run the system itself, and that capability is now part of the company you own.

2. If the hours stay flat or climb, you are buying a dependency, not a capability. The company cannot run the system without the consultant, so what looks like an asset is really a liability you can never stop paying for.

3. The engineer worth paying for bills on value delivered vs. hours. Systems do require maintenance long term, but there should never be ‘tokenmaxxing’.

What Startup Founders need to Know

The forward deployed AI product engineer is the role that turns “we use AI” into AI your customers actually trust, and for a founder the same three skills answer three questions: can you ship AI that works, is it moving a number that matters, and will your own team own it before the cash runs out.

Eval Engineering is what lets you Ship AI you can Stand Behind

1. The eval suite tells you your AI works before a customer finds out it doesn’t. Without it you ship on vibes and learn about failures through churn or a frozen demo in a board meeting.

2. With per-category pass rates and release gates that block a bad deploy, your small team keeps improving the system without a specialist hovering, and you can answer the “how do you know it works” question investors increasingly ask in a raise.

3. Whoever builds your AI, insist the eval suite stays with your team.

Outcome-scoped work is how you Protect Runway

1. Scope every AI effort to a number that matters to the business: activation rate, time-to-value, support cost per ticket, not “add AI.”

2. A feature scoped to “cut time-to-first-draft from 40 minutes to 8 at 0.92 task success” either moves the number or it doesn’t, and telemetry tells you which within weeks, so you can double down or kill it before it eats a quarter of runway.

3. “Build a chatbot” has no kill criteria, which is exactly how AI projects quietly burn cash with nothing to show.

Capability Transfer is Survival, not just Hygiene

1. You cannot afford a permanent dependency on an expensive outside engineer. If you bring in a fractional or forward deployed person, structure it so their effort declines while your team takes over, with the goal that in a few months your people run the system without them.

2. The real first question is usually whether to make an AI hire at all. You should be working backwards from the goal/user pain to the technology, not the other way around.

3. The engineer worth hiring works to make themselves unnecessary; if the hours never drop, you have bought a cost center, not a capability.

Conclusion

The forward deployed engineer, the PE buyer, and the founder are asking the same three questions in different dialects: can you prove the AI works, is it moving a number that matters, and does the capability stay when the engineer leaves. Evals answer the first, outcome-scoping answers the second, and capability transfer answers the third.

That convergence is not an accident. We are early in a paradigm shift, and in a paradigm shift execution is the part that gets cheap first. Capable systems now write most of the code, which means the old proxies for engineering value, shipping fast, writing a lot, looking busy, have stopped carrying information. What does not get cheap is knowing whether the thing works, knowing it is the right thing, and making sure the people who own it can keep it running. Those are feedback-loop problems, and they were always the hard part. Execution was never the bottleneck. Building the right thing was.

The forward deployed AI product engineer is the role that forms around that truth. They sit closest to the user, run the tightest feedback loop, and carry the macro lessons from one client to the next, which is exactly the posture R&D demands when nobody yet knows the right answer. For the founder, that is who you hire, or deliberately decide not to. For the PE buyer, that is the capability you are underwriting. For the engineer, it is the work worth getting good at, because it is the part the machine does not do for you.

The model can write the code. It cannot tell you whether the code was worth writing. That gap is the job.

Professional services are specialized services provided by skilled professionals to help businesses solve complex problems. These services typically involve expertise in areas like consulting, legal counsel, and accounting to name a few. Their core value comes from skilled human capital performing language-intensive, knowledge work.

Who is General Catalyst?

For those of you unfamiliar, General Catalyst (GC) is an “investment and transformation company”. This label is purposefully broad as they’ve borrowed strategies from both private equity and venture capital, while pioneering some of their own. They command over $30B in assets under management, and their portfolio included some of the most successful tech companies (e.g. Airbnb, Stripe, Snap).

What are AI-Enabled Roll Ups?

In August of this year, General Catalyst published an article titled “The Future of Services” which explained their AI-enabled roll up strategy. Here’s the TLDR of their strategy in 6 steps:

1. Identify a Legacy Service Sector: Target fragmented, traditional service industries (like property management, insurance, or accounting) that haven’t been meaningfully transformed by AI.

2. Assemble the Founding Team: Build a team combining three critical capabilities:

   • AI technologists with deep applied AI experience in that vertical

   • Industry experts who understand legacy service business pain points

   • Operators with proven M&A and integration experience

3. Build the AI Foundation: Develop applied AI tools that dramatically improve service delivery, delivering measurable change to profit (EBITDA margin).

4. Acquire Service Businesses: Acquire existing service companies in the target sector through M&A.

5. Integrate and Transform: Apply the AI tools to acquired businesses, transforming replicating the dramatic improvements to service delivery.

6. Scale Through Additional Acquisitions: Use the now proven playbook to acquire more companies, creating compounding growth while maintaining operational excellence.

They also revealed they have already put this strategy to work across at least 9 portfolio companies over the past 3 years and have achieved amazing results:

“The companies we back aim to take businesses growing in single digits to 10-20% growth through a combination of organic capability-led growth and acquisitions. They simultaneously aim to double profit margins, often targeting 30-40% margins. They are setting their sights on a new Rule of 60 standard.” - GC

What’s the “Rule of 60”?

The Rule of 40 is a key benchmark for SaaS businesses, stating that a company’s year-over-year revenue growth rate plus its EBITDA margin should equal or exceed 40%.

The idea is that a financially strong SaaS business should balance rapid expansion with profitability, and achieve net 40% growth across both for any given year. GC’s proposed Rule of 60 is a complete game changer, setting a significantly higher bar for their portfolio companies and investors’ expectations.

“Double-digit growth and operational efficiency are no longer a tradeoff; they reinforce each other. By expanding service capabilities and capacity, unlocking markets that once looked unreachable, and setting new standards of customer experience, these businesses are creating a new baseline for what services can achieve.” - GC

Why Professional Services?

The professional services sector represents one of the largest and most compelling opportunities for AI-enabled transformation. This broad sector encompasses legal, finance, insurance, accounting and many other industries, commanding a combined $3.1 trillion in annual revenue. Although a diverse category, what all members share is a breadth of language-intensive, knowledge work that AI is uniquely positioned to transform. The 2023 study from Felten et al. systematically ranked which industries face the highest exposure to AI language modeling capabilities. Reflecting on GC’s article, the top 10 results are striking:

• Legal services #1

• Financial services #2

• Insurance agencies, funds, and carries ranked #3, #4, and #7 respectively

• Private credit #5

• Talent agents #6

• Alternative investments #8

• Accounting #9

• HR #10

Further validating the potential for professional services, the recent 2025 MIT Iceberg Index highlighted these same industries as the opportunity 5x larger than today’s visible AI adoption.

Sizing The Opportunity

• The Iceberg Index’s estimates the professional service occupations value at $1.2T

• Orb’s SaaS value-based pricing formula reports 10-20% conservative value capture

• The Professional Services’ AI Opportunity Conservative TAM = $120B - $240B

The professional services opportunity isn’t speculative, it’s validated by academic research, quantified by MIT, and already being executed by sophisticated investors like General Catalyst. The $1.2 trillion in occupational exposure identified by the Iceberg Index represents real labor value sitting in fragmented, legacy industries that have remained largely untouched by technology for decades.

What makes this moment different is the convergence of three forces: AI capabilities that can finally perform language-intensive knowledge work, a proven transformation playbook pioneered by GC’s portfolio, and fragmented markets ripe for consolidation. The Rule of 60 isn’t aspirational—it’s already being achieved by companies that combine AI-first operations with disciplined M&A.

For investors and operators watching from the sidelines, the window is narrowing. General Catalyst has a three-year head start and $30B in capital to deploy. The firms that move now to partner with the right AI teams will define the next generation of professional services. Those that wait will find themselves either acquired or outcompeted by AI-native players delivering superior service at a fraction of the cost.

About Rosenblatt

MIT also reports that partnering externally on AI-first products brings them live 6 months sooner and twice as successfully as internal builds. Rosenblatt specializes in AI transformation for mid-market, tech-enabled, professional services. We bring together AI leaders from big 4 consulting firms and founders from exited AI startups to lead companies from AI pilots to complete transformations. Click below to schedule a 30-minute meeting with our CEO and founder.

Book a Meeting

In late March of 2025, Rosenblatt founder and CEO, Ryan Walden, lead a one day, in-person consultation with Jordan Conley, ProService Head of Strategy and Technology, and Mikaela Ferguson, Director of AI Product.

48 hours after the meeting, the Rosenblatt team returned a 3-month pilot plan with comprehensive JIRA tickets and a clear path to AI-enabling ProService’s new client onboarding process, named “Fridai”.

Fridai

3 months later, the Rosenblatt team delivered an AI-assisted, self-service onboarding experience for new clients, eliminating several onboarding calls from ProService’s existing process. This solution includes both an onboarding web application, and an internal dashboard for adding new clients and tracking their self-onboarding process. By using information collected during client sales calls, our AI agents could pre-fill 80% of all new client onboarding details before they even start their onboarding. By December, all 75 new ProService clients had successfully self-serviced their onboarding without any human intervention.

5/22/26 Update: 190 clients onboarded, over $1M lifetime value recaptured.

ProPilot

After success with Fridai, the Rosenblatt team expanded into new projects outside of onboarding. Tasked with improving the ProService call center’s first call resolution (FCR) rates, Rosenblatt launched a new AI agent called ProPilot in only 3 weeks. By week 4, call center employees are already providing incredibly positive feedback, and observed FCR increases by +20%.

4/15/26 Update: 71 average WAU; strong correlation of +0.64 WAU to FCR.

About Rosenblatt

MIT reports that partnering externally on AI-first products brings them live 6 months sooner and twice as successfully as internal builds. Rosenblatt specializes in AI transformation for mid-market, tech-enabled, professional services. We bring together AI leaders from big 4 consulting firms and founders from exited AI startups to lead companies from fast pilots to complete AI transformations. Click below to schedule a 30-minute meeting with our CEO and founder.

Book a Meeting

A recent Harvard Business School working paper provides data-backed evidence that “private equity investors function as strategic capital allocators, adjusting their investment approaches in response to technological shifts”. Yet, in EY’s Q3 PE Pulse report, allocations to healthcare, a sector with notoriously strict AI safety standards and regulations, more than doubled year to date. This trend is not unique to Q3, but is instead a thematic pivot of 2025 overall. In reaction to tariff uncertainty, PE has focused latest investments into essential services (e.g. healthcare, utilities, infrastructure), many of which are human labor intensive, physical asset driven, and highly regulated. Because of this, the occupations that underlie these services rank at the very bottom of exposure to agentic AI. Despite strategic reorientation towards traditionally safer industries, PE is also rapidly gaining a track record of failures within these sectors as research by S&P Global found these sectors responsible for 56% percent of H1 2025 bankruptcies.

As essential services have become the primary focus, technical leaders within PE have felt side-lined as a result. Many of PE’s digital leaders neither see the opportunity to usher in agentic transformation to these new investments nor have been issued a clear mandate to guide AI transformation within the existing portfolio. As a result, many leaders are departing to start their own AI-first companies. Moreover, these positions frequently go unfilled, with Bespoke Partners recently reporting that demand for C-suite and VP-level digital leadership in the second half of 2025 significantly exceeds available supply. Without playbooks, and losing leaders, the options are quickly waning.

Meanwhile in big tech, the race towards deploying AI agents continues to gain momentum. Current solutions are already fulfilling the promise of human-like intelligence with major players like IBM automating 94% of their routine HR tasks and confirming mass layoffs as a direct result. This leaves tech-enabled portfolio companies increasingly anxious of the growing AI-first innovation in both startups and big tech. Portcos in professional services such as insurance, legal services, and HR are most exposed. These sectors spend ~50% of revenue on knowledge workers, the exact roles agents are well positioned to automate. Under this immense pressure of exposure and lacking AI leadership, these companies attempt their own internal AI agent transformation initiatives. Unfortunately, most lack specialized AI engineering talent and their internal teams are already lean, stretched thin on managing existing systems. Pair these shortcoming with the now infamous report from MIT, and the odds for success average well below 5%.

This is creating a strategic inflection point, with the wrong choice ending in the demise of PE’s reputation as leaders of digital transformation and accelerating bankruptcies in their most exposed portcos. By continuing to lack transformation playbooks, failing to retain top AI leadership, and filling their latest funds with less exposed sectors, they risk undermining the digital leadership LPs expect from them. The choice is clear: adapt now to harness agentic AI, or risk further losses and conceding reputation to a new wave of agile, AI-first competitors.

About Rosenblatt

MIT reports that partnering externally on AI-first products brings them live six months sooner and twice as successfully as internal builds. Rosenblatt specializes in AI agent transformation for mid-market, tech-enabled, professional services. We bring together AI leaders from big 4 consulting firms and exited AI startups to lead teams from agent pilots to full production-deployed agents. Click below to schedule a 30-minute portfolio AI exposure assessment with our founder.

AI Exposure Assessment

A Brief Recap of AI Engineering

For those who were working in AI prior to the release of ChatGPT, deploying a uniquely useful pretrained model without fine-tuning on curated data was extremely unlikely. A handful of embedding models, some CNNs, BERT, YOLO, and CLIP were the only regularly used, pretrained options that come to mind, pre-November-2022. In March 2023, software engineers quickly capitalized on the accessible APIs of ChatGPT to begin building their own GPTs, kicking off a wave of LLM-first software engineering. Now those same engineers are learning data science basics rebranded as “context engineering”. Simultaneously, data scientists who have spent years grappling with these complexities have had to revisit the way they approach new projects altogether, now no longer needing anything but a simple prompt to achieve intelligent predictions. The great news is that the solution to reconciling the slow nature of LLMs is answered by leveraging the middle ground between these fields: SLMs.

LLM-First Software Engineering

LLMs brought the unique capability of solving advanced intelligence problems through prompting alone. This has made the creation of data science applications increasingly more accessible to non-data scientists. The naive process for many software engineers has gone in three steps:

1. Prompt engineer to demo-able

2. Deploy upon stakeholder approval

3. Adjust prompts based on user complaints and new feature requests

This closely mirrors how software development (when lacking automated testing) has been occurring for years throughout enterprises, startups, and dev shops alike. As time has progressed, more sophisticated patterns have emerged:

1. Work alongside a subject matter expert to curate an evaluation dataset

2. Leverage experts + LLM-as-a-Judge for model selection and prompt optimization

3. Incorporate evaluations into CI/CD as an intelligence regression test

4. Deploy and collect real conversations to supplement the evaluation dataset

5. Add a Human-in-the-Loop tool for the LLM to ask a human to respond

6. Repeat steps 1 - 4

This is a far-improved approach over the naive process, but still lacks crucial steps learned from decades of real-world observations from traditional pre-trained data-science applications.

Traditional Data Science Applications

Before deep learning, traditional data science models were not pretrained; they existed only as algorithms to be fit to a dataset provided by the data scientist. The earlier deep learning models that were generally pretrained were incapable of domain-specific, human-like performance through prompting only. Therefore, the common phrase “a model is only as good as its data” was universally embraced among data scientists, until the inception of ChatGPT. Revising that data-first mindset, the traditional path to building a traditional data science application was as follows:

1. Have an application already creating real world data

2. Collect and curate a dataset (e.g. data engineering, cleaning, and sampling)

3. Define a north-star metric (e.g. precision, recall, NDGC, etc.)

4. Experiment with different model options

5. If pretrained:

   1. Prompt Engineer

   2. Fine Tune

6. If not:

   1. Train from Scratch

   2. Hyperparameter Optimization (e.g. Grid, Bayesian)

7. Evaluate against a holdout set on the north-star metric

8. Shadow deploy the top model and analyze real world results

9. If shadow performs well, deploy

10. Retrain or fine-tune on new data on a regular schedule (e.g. daily, weekly, monthly)

11. Deploy the updated model if outperforming existing

Notably, an important part of experimenting with different models is right sizing the model. Importantly, large models like transformers require GPU acceleration for high-speed inference, whereas smaller models such as XGBoost can run millisecond inference on a single CPU core. Because of the vastly different costs in self-hosting large vs small models, data scientists are pushed towards finding the most pragmatic balance between complexity, cost, and performance.

Solving The Hedonic Treadmill with SLMs

In late 2024, leading AI labs began reporting slowing improvements in their frontier models (Amodei, A., et al., 2024). Since then, researchers have increasingly demonstrated that Small Language Models (SLMs) with appropriate context engineering can outperform LLMs on the same task (Belcak et.al 2025). Notably, both SLMs and LLMs show similarly decreased performance on OOD examples when they are many-shot prompted (Wynter 2025). In the context of bringing intelligent applications to market, these facts and trends paint a clear picture of LLMs reaching their potential with marginal intelligence improvements lacking meaningful changes to the user’s experience. In accordance with the Hedonic Treadmill, as people become comfortable with the intelligence limitations of LLMs, they will begin to desire faster responses, and the universal truth will continue to remain that a smaller model will always respond faster than a larger model. Considering this, we must borrow from the learnings of traditional data science applications and begin applying them to LLM-first software engineering.

Here’s a suggested path forward:

1. Work alongside a subject matter expert to curate an evaluation dataset

2. Leverage experts + LLM-as-a-Judge for model selection and light prompt optimization

3. Incorporate evaluations into CI/CD as an intelligence regression test

4. Deploy and collect real conversations to supplement the evaluation dataset

5. Add a Human-in-the-Loop tool for the LLM to ask a human to respond

6. Repeat steps 1 - 4 with some tweaks:

   1. Do not over optimize the LLM’s prompt, only adjust as needed

   2. Continue heavy LLM-as-a-Judge prompt optimization of the SLMs

   3. Detect when a SLM outperforms the LLM

   4. Deploy the optimized SLM as the new default

   5. Add an LLM-in-the-Loop tool for the SLM to ask the LLM to fallback to

By reserving heavy automatic prompt optimization to the SLM, and keeping the LLM’s prompt highly generalized, you strike a pragmatic balance between complexity, cost, and performance. For In-Distribution data (ID, explained below) data you have the fast and cheap responses of the SLM and for Out-of-Distribution data (OOD) you have the LLM which has stronger generalization capabilities, and for the extraordinary scenario you have the human. In essence, a Russian-nesting doll of intelligence.

In Distribution - Queries and scenarios that closely match the patterns, domains, and types of problems the model was trained or optimized for. These represent the “expected” or typical use cases.

Out of Distribution - Queries that fall outside the model’s training distribution—novel scenarios, edge cases, or uncommon combinations of requirements that the model hasn’t been specifically prepared to handle.

Conclusion

If you are not already using this approach, I hope you consider it as your next step towards long term wins with your intelligent application. In some ways, we already see similar approaches being embraced by top foundation model providers such as GPT-5’s model router design (OpenAI 2025). Better yet, there is some very recent research from a fellow Atlanta local which concludes “this survey firmly positions SLMs as the default, go-to engine for the majority of agent pipelines, reserving larger LLMs as selective fallbacks for only the most challenging cases” (Sharma 2025).

Food For Thought

For those reading who are familiar with traditional data science or NLP, we can take this nesting doll pattern a step further. Frankly, some questions are truly best solved by simple FAQ responses. After deploying an SLM, you could begin a new pattern of progressively clustering high similarity prompt-response pairs into a general FAQ. When such prompts are sent, FAQ responses could then be retrieved by an embedding model with a high threshold, cosine-similarity match, with low scores escalating to the SLM to fallback to.

Thank you for your time and I hope you leave some feedback!