Stop Building New AI Products. Start Putting AI Inside the Ones Your Team Already Trusts.
A London startup called Arrakis came out of stealth with $38 million in funding to help industrial companies (aerospace, energy, logistics, manufacturing) deploy AI agents into their operations. The round included backing from Datadog’s CEO and OpenAI’s head of business products, which is the kind of detail that gets a seven-month-old company covered by Fortune.
The interesting part isn’t the funding number. It’s the one concrete example the founder gave the press. For a New York-listed shipping company, Arrakis didn’t build a new platform. They rebuilt the exact spreadsheet the company’s operators already used every day, had AI populate it automatically, and let the system learn from the corrections those operators made as they went. Cash-flow visibility went from a monthly process to a daily one. Nobody had to learn a new tool. The tool got smarter underneath them.
That’s a useful story to sit with, because it points at a mistake a lot of companies make when they decide it’s time to “add AI,” and a lot of dev teams make when someone asks them to build it.
The default instinct is to build something new.
Ask most teams to bring AI into a business process and the plan that comes back looks like a product roadmap: a new dashboard, a new interface, a new system for the team to log into. It’s the natural output of a build mentality. Engineers build things, and a new AI capability tends to get expressed as a new piece of software.
The problem is that a new piece of software is also a new habit somebody has to form. Every additional login, every extra tab, every “check this dashboard too” is friction against a process that was already working, just working slowly. The AI has to be good enough to overcome the cost of switching, and most of the time it isn’t, so the new dashboard gets checked once a week instead of replacing the daily process it was meant to fix.
Arrakis’s bet, and it’s a reasonable one, is that the biggest near-term value in enterprise AI isn’t a new product at all. It’s AI quietly doing more of the work inside the tool that already has the team’s trust.
What “integration” actually means in practice.
This isn’t a design philosophy, it’s a scoping decision you make before a single line of code gets written, and it usually comes down to three questions.
Where does the team already look? Not where would a clean system architecture put the information. Where does the person actually doing the job open their laptop and check first thing in the morning. That’s the surface AI needs to show up in, not a new one next to it.
What’s the manual step that’s costing time, not the step that looks impressive to automate? A five-agent orchestration system sounds more sophisticated than “auto-populate this spreadsheet,” but the spreadsheet is what shipped, because it solved the actual bottleneck (data entry and reconciliation) instead of a more interesting problem nobody was losing sleep over.
Does the system get better from the corrections a human makes, or does it just sit there? The detail in the Arrakis example that’s easy to skim past is that the AI learned from the operators’ corrections over time. That’s the difference between a tool a team tolerates and a tool that actually earns the trust to take on more of the work.
None of this rules out building something genuinely new when a new system is the right answer. Some workflows don’t exist yet in any usable form, and in those cases a purpose-built agent or platform is the correct scope. But that should be a conclusion you reach after mapping how the team actually works today, not the default starting point because it’s the more interesting engineering problem.
Why this matters more in regulated or high-stakes environments.
The stakes get higher, not lower, when real capital decisions run through the tool in question. We’re seeing this firsthand right now, rebuilding a financial investment firm’s Excel-based feasibility model into a production system: multi-phase capital structuring (GP, LP, preferred equity), scenario recalculation, sensitivity analysis. The spreadsheet wasn’t broken. It was the model the team had trusted for years, the one their investors’ reporting already ran on, just too slow to explore more than one scenario at a time. The mandate wasn’t “replace this with a platform.” It was “make the model instant, and keep everything that already works.”
That’s the same shape as the Arrakis example, just in a different industry: a capital-structuring process built over years is a much harder thing to ask a team to abandon than to ask them to run faster. Replacing that process is a much harder sell than making it faster and more consistent, because the process isn’t broken, it’s just slow, and slow is a much easier problem to justify solving than “trust something completely new with the fund’s numbers.”
That’s also where the pricing model AI vendors are starting to experiment with (tying fees partly to hitting a specific performance outcome rather than just delivering a system) actually makes sense. It’s much easier to commit to an outcome, like cutting a scenario-modeling cycle from hours to seconds, when the AI is embedded in a process you can already measure, than when you’re asking a client to adopt something new and hoping the outcome shows up eventually.
The question worth asking before your next AI project starts.
Before scoping the build, ask what the team already opens every day, and whether the plan puts AI behind that screen or next to it. If the honest answer is “next to it,” that’s worth revisiting before the first sprint starts, not after the team quietly stops logging in.
If you’re working through that scoping question right now, that conversation, mapping what your team already relies on before deciding what to build, is one we have with founders early, before any commitment to a specific architecture.
