8 Integrations, 3 Enterprise Deployments Unblocked: Building the Integrations Layer at Galileo AI

This is the story of how deep technical ownership of an integrations layer, and the right architectural decision made at the right time, translated directly into commercial outcomes for enterprise clients.

Galileo is an AI evaluation and observability platform for GenAI applications. It gives teams the tooling to measure, monitor, and improve LLM-powered systems in production. Covering evaluation metrics, hallucination detection, and runtime monitoring.

When Galileo opened its platform to the public, the integrations landscape was at an early stage: two supported frameworks, with a custom-mapping approach that took more than a week per integration, and a growing pipeline of customer requests for more.

The starting point: Two integrations, a growing queue

When the Eversynced team first engaged with the integrations layer, Galileo supported two frameworks: LangChain/LangGraph and OTel. Adding anything new meant writing a full custom mapping layer. Complex logic to catch all fields and translate them into something Galileo’s ingestion pipeline could understand. There was no shared architecture. Every integration was a standalone project.

That process took more than a week per framework. In a market where competing platforms were expanding their integration coverage rapidly, the pace wasn’t sustainable, and the queue of customer requests made that clear.

Three enterprise clients each had an open blocker preventing them from moving forward with their deployments. Each had a different blocker, but the underlying problem was the same: the existing architecture couldn’t move fast enough.

The architectural decision: Build on the open standard

The solution wasn’t to build faster using the old approach. It was to change the approach entirely.

The team looked at how the ecosystem was developing and made a foundational call: build on the OTel GenAI Semantic Conventions. This was an open-source standard that most major frameworks were already adopting. That meant framework maintainers (AWS Strands, Google ADK, Microsoft, and others) would own their own OTel instrumentation. Galileo’s team would only need to handle the receiving side.

The pipeline was designed in layers: a Detector identifies which framework sent the trace, an Extension normalizes any framework-specific deviations, and then a shared Processor and Transformer map everything into Galileo’s internal schema. The key decision was keeping the Extension layer thin. Since most frameworks already follow the GenAI spec, each extension handles only edge cases rather than a full custom mapping.

That architectural choice turned adding a new integration from a week-long project into a three-day one, for Tier 1 (basic OTel ingestion). The tiered model gave the team a clear promotion path: get basic support in quickly so customers aren’t blocked, then invest in native integration when usage and demand justify the effort.

What “unblocked” actually meant: Three clients, three different blockers

The three enterprise deployments that were unblocked each had a different root cause. Understanding what it took to unblock each one illustrates why architectural flexibility, and the ability to act across the full stack, mattered.

A major telecom provider. The blocker wasn’t a missing framework. This client was already sending traces via OTel, but their middleware injected redacted versions of inputs and outputs before data reached Galileo. The pipeline didn’t support those custom span attributes, so traces were arriving incomplete. The team added support for the specific custom attributes across the processor, transformer, and validation layers, and unblocked the deployment within the sprint.

An enterprise analytics platform. The issue was a silent bug: spans with errors were being dropped during ingestion even though the API returned a 200. From the client’s perspective, everything looked fine. But failed traces never appeared in Galileo. This was escalated as the highest-priority customer bug and shipped the same week.

A billing software provider. The blocker was twofold: they needed Microsoft Agent Framework support, which hadn’t been built yet, and ground-truth metrics, meaning the ability to evaluate agent responses against expected outputs. Both had to ship before the client would move forward. The timeline was approximately one week. With the old architecture, that would have been impossible. The tiered framework made it achievable.

With the old approach, that timeline would have been impossible. The tiered architecture is what lets us move fast enough to keep the deal.

8 integrations shipped, with sequencing logic behind each one

Prioritization across the 8 integrations wasn’t arbitrary. The team built a tiered system: Tier 1 for basic OTel ingestion, Tier 2 for native framework support with a dedicated callback or handler, and Tier 3 for full session and stable support. Frameworks were promoted through tiers based on customer demand and ecosystem adoption.

LangChain, given its market dominance, was built to Tier 3 from the start. Google ADK was promoted from Tier 1 to Tier 2 to Tier 3 as Galileo published the galileo-adk package. CrewAI followed the same path. For the remaining frameworks, the model was consistent: ship basic OTel ingestion immediately so customers aren’t blocked, then invest in native integration as demand develops.

The OTel client: Lowering the barrier for end users

Beyond the frameworks themselves, the team shipped an OTel client that simplified the user-facing integration experience. Previously, customers had to wire up their own OTel exporter and configure it for Galileo, a setup step that created friction, especially for teams unfamiliar with OTel instrumentation. The client abstracted that entirely, reducing the integration surface for end users significantly.

That investment in quality had an unexpected downstream effect: Galileo was listed as a recommended observability provider on both the official CrewAI and Google ADK documentation pages. The integrations earned placement there because of how well they worked, not because of any outbound effort.

Being listed as a recommended observability provider on those docs pages brought in organic adoption that no amount of outbound would have matched.

Full-stack ownership across the integrations layer

The integrations work required ownership across more than just the integration code itself. Custom integration framework architecture, documentation for every framework shipped, and bug fixes at the ingestion layer. All of it sat within the same scope of ownership.

That breadth was what made the pace possible. When a blocker emerged at the ingestion layer, as it did with the custom span attribute gap and the silent error drops for two of the enterprise clients, it could be addressed immediately, within the same team, without a handoff or a ticket queue.

The integrations work at Galileo demonstrates something specific about what technical ownership of a platform layer can mean commercially. The right architectural call, building on OTel GenAI conventions rather than continuing to write bespoke mapping logic, didn’t just make the team faster. It changed what was possible. Three enterprise deployments were unblocked within sprint timelines that the previous approach couldn’t have supported, including one where the window to deliver was approximately a week.

That kind of outcome requires more than execution. It requires the context to see the architectural decision, the range to implement it across the stack, and the ownership to carry it from design to delivery to documentation, without passing it off.

That’s what Eversynced is built to provide.