A few weeks ago, one of the largest fintechs in the US got access to our platform. Within hours, their team had created a service account, spun up a new workspace from the command line, copied one of our agents, and modified its context to fit their own process. Nobody from our side sat next to them, and nobody needed to. This is a company with one of the strongest engineering organizations in financial services. They could build agents, they know they could build agents, and they chose to buy.

I want to explain why that decision was the right one, from the perspective of an engineer who has spent the last years learning where the difficulty in this problem actually lives.

Building has become a commodity

Intelligence is becoming a commodity, and building on top of frontier models is following the same path. If your differentiation is that you built an agent, you have no differentiation, because a capable engineer can build one in a weekend and it will demo well.

What stays hard is everything after the first deployment. The conditions the agent was built for keep shifting. A policy gets updated, a supplier reformats its invoices, a regulator asks months later how a specific decision was reached. Sooner or later a case surfaces that the agent was not set up to handle.

The agent has to change, and the questions that decide whether it survives in production are who changes it, how long that takes, whether it needs an engineer every time, and whether anyone can prove the new behavior is correct before it ships. That layer, change management, governance and continuous learning, is the part internal builds consistently underestimate.

The question is not whether you can build

You can. For a serious engineering organization, "can our team build this?" always resolves to yes, which is why it is the wrong question. The real cost is maintenance. Internal builds rarely fail at launch. They fail later, once the workflow has drifted from what the agent was built to do and the people who built it have moved on.

Your engineering team should own the workflows that encode how your business operates. In lending, for example, loan-processing logic may be central to the product and a genuine source of differentiation. But owning that logic does not require building the platform beneath every agent: credential management, RBAC, durable execution, evaluation, governance, and the learning loop that allows agents to evolve safely.

Maintaining is the word that matters. Internal builds rarely fail at launch. They fail after the original builders have moved on, the model provider has deprecated an API, and the agent has quietly stopped matching a policy that someone in compliance changed in a shared document.

What buying should actually mean

Much of what is sold as "buy" today is one of two bad deals, and I will name both, because our industry created them.

The first bad deal is renting an outcome and losing control. A vendor deploys a system it alone understands, staffs it with forward-deployed engineers, and routes every change through its own ticket queue. The customer has not bought software; it has outsourced a function and acquired a dependency. Enterprises are right to refuse this arrangement. No company running critical operations will accept deep dependency on a single vendor, and the ones that have tried tend to regret it.

The second bad deal is buying a point solution per workflow: one vertical tool for AP, another for collections, another for KYC, each with its own logic, its own governance model, and its own way of drifting. The result is a collection of agents with no coherent way to manage, evaluate, or evolve any of them. This is buying vertically when the capability should be built centrally.

The right model is a third option: buy the platform, and keep ownership of the operation. You do not need to own the agents themselves or the infrastructure that runs them, because that is commodity work a platform can absorb. What you do need to own is the operation: the context, the policies, the evaluation criteria, and the decision to promote a revision to production. The fintech team I described at the top of this post works this way in practice. When they want to change an agent, they do not file a ticket with us. They open the command line and change it.

A platform earns that arrangement by providing two things that internal builds almost never get right.

The first is evaluation between revisions. When a policy changes and the agent changes with it, the question of whether it still works cannot rest on impressions. The old behavior needs to be evaluated against the new one, on your own cases, before anything reaches production. It is no coincidence that one of the first things this fintech's team requested from us was documentation on evals. Sophisticated buyers do not ask what the agent can do. They ask how they will know when it changed.

The second is two loops rather than one, and it rests on the first. Every serious agent system needs an execution loop, in which the agent does the work, and a learning loop, in which the system evaluates outcomes, captures exceptions, and improves behavior under human governance. The learning loop cannot exist without evaluation, because there is no way to improve behavior you cannot measure. Internal builds ship the execution loop and declare the project done. The learning loop is where agents either stay aligned with a changing business or quietly rot. Autonomous learning without governance is a liability, and governance without learning is a permanent maintenance burden, so the system needs both from the start.

This is also where the cost argument lives. When every agent change requires engineering, whether yours or a vendor's, the cost of change is what kills the return, not the license fee. Putting the ability to change agents in the hands of the people who own the process brings the marginal cost of keeping them aligned with reality down to a level a business can sustain.

The tradeoff

There is a real case for building. If the workflow itself is your intellectual property, meaning the automation is the product you sell, then you should build it, own every layer, and staff it permanently. That is the correct decision for that situation.

The business core operations are a different situation. There, the goal is that the work runs correctly, adapts when conditions change, and can be defended to an auditor. Choosing to build means committing your best engineers to a permanent maintenance obligation on commodity infrastructure, in exchange for a degree of control that the right platform gives you without the obligation.

The strongest engineering teams we work with understood this fastest. They did not buy because they lacked the ability to build. They bought because they had done the math on what building costs in years two and three, and concluded that this was not the war worth fighting. Their engineers build the company, and ours build the harness.

‍