Steam factories were built around a single power source: one engine turning an overhead line shaft, belts dropping to every machine, layouts dictated by power instead of workflow. When electricity arrived, owners swapped the steam engine for one big electric motor on the same shaft. Same layout, same belts, same everything. Result: marginally cheaper power, flat productivity. A 2x mindset.

The real unlock was that electric power could be distributed. A motor on every machine (”unit drive”) made the shaft unnecessary, and everything the shaft dictated became negotiable. Factories went single-story, machines were arranged around the flow of work, downtime collapsed, and the assembly line became physically possible. That redesign, not the motor, drove the 1920s productivity boom.

Why thirty years? Sunk capital in existing factories. A generation of engineers whose expertise was optimizing the old architecture. And a hard truth: the gains couldn’t be captured machine-by-machine. The factory was the unit of change. Mostly, new factories built from scratch got there first.

Today’s line shafts aren’t steel. They’re process: handoffs, ticket queues, role definitions, reporting structures, all built around the old constraint that human attention was the only engine. Bolt AI onto that and you get real but incremental gains, which is why the corporate AI conversation keeps collapsing into “how much headcount can we save?” Cost savings on personnel is the 2x paradigm. And just like 1895, the company, not the tool or the department, is the unit of change.

The Rosenblatt thesis. Rosenblatt is an AI engineering services firm built on one decision: we are the factory being redesigned around the engine, not a firm bolting it on. Concretely:

• Outcome & product focused. Every engagement runs on KPIs and North Star metrics that tell us objectively whether AI is making the work better or worse.

• Engineers out-compete via compounding internal platform. Our engineers work on an internal platform that compounds with every engagement, making each Rosenblatt engineer distinctly more capable than an equivalent engineer alone.

• Opportunity over headcount arithmetic. With startup clients shipping AI MVPs and mid-market clients standing up pilots, we optimize for what AI unlocks, not what it replaces.

• Full ownership top to bottom. We recognize the dangers posed by over-reliance on suppliers & runaway token expenses, the company is built for full cost control.

• An individual lacks the team dynamic, an enterprise is too rigid. A single team iterating is the beginning, which can be scaled up iteratively through success and failure.

Why small is structural. Incumbents aren’t choosing the 2x paradigm out of a lack of imagination; they’re locked into it by scale, sunk process, and quarterly commitments.

History says redesigned factories were mostly new factories. Rosenblatt is small on purpose: we iterate at the company level (delivery model, workflows, metrics) in weeks, not fiscal years. You can’t easily grow a 100x organism inside a 2x host, but you can partner with one.

• Clients get insights that are scar tissue from redesigns we’ve already run, without betting their own factory.

• Investors get an asset (compounding platform plus company-level iteration speed) that appreciates precisely because the market stays stuck in bolt-on mode.

Who drives it. The heroes of the 1920s weren’t electricians; they were industrial engineers who understood both the motor and the factory. Today’s equivalent is the systems engineer with AI and full-stack depth: someone who understands the models, the software, and the business system around both. They will be the primary drivers of the new model of company. Rosenblatt is where that kind of engineer is battle tested.

The brief. The electric motor was available for thirty years before the world realized the factory, not the motor, was the point. AI has been commercially available for about three. Everyone will adopt the engine. The only question is bolt-on or built-around, and how long you take to learn the difference. We’ve made our choice. If you want to see a company built around the engine, as a client, partner, or investor let’s talk.

Initial Consultation

Rosenblatt scoped a project for UScope, a property-damage inspection platform: give field inspectors a way to upload a batch of on-site photos, then use OpenAI's vision models to read every image and generate a complete damage report automatically. UScope handed over example assignment JSON and a detailed "scope checklist" for the report format, and Rosenblatt built the pipeline from the ground up.

Automated Damage Reports

Rosenblatt built the pipeline from the ground up: ingest the assignment JSON, enrich it with third-party data (like the property's year built), pass every photo to OpenAI to detect and describe damage, aggregate the results by room using each image's file path, and summarize everything into a single structure-wide report — covering details like roof pitch and the specific type of roof damage (granule loss, thermal cracking, etc.) — before generating the final PDF exactly to UScope's spec. The system runs on AWS: a FastAPI service handles requests and preprocessing, while an async Lambda function fans out the image calls to OpenAI in parallel, cutting response time for a 100-image report from 5 minutes down to just 8 seconds.

At full scale, the service can caption 335 images and generate 27 assignment summaries in about 30 seconds, at a cost as low as $0.0004 per caption — one real UScope assignment ran 168 images through the pipeline in a single batch. The hardest technical problem wasn't the pipeline logic, it was throttling: managing OpenAI's rate limits at that volume while keeping the whole batch fast. The team also had to rebuild around a client-side data breach that corrupted the first set of example images. A functional prototype was ready in two weeks, followed by two to three more weeks iterating on the exact PDF layout UScope wanted.

The captioning service was handed off production-ready: the FastAPI + Lambda pipeline running end-to-end against UScope's live assignment data, from image upload through to a finished damage report PDF.

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

Initial Consultation

Branch Politics is a free, nonpartisan app that walks voters through the elections and candidates in their area — breaking down who each candidate is, what they believe, and why it matters. Before working with Rosenblatt, Branch relied on a team of human data annotators to manually match candidate quotes to campaign topics. As Branch's revenue grew, that manual process couldn't keep pace with the volume of new campaigns and candidates, so they came to Rosenblatt to automate it.

Automated Political Topic Modeling

Rosenblatt's first approach was a fully unsupervised pipeline built on the BERTopic library: tokenize sentences from Branch's scraped candidate-page content, embed them, deduplicate semantically, reduce the embeddings, cluster them, and label each cluster using Llama 3 8B. Two things went wrong. The scraped web data was full of irrelevant boilerplate (privacy policies, terms of service), and density-based clustering kept collapsing into just a handful of clusters that didn't match how Branch's own team already organized political topics.

That led the team to a two-model supervised approach instead. First, a relevancy classifier: to fix a dataset skewed toward a handful of over-represented candidates, Rosenblatt built a custom sampling function, then worked with Branch’s own annotation team to label 1,000 sampled sentences as relevant or irrelevant. Because Branch needed to avoid ever dropping a relevant sentence, the team optimized for recall rather than raw accuracy — the final model hit over 90% accuracy and 90% recall, deployed via a pipeline of AWS Lambda functions and a SageMaker endpoint.

Second, a topic-matching model: given a relevant sentence, which political topic does it belong to? Early attempts using a stock Hugging Face model and a traditional single-label classification design (plus triplet loss) capped out below 40% accuracy — real campaign sentences often relate to more than one topic, which a single-label design can’t capture. The breakthrough was contrastive learning: fine-tuning the model on positive and negative sentence-topic pairs so it learns to maximize the contrast between matching and non-matching topics. That pushed accuracy to 92% on the internal test set and 88% on brand-new, real-world campaign data — deployed to a SageMaker endpoint supporting both batch and real-time inference.

Both models were handed off production-ready: the relevancy classifier running through its AWS Lambda pipeline, and the fine-tuned topic-matcher deployed to a SageMaker endpoint supporting both batch and real-time inference against new campaign data as it comes in.

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

“It has been a pleasure to work with the Rosenblatt Team. Their deep knowledge of AI, combined with their ability to adapt and tailor solutions to our specific use case, has been invaluable. The team’s expertise and flexibility have significantly contributed to laying a solid foundation for developing our application” - Mike Ha, CEO of ARTBAT LIVE

The Challenge

ARTBAT LIVE is a hybrid “Digital Art + Esports” platform hosting live 20-minute drawing battles, built around a core mission of artist empowerment: helping artists build portfolios, connect with clients, and turn their work into merchandise. As the artist community grew, manual tagging became a bottleneck on both sides of the marketplace; artists lost time keyword-tagging their work, and clients were limited to exact keyword matches that routinely missed relevant artwork. The scaling problem hid a second challenge: ARTBAT’s development team in Hong Kong needed senior architectural direction and prioritization to keep the build aligned with the CEO’s goals.

How We Worked

We worked backwards from the outcomes ARTBAT wanted to the tools that enable them; the fine-tuned CLIP model and full-stack AWS infrastructure were selections from a toolbox, not the starting point. Before committing to a full MVP, we used rapid proofs of concept to test whether the founder’s ideas were technically feasible; ideas that proved out were promoted to the roadmap, and ideas that didn’t were killed cheaply. We established KPIs and a North Star metric so that everyone, from the founder to the delivery team, shared one answer to the question that matters for any AI product: is the system improving outcomes or not? And as ARTBAT’s forward-deployed product engineers, we owned those outcomes; that included making the architectural and prioritization calls for the Hong Kong team and enforcing the policies needed to hit them.

What Shipped

Clients can now search by natural-language description (“a brutalist style with two men standing in front of a doorway”) or by uploading a reference image and get matched to artists based on the actual visual qualities of their work. Artists simply upload their portfolios; the system understands the work automatically. The MVP also shipped portfolio-level search for clients who want an artist with a history of similar work, and an Up & Coming Artists feature surfacing recent uploads on the landing page.

Full architecture details, including why we chose a fine-tuned CLIP model over an LLM, are available in the ARTBAT Technical Report.

Why This Matters for You

If you have a strong product vision but need senior technical judgment on architecture and prioritization, that’s the gap Rosenblatt’s forward-deployed product engineers fill. We ship alongside your team, de-risk ideas with fast proofs of concept, and instrument your AI product so you know whether it’s working.

If that sounds like your situation, click below to schedule a 30-minute meeting with our CEO and founder.

Book a Meeting

The Problem, Technically

ARTBAT LIVE’s discovery experience depended on manual keyword tagging. Artists tagged their own work; clients searched by exact keyword match. This failed in both directions as the community scaled. Tagging is unpaid labor that artists skip or do inconsistently, and lexical search misses relevant work whenever the client’s vocabulary differs from the artist’s. A query like “a brutalist style with two men standing in front of a doorway” returns nothing useful in a keyword system, no matter how well the artwork matches.

The requirement was semantic search: matching on what a query means and what an artwork actually looks like, with no tagging step anywhere in the pipeline.

Why CLIP and Not an LLM

We worked backwards from the outcome (clients matched to artists based on the visual qualities of the work) to the tools that enable it. Artist discovery is a similarity problem, not a generation problem, and that determines the tool choice:

CLIP encodes images and text into the same vector space. A client’s text description and an artist’s actual artwork become directly comparable vectors; similarity is a dot product, computed in milliseconds against the full library.

An LLM rebuilds the bottleneck we were removing. An LLM cannot compare a query against a million images directly; each artwork would first need to be described in words (captions or tags), reintroducing the tagging step with added latency and inference cost. The intermediate text also discards exactly the visual information (style, composition, palette) that clients search by.

Retrieval is cheap and predictable. Every search is an embedding lookup, not a generation call; there’s no sampling variance in results, latency is measured in milliseconds, and costs scale with uploads rather than usage.

The Model

CLIP (Contrastive Language-Image Pre-Training) is a neural network trained on image and text pairs. We fine-tuned it on style labels drawn from ARTBAT’s own community (for example, an artwork paired with the description “Naruto in chibi style”), so the embedding space reflects the styles ARTBAT’s clients actually search for.

An embedding is a mapping from images and words to vectors of real numbers, where distance corresponds to meaning; the word “brutalist” sits closer to a certain architectural style than to the word “vehicle.” Because images and text share one space, search-by-description and search-by-reference-image are the same operation under the hood.

The system works in three stages:

1. Train CLIP on style-labeled image and text pairs.

2. Create the image embedding database. Every uploaded artwork is encoded and stored.

3. Find digital art using text or images. Incoming queries are encoded and ranked against stored embeddings by similarity.

The Artist Workflow

1. Upload Art. Artists upload a portfolio of images, along with traditional metadata such as artwork titles, profile contact information, and website links.

2. Create Embedding. The CLIP model generates an embedding for each uploaded image; no manual tagging exists anywhere in this flow.

3. Store Embedding. The embedding and its metadata are stored as a single object in an AWS OpenSearch Service k-NN index.

The Client Workflow

A client query, whether text or an uploaded image, is encoded through the same model. The query embedding is compared against stored vectors and artworks are returned ranked from most to least similar. Each stored embedding carries metadata identifying its source image, so results resolve back to the artwork and the artist’s profile, contact information, and website; a search result becomes a client connection directly.

Pre- and Post-Filtering

Storing metadata and embedding vectors together in a single OpenSearch object enables filtered vector search:

• Pre-filtering applies filters before similarity ranking, effectively ranking a subset of the total vectors; for example, restricting to artists from a certain region before finding the best match.

• Post-filtering applies filters after ranking is complete, refining an already-ranked result set.

Features Built on the Embedding Infrastructure

Because every artwork lives in the index as a vector plus metadata, product features are queries rather than new systems:

• Portfolio-level search. Similarity ranks can be computed per artwork or aggregated per artist, exposed as a client-side filter for clients who want an artist with a history of similar work.

• Up & Coming Artists. A landing-page surface of artwork uploaded in the past thirty days, pulled from the same index.

Deployment

The model and search infrastructure were developed and deployed on AWS, with OpenSearch Service providing the k-NN vector index and filtered query capability. Model efficacy was measured iteratively through real user interactions against the KPIs and North Star metric established at the start of the engagement, so both the interface and the model were evaluated on whether they moved outcomes.

About Rosenblatt

Rosenblatt AI is an AI-native consultancy that builds production AI systems for startups and PE-backed portfolio companies. Our forward-deployed product engineers embed with your team, work backwards from the outcomes you want, and ship. From conversational AI to semantic search, we take products from proof of concept to production.

Have a similar challenge? Click below to schedule a 30-minute meeting with our CEO and founder.

Book a Meeting

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!