Cleaning up the "legacy code mess" for Agents is becoming a lucrative business.

Enterprise procurement of Agents is becoming increasingly accessible.

OpenAI, Anthropic, Google and Microsoft are all vying for enterprise customers, while SaaS companies including Salesforce, ServiceNow and Workday are busy embedding Agents into every product page.

It can be said that purchasing an Agent itself is no longer a difficult problem. But when enterprises actually try to deploy these Agents, new issues arise:

Buying an Agent does not equal getting the Agent to work.

US mortgage company CMG Financial has encountered such a dilemma: its Chief Strategy Officer Paul Akinmade previously promised at the Salesforce annual conference that the company would push 100 Agents into operation in the next phase, but things were not as easy as he imagined.

Previously, CMG had migrated part of its software development work to Claude Code, proving that the team could quickly adopt the latest AI tools. However, when the team tried to get Agents to access Salesforce and participate in real business processes, the project suddenly slowed down.

They soon found out that Agents can write code and call APIs, but they cannot understand the data, permissions and business processes accumulated by an enterprise over many years.

Similar problems are emerging across the entire industry. According to an industry study by headhunting firm Christian & Timbers (C&T), there are only about 2,000 Forward Deployed Engineers (FDE) in the United States who currently truly have the ability to deploy AI systems into enterprises and help customers obtain quantifiable returns.

As enterprises move from "experimenting with AI" to "scaling AI deployment", large consulting and service companies are rapidly expanding such teams.

This has led to a somewhat ironic turn in the AI industry: enterprises are no longer significantly short of Agents, and what is truly scarce is the talent that can sort out their legacy systems for them.

The startup company named June finally helped CMG find a solution.

100 Agents, Stuck in Salesforce

When large model companies demonstrate Agents, they usually provide a clean environment for them.

The data is already sorted out, the interfaces are already connected, the task boundaries are clear, and the calling permissions are pre-set. What the Agent needs to do is to prove that it runs fast enough on a smooth track.

However, real-world enterprise systems are rarely so neat.

A company that has been operating for more than ten years usually uses Salesforce, ServiceNow, Workday, Databricks and a number of self-built systems at the same time. One customer may appear in four databases, with four IDs, three statuses and two responsible persons. Traces left by previous organizational adjustments, product revisions and management changes may also be retained between systems.

These traces are not all technical errors, but only different judgment standards between different departments: the sales department may judge "active customers" based on whether business opportunities are generated, while the finance department judges based on whether payment is received; customer service considers the customer relationship to have been terminated, but the compliance system requires their files to be retained continuously.

Behind each field, there is a set of departmental interests, responsibility boundaries and historical reasons.

In traditional software, these conflicting data can be temporarily digested by people based on employee experience. Senior employees know that a certain field named "customer status" has not been updated for two years in practice; financial personnel know that three columns need to be modified manually after exporting reports; sales managers also clearly know that projects marked as closed in the system still have opportunities to be retrieved.

But Agents do not have these experiences, nor will they develop such tacit understanding — they can only read each field carefully and execute instructions according to the permissions granted to them.

Many system vulnerabilities that were barely maintained by human experience in the past have become big problems that must be solved in front of Agents. An incorrect customer status may lead to an untimely marketing email, while an incorrect loan status may trigger risk control, compliance and even legal responsibilities. For Agents, this is a huge and boundless "mountain of legacy code".

This is exactly the obstacle CMG encountered.

CMG Financial is not unprepared for AI. In fact, as a US mortgage company, CMG has been exploring how to introduce AI into business processes in recent years. The company has begun to use Claude Code to assist part of its software development work, which also proves that its engineering team can quickly adopt the latest AI tools.

In the Salesforce ecosystem, CMG also hopes to further expand the scope of AI application.

Previously, Paul Akinmade, Chief Strategy Officer of CMG, put forward a goal at the Salesforce annual conference: the next time they return to the conference, the company hopes to have 100 Agents in operation.

But when Agents actually entered the enterprise workflow, CMG soon found that things were not as simple as imagined.

Migrating software development to Claude Code is relatively easy, because the boundaries of code are relatively clear, and errors can be controlled through testing, review and rollback. It is different to get Agents into Salesforce, where they are faced with the digital sediments left by the company's years of business operations.

In this case, Agent deployment is no longer a purely technical project. It requires enterprises to answer a series of questions that have been avoided before: which set of data is the real one, who has the right to modify it, which department is responsible for errors, and which historical processes should be abolished.

In order to get Agents truly integrated into the workflow, CMG had to bring in architects, consultants and Forward Deployed Engineers (FDE) to help sort out the existing enterprise systems.

But weeks passed, the project still did not achieve the expected progress.

It was not until CMG found a startup company named June.

Efrat Rapoport, founder of June, summarized CMG's problem as: It is not difficult to create an Agent template, the difficulty lies in dealing with the chaos beneath it.

The solution provided by June is to first make a "medical record" of the enterprise system. It will scan the company's existing software and databases, identify business processes, duplicate fields, data breaks and permission conflicts, and then generate an implementation roadmap.

This set of methods helped CMG see clearly where Agents are suitable for deployment, and what problems must be solved before going online.

According to Akinmade, June even helped the team safely deploy part of the capabilities before the official kickoff meeting between the two parties.

AI First Created an FDE Legion

The problem encountered by CMG is not an isolated case. As enterprises are integrating Agents into their workflows one after another, a new position is rapidly heating up: FDE.

This position was first popularized by Palantir. Different from traditional software engineers, FDEs are not only responsible for developing products, but need to directly enter customer enterprises, understand business processes, connect AI systems to real working environments, and help enterprises obtain actual returns.

But such talents are not easy to find: according to a study by headhunting firm Christian & Timbers (C&T), there are only about 2,000 engineers in the United States who currently truly have such capabilities — this number does not refer to the number of vacant positions, but the total number of talents that meet the requirements is only 2,000.

TechCrunch cited the study as saying that these people need to have industry knowledge, enterprise communication and promotion capabilities, as well as practical AI deployment experience at the same time, to continuously help enterprises get returns from AI investments.

And enterprise demand is growing rapidly.

At the beginning of 2026, only about 5% to 10% of enterprises planned to recruit FDEs; by the end of the second quarter, this proportion had risen to about 70%. Large consulting and service companies have also begun to plan to expand their related teams by 10 times.

This also happened in the software era — whether it is ERP or CRM, after enterprises purchase software, implementation consultants need to go to the site to help the system adapt to real business; now, as Agents enter enterprises, similar roles have been reborn.

But this model also has a natural limitation: it relies on a large amount of high-cost manpower.

To deploy an Agent for an enterprise, engineers may first need to understand dozens of software systems, hundreds of data fields, and decades of business processes.

If every enterprise needs an FDE team, the speed of large-scale AI implementation will still be restricted.

And this is exactly the problem that June is trying to solve.

On August 3, 2026, TechCrunch reported that June, an enterprise AI deployment startup, completed a $20 million Pre-seed financing round.

This round of financing was led by Time Ventures under Marc Benioff, with important figures in the enterprise software and cloud computing fields including Michael Dell, Aaron Levie and George Kurtz participating in the investment.

Rapoport, one of the company's founders, said that the team did not even prepare a business plan for this round of financing.

This is not the first time June's founding team has started a business — Rapoport, Ohad Hen, Barak Goldstein and Idan Tsitiat co-founded the voice analysis company Bonobo AI. In 2019, Bonobo was acquired by Salesforce, and the team later joined Salesforce to participate in its AI business.

It can be considered that their previous company solved the problem of "how to make AI understand customer conversations"; their current company is solving the problem of "how to make AI understand the entire enterprise system".

Investors are willing to place bets quickly, not just because the four founders have had a successful exit, but the problem they are targeting has become a common anxiety across the entire enterprise AI industry.

Rapoport said: "AI has instead increased enterprises' demand for professional services."

The credit approval process of a bank cannot be directly copied to an airline, and the sales department and finance department of the same company may not use the same data standards. Every time a model supplier enters a large customer, it needs to re-understand the business, connect data, configure permissions and design fault tolerance mechanisms.

OpenAI has proved that simply selling models is not enough to capture the enterprise market. It is complementing its deployment capabilities: through the Frontier Alliance, it unites consulting and system integration partners such as BCG, McKinsey, Accenture and Capgemini to help enterprises promote AI transformation. In May 2026, OpenAI established the OpenAI Deployment Company and acquired Tomoro, an applied AI consulting firm, gaining about 150 FDEs and deployment experts. The company received more than $4 billion in initial investment at its launch, further betting on the enterprise AI implementation market.

Amazon took a more direct approach. At the end of July this year, AWS announced that it would invest $1 billion to set up a forward-deployed engineering team, allowing engineers to enter customer organizations and help them build Agent systems in days instead of months.

Anthropic, Google Cloud, Stripe and other companies are also expanding similar positions. The basic annual salary for some FDE positions in the United States has reached $170,000 to $200,000, and the upper limit offered by OpenAI once reached $345,000, not including equity.

What enterprises lack is obviously no longer a set of Agent products, but an engineering team that understands models, software and business at the same time.

The success of Palantir has proved that deployment teams are not just cost centers, but can also become the core barrier for sales and renewal. Engineers staying around customers can quickly discover real needs, help product teams correct directions, and also build customer stickiness that ordinary SaaS cannot easily form.

The problem is that this model is difficult to replicate infinitely.

Every additional customer may require a batch of additional engineers; each company has its own historical baggage, and the experience accumulated in the previous project may not be fully reused in the next project. As long as delivery still relies heavily on manpower, the gross profit margin and expansion speed of Agent companies will be constrained.

What's more troublesome is that customers may fall back into a familiar dilemma: in the past they were locked by software suppliers, now they are locked by deployment engineers. The system does run, but only a few external people know why it works. Once these people leave, the enterprise will get a new black box again.

Akinmade said very plainly before trying June: if this product still needs FDEs, he doesn't want it; he doesn't want to get another set of things that only a few people can understand.

So far, it seems that June has passed this test.

Who Will Take the Business of Tidying Up Legacy Systems

In the past, enterprises were willing to tolerate the chaos of systems, because although legacy systems were inefficient, they could still run at least. Employees could fill data gaps with their experience, and management was unwilling to risk transforming core business for the sake of slightly improving efficiency.

But Agents have overturned this model. They promise to take over a whole segment of work, rather than simply increase efficiency by a few percent.

To deliver on this promise, enterprises must systematically clean up data, re-divide permissions, and formally write those processes that rely on word of mouth into software.

This turns the "legacy system tidying" work from a maintenance cost into a growth business.

June is trying to capture exactly this part of the budget — it attempts to break down the work of FDEs into a set of software processes: first automatic diagnosis, then providing transformation roadmap, and finally completing the setup item by item.

If the same data conflict, permission structure and workflow can be reused across different enterprises, June may turn the past projects charged by man-days into products that can be sold at scale.

This is a more attractive business than recreating an Agent.

Model capabilities are converging, and calling prices are continuing to drop. Enterprises can switch between OpenAI, Anthropic, Google and even open-source models, but it is difficult to easily replace a set of sorted data and business structures.

An enterprise is not a blank sheet of paper waiting for AI to write on. It is more like an old building that has been continuously added to and never thoroughly renovated: abandoned pipelines are buried underground, temporary circuits are hidden behind walls, and every former manager has left traces of transformation that only they can understand.

Model companies have sent more and more intelligent robots, only to find that after the robots enter the door, the first thing they need to do is not work, but to understand the structure of this building, to prevent it from suddenly collapsing once a single part is touched.

Whoever completes this cleanup for enterprises is more likely to occupy the control layer between Agents and legacy systems.

June is not the only company trying to solve this problem. But who will eventually take the "legacy system tidying" business still has no answer:

The first possibility is that startups like June successfully productize deployment work.

They do not own the strongest models, nor do they control the original enterprise systems, but they can remain relatively neutral: connecting different models and SaaS products at the same time, helping customers choose the combination that best suits them. If the product can indeed reduce on-site personnel, such companies will directly impact traditional consulting firms and system integrators.

The second possibility is that SaaS giants such as Salesforce and ServiceNow take this revenue for themselves.

They know the data structure of their own systems best, and also control the most important business entrances of enterprises. The more Agents need to read customer, employee and order data, the harder it is to bypass these legacy SaaS systems.

After June proves that the market is valid, SaaS companies can either replicate its functions or acquire it directly.

This will lead to a result completely different from the "SaaS Doomsday Theory", that is, Agents not only do not destroy traditional software, but also extend their lifespan.

Enterprises will not cobble together a Fortune 500-level CRM in natural language, nor dare to let an Agent of unknown origin directly take over their