Gemini Enterprise o desarrollo propio: una comparación honesta

Platform or custom is usually debated as an identity question. Are we the kind of organisation that buys, or the kind that builds. Framed that way it gets answered by temperament, and the answer applies to everything, which is how you end up either paying to rebuild connectors that already existed or forcing a genuinely unusual workflow through a product that was not shaped for it.

The better framing is per workflow, and it turns on a single question: is the differentiating thing about this work the plumbing, or the logic?

We build on Gemini Enterprise and we build custom agent systems. What follows is how we actually decide, including the cases where the platform is the wrong answer.

Three things, and the third is the one people undercount.

Connectors that already work, and keep working. Reading from Workspace, Microsoft 365, SharePoint, Salesforce, SAP, ServiceNow and Box is not intellectually difficult, but doing it with correct permission handling and then maintaining it through every API change on the other side is an ongoing tax that never appears in the original build estimate.

Permission-aware retrieval as a default rather than a feature you remember to implement. Getting this right in a custom stack is entirely possible and is exactly the sort of thing that is correct in version one and subtly wrong by version four.

A central place agents are registered, visible and auditable. In a custom estate this is a thing somebody has to decide to build, and it is never the priority in the quarter when it would have been cheap. Proliferation is the most expensive failure mode in agent programmes and the platform is opinionated about preventing it.

Three situations, and they are narrower than most engineering teams initially claim.

The reasoning itself is the product. If the sequence of steps, the domain model or the decision logic is the thing your competitors cannot copy, you want full control of it, and you do not want its evolution coupled to a vendor roadmap.

The data cannot go where the platform is. Sovereignty, classification or contractual constraints sometimes settle this before any technical discussion, particularly in public sector and regulated work. This is a real constraint and not usually an arguable one.

The workflow is genuinely unusual. Not complicated, unusual. Most enterprise work is a variation on retrieve, reason, act inside a system of record, which is precisely the shape the platform is built for. If your workflow is honestly not that shape, forcing it in produces something worse than either option.

Platform cost is visible and per seat. Custom cost is mostly invisible and lands later, which reliably biases the comparison toward building.

A fair comparison includes the connector maintenance, the permission model, the evaluation harness, the audit trail, the on-call rota and the fact that the two engineers who understand the system will not both still be there in three years. None of that appears in the initial estimate and all of it is real.

Running the other way, the platform comparison should include what you will pay in workarounds when a workflow does not quite fit, and the strategic cost of having your most differentiated logic sit inside someone else's product. Both of those are real too. The honest position is that the platform is usually cheaper than the build estimate suggests, and occasionally more expensive than the licence suggests.

In practice the answer is rarely uniform. The broad productivity layer and the long tail of system-touching workflows sit on the platform. The two or three workflows that genuinely differentiate the business get built properly, with the control that deserves.

The thing that must not be hybrid is governance. Two registries, two audit trails and two access models is how you end up unable to answer a simple question about what agents exist and what they can reach. Whichever way individual workflows split, the reach model, the human-in-the-loop policy and the audit record should be answered once, for everything.