What MaiAgent said in Paris on June 19 and why it lands now
At VivaTech 2026 on June 19, Taiwan-based MaiAgent stood on stage and told the room that enterprises should stop building retrieval-augmented generation and AI agent systems from scratch. The phrasing is what made the moment land: not a competitive jab against another platform vendor, but a public statement that the default posture the enterprise market spent the past two years adopting — "every team builds its own RAG stack and its own agent orchestrator" — has run its course.
The credentials MaiAgent brought to the claim are not trivial. The platform runs in production at 100+ organizations across financial services, healthcare, manufacturing, and aviation. The product surface bundles, under a single governed AI Core:
- Retrieval — indexing, embeddings, vector store, hybrid search, reranking.
- Orchestration — agent loops, tool calling, multi-step planning, error recovery.
- Tool connectivity — connectors to the document systems, ticket systems, ERPs, and data warehouses the enterprise already runs.
- Access control and compliance — auth, audit logs, redaction, data residency, regulator-aligned controls.
- Deployment shape flexibility — SaaS, private cloud, on-premises, and hybrid cloud configurations.
The pitch is structural: every piece of that surface is generic across customers. The financial services version and the aviation version differ in the domain data, the workflows, the access controls, and the eval rubric — not in the RAG plumbing or the agent runtime. The case for building each of those layers in-house, against the case for buying them as a unit, has been getting weaker quarter by quarter, and on June 19 a vendor with 100+ production deployments said it out loud.
The commoditization moment, named
The MaiAgent talk is the cleanest 2026 signal that the generic agentic-infrastructure layer has commoditized. The pattern is not new — it is the same shape every prior infrastructure layer has followed:
- 2010 → 2014: Every team rolled its own deployment pipeline; then GitHub Actions, CircleCI, and the cloud providers shipped the generic version and most teams stopped.
- 2015 → 2018: Every team rolled its own analytics warehouse; then Snowflake, BigQuery, and Redshift shipped the generic version and most teams stopped.
- 2020 → 2023: Every team rolled its own observability stack; then Datadog, Honeycomb, and the cloud-native APMs shipped the generic version and most teams stopped.
- 2024 → 2026: Every team rolled its own RAG and agent runtime; the platform vendors are shipping the generic version, and on June 19 one of them said the quiet part out loud.
Building your own version of the generic agentic-infrastructure layer in 2026 is the same kind of bet as standing up your own Postgres deployment in 2018: defensible only if you have a reason the generic version actively breaks for you. The vendors who have made the platform sufficient have not made the platform a winner — they have made the default a platform, and the build-bespoke case is now the one that needs to be argued.
The build-vs-buy decision matrix we now run on every engagement
The matrix below is the question set we walk through with a client on the design call when the conversation turns to should we build our own RAG and agent stack. The matrix is short on purpose: each question is a kill switch on the build case, not a vote in a longer scoring exercise.
- Is the domain data on a system the platform connector covers? If MaiAgent (or Vertex AI Agent Builder, or AWS Bedrock Agents, or the in-house Azure AI Foundry equivalent) already has a maintained connector to the system of record, building the connector in-house is a write-off. Use the platform's. If the system of record is bespoke enough that no connector exists and no roadmap is going to add one, that is a real argument for in-house — but only for the connector, not for the full stack.
- Is the eval rubric domain-specific in a way the platform cannot host? Every serious platform now lets the customer plug in their own golden set and their own eval rubric. The platform owns the runner, the customer owns the rubric. If the team is building "its own RAG stack" because it wants control over the rubric, the team is solving a problem that no longer exists.
- Is the deployment shape outside the platform's footprint? Air-gapped, on-prem, sovereign-cloud, or regulator-pinned deployments used to be the obvious build-bespoke case. MaiAgent shipping in SaaS, private cloud, on-prem, and hybrid configurations narrows that case to the strictest sovereign deployments — and for the rest, the platform footprint covers it. Verify before assuming.
- Is the access-control posture more aggressive than the platform supports? Per-document ACLs, row-level security in the warehouse, attribute-based access on the retrieval layer — most platforms now ship a reasonable model. The build-bespoke case is the team whose access posture is more aggressive than the platform supports and whose risk profile makes the gap material. That is a narrow band.
- Will the team actually staff the long-tail work? RAG plumbing in 2026 is not the hard part; the maintenance of RAG plumbing in 2026 is the hard part — re-indexing pipelines, embedding upgrades, eval drift, connector rot, runtime upgrades, security patches. The honest question is: will the team have two engineers permanently allocated to this in 18 months? If the answer is no, the build case is a write-off no matter how it scores on the other questions.
If three or more answers point to use the platform, the platform decision is made and the team should be spending the engineering budget on the domain logic on top — the workflows, the rubric, the access policy, the connectors to the genuinely bespoke systems, and the human-in-the-loop quality bar. That is where the differentiation accrues. The plumbing underneath does not.
What "domain logic on top" actually looks like
The MaiAgent reframing only works if the buyer believes the differentiation — the reason their AI feature wins against the competitor's — lives in a layer the platform does not commoditize. We think that is right, and we think the layer is more specific than "prompts and workflows." On every engagement we run, the differentiating layer is some combination of:
- A measured golden set against the team's actual workload. Not generic benchmarks. The team's own representative inputs, with the right answers labeled, run on a cadence that catches drift early.
- A domain-expert eval rubric written by people who would catch the wrong answer in production. Subject-matter experts grading the model's outputs against the criteria that matter for the workflow — medical clinicians for healthcare, claims adjusters for insurance, M&A bankers for finance.
- A workflow design that exposes the right human-in-the-loop checkpoints. Where does the agent ask before acting? Where does it act and log? Where does it route to a senior human? The answer is workflow-specific and is the part the platform cannot ship for the buyer.
- A connector layer to the genuinely bespoke systems of record. The 5% of integrations the platform's catalog does not cover. The team that builds those well has a moat. The team that rebuilds the other 95% the platform already covers is burning the budget on plumbing.
That set of artifacts is what we ship on AI-development engagements. It is also what our AI-training service produces on the labs and the enterprises that need the eval rubric and the human-in-the-loop quality bar built from the ground up by domain experts. The MaiAgent talk on June 19 is the clearest public signal yet that the buyer should be spending their budget on exactly that layer, and outsourcing the layer underneath.
When you should still build bespoke
The matrix has corner cases that survive even the 2026 commoditization. The honest list:
- Genuinely sovereign deployments where the platform's strictest footprint is still too permissive.
- Latency-critical retrieval where the generic platform's latency floor is above the workflow's budget.
- Embedded deployments — on the device, in the appliance, in the browser — where there is no platform runtime to install.
- Research-stage R&D where the team is exploring novel architectures the platform cannot accommodate.
- A real, named systems-of-record gap where the connector does not exist and will not be built.
For everything outside that list — the median enterprise RAG and agent deployment in 2026 — the platform decision is now the default, and the engineering investment should follow the domain logic on top. That is the read we'd offer any team currently sketching a build-bespoke Q3 plan: rerun the matrix this week, and if the platform answer holds, redirect the budget into the rubric and the workflow design. The team that ships its Q3 AI feature on a platform plus a domain-expert eval rubric ships in October. The team that ships its own RAG stack ships the plumbing in October and the feature in March.
If you want a second pair of eyes on the Q3 roadmap, that is the conversation we run.
