Software Is Going Back to Custom. Your API Is What Survives.

In 1953 an IBM salesman, R. Blair Smith, was seated next to C. R. Smith, the president of American Airlines, on a cross-country flight. American booked seats by hand, and according to IBM a single reservation could take about 90 minutes to process. The conversation on that flight turned into Sabre, a reservation system the two companies built together. C. R. Smith committed roughly $40 million to it, and IBM adapted the technology from SAGE, the air defence network it had built for the US military.

Sabre was made for one customer. It ran American's routes, American's fares, and American's booking rules, over more than 10,400 miles of telephone lines into a processing centre in New York. It was operational in 1964, about a decade after the flight, and by the mid-1960s it handled 7,500 reservations an hour, each in seconds. It fitted American perfectly. When Delta wanted the same thing, it needed a system of its own.

That was how serious business software was made for the next forty years. A vendor's engineers worked inside the customer, sometimes for years, and built something that fitted one company exactly and cost a fortune to run.

In 1999 Salesforce launched on the opposite idea. Enterprise software, its own history says, was "complex to deploy and expensive to maintain", so it "started with a radical idea: no software." Customers rented one product, the same for everyone, through a browser. It was live in weeks instead of years, and it fitted most of the way. A product that got 75% of the job right beat a perfect fit that took a decade and a team to maintain, and for twenty years the industry moved in that direction.

AI has reversed the cost. Building the exact fit is cheap again, and software is going back to the Sabre model: engineers inside the customer, building around how that one business runs. Two things are different this time. The custom software is mostly agents, and it is built on top of everyone else's systems instead of replacing them.

The engineers are back on site

The role has a new name. A forward deployed engineer, or FDE, is employed by the software vendor but works inside the customer, building the integrations, automations, and custom tools that make the product fit. Palantir made the role famous. Now the largest AI companies are building whole businesses around it.

In May 2026 OpenAI launched the Deployment Company, a unit it controls with more than $4 billion of initial investment from 19 partners, led by TPG. Its engineers pick a customer's priority workflows and build production systems that connect OpenAI's models to that customer's data, tools, and processes. To staff it, OpenAI agreed to buy Tomoro, an AI consulting firm whose past clients include Tesco, Virgin Atlantic, and Supercell, bringing about 150 forward deployed engineers and deployment specialists.

OpenAI is not alone. Investor Tomasz Tunguz added up roughly $10 billion committed to forward-deployed engineering in 12 months by Microsoft, OpenAI, Anthropic, Amazon, and Google Cloud. Perspective AI, which analysed about 1,000 job postings, reported that FDE hiring grew more than 1,000% year over year through early 2026, with Palantir the largest single employer and OpenAI, Anthropic, and Google behind it.

Startups are doing the same. Serval, which raised $150 million in October to replace ServiceNow, is hiring more than 100 engineers to sit inside customers and rebuild their workflows on its platform. We covered what that rivalry did to ServiceNow's share price in ServiceNow Fell 27% the Day Its AI Rival Tripled.

Why the old way is cheap again

The subscription model won because custom software had two costs: building it, and keeping it running. AI has cut the first one hard. An engineer with a coding agent, or an agent alone, can produce in days the integration or internal tool that used to take a consultancy months.

Andreessen Horowitz partner Joe Schmidt made the case for the shift in Trading Margin for Moat, arguing that AI companies selling into complex businesses should accept the lower margins of hands-on services because that is how they win the data and workflows that keep customers. "Enterprises buying AI are like your grandma getting an iPhone," he wrote: "they want to use it, but they need you to set it up."

Investors are pricing the same idea from the other side. When ServiceNow fell 17.7% in April, MarketBeat described the fear behind it as a "lower barrier to entry into coding" that lets customers build what they used to buy. The 25% a product gets wrong used to be a workaround a customer lived with. Now it is a weekend project.

Why custom is how agents get built

The 25% a rented product got wrong did not disappear. People did it: copying records between tools, reconciling exports in spreadsheets, and following the steps the product had no screen for. That leftover work is exactly what companies now hand to agents, and an agent that does it well is custom by nature. Its instructions are one company's rules, its tools are that company's systems, and its permissions mirror that company's people.

That is what the new deployment teams build. OpenAI describes its Deployment Company's work as connecting models to a customer's data, tools, and processes, which is a description of an agent. A forward deployed engineer in 2026 is mostly an agent builder who sits close enough to the business to know what the agent should do.

The return to custom is good news for agents for a second reason. A rented product decides what an agent can do through what its vendor chose to expose. A custom layer decides for itself: it can give an agent one tool for the exact job, written in the business's own terms, instead of a general product an agent has to drive like a person.

What is different this time

Sabre replaced a manual booking process outright. It was the whole system, built for American alone, and travel agents could not book through it until 1976. The custom software being built now mostly sits on top of other systems. An FDE does not rebuild the CRM, the ledger, or the service desk. They build agents and workflows on the data and actions those systems already hold.

So the new custom software is only as good as what it can reach. An agent can't use a capability that lives behind a screen. Sabre's engineers could wire anything they needed because they owned the whole stack. Today's builders own only the top layer, and depend on every vendor underneath to let them in.

That changes what a software vendor is selling. The screens your team designed matter less, because the customer's own tools and agents are replacing them with something that fits better. What the custom layer cannot replace is underneath: the data, the actions that change it, the rules about who may do what, and the record of what happened. A vendor that exposes all of that becomes the foundation everyone builds on. A vendor that keeps it behind its own interface becomes the thing the next custom build replaces.

If you sell software

Treat the API as the product. Custom builders and agents only see what you expose. Every capability that exists only in your interface is a reason to route around you. Our post on HubSpot's API parity promise covers how that gap forms and how to close it.

Make your data easy to build on. Clear object models, documented fields, change events a custom app can subscribe to, and bulk access that does not need a support ticket. An FDE has days, not months, to wire your product in. If it takes a month, they will pick the system that takes a day.

Give builders the same permissions as people. Custom apps and agents act for real users. Scoped tokens that carry each user's existing permissions make your product safe to build on. A separate, narrower set of rules for software is a reason to replace you.

Price for use through the API. If your pricing charges per seat for every person who might touch the data, a customer whose agents do the work will look for a cheaper foundation. Usage-based pricing for automated access keeps you in the build.

Be easy for an agent to learn. Machine-readable API documentation, an MCP server for assistants, and docs pages an agent can read without running JavaScript cut the time it takes to build on you. The builder may be an agent working for an FDE. The Agent Analyzer checks whether your docs and product pages are readable that way.

If you buy software

Own the custom layer, not just the contract. When a vendor's engineer builds your workflows, agree up front where the code lives, who maintains it, and what happens when the engineer moves on. Custom software is cheaper to build than it was, but someone still has to keep it running.

Build the custom layer for agents from the start. Write the business rules down where an agent can read them, give each agent narrow tools that call APIs rather than drive screens, scope its permissions to the person it works for, and log every action it takes. Keep a person on the approvals that cost money or cannot be undone. A custom layer built this way survives the engineer who wrote it, because the next agent can read what the last one did.

Choose platforms by how open they are. The system of record you pick now is the foundation for every custom tool you build later. Ask for API coverage, export rights, and event access before you sign, and test them with an agent during the trial.

Keep your data portable. The more tailored your workflows become, the more it matters that the data underneath can move. A perfect fit on a platform you cannot leave is the old lock-in with a new interface.

Your website is part of the foundation

The same shift reaches public websites. Custom apps and the agents inside them read product pages, pricing, documentation, and help articles to decide what to connect and how. A page an agent cannot read is a page the custom build is assembled without. The Agent Visualizer shows where an agent working through your pages stops, and what it never reaches.