How Omada broke free of single LLM lock in with an agents adapter layer on Amazon Bedrock

Omada wanted the freedom to run its multi agent platform on more than one AI model provider, starting with Amazon Bedrock. Its agents, however, were built on OpenAI APIs. Fission Labs closed that gap with an Agents Adapter Layer, so every existing agent kept working while engineering effort dropped by about 80% and model spend fell 13.2%, an average saving of $2,100 a month.

At a glance

The opportunity: flexibility to evolve the platform

Omada is a fast growing enterprise AI platform focused on multi agent orchestration and enterprise SaaS. To support its continued growth, Omada set out to expand beyond a single AI model provider and use Amazon Bedrock for enterprise AI workloads.

Four business priorities shaped the project:

• ‍Model and vendor flexibility: access multiple foundation models and reduce dependency on a single provider‍
• Enterprise adoption: use AWS capabilities to support enterprise requirements around security, scalability and cost management‍
• Continuous AI improvement: create the flexibility to evaluate and adopt newer, more capable models as they become available‍
• Protect existing investments: make the transition without rebuilding Omada's existing agent ecosystem

The commercial priority was clear. Give enterprises the vendor flexibility they required, particularly Amazon Bedrock for compliance and cost benefits, without disrupting the agents customers already relied on.

Why a rewrite was off the table

The obvious answer was to rebuild the platform for Bedrock. Three problems made that a bad bet.

1. ‍OpenAI provider lock in. The platform was tightly integrated with OpenAI APIs, which made it hard to extend to alternative providers.‍
2. Deep API and memory coupling. Existing agents depended on the OpenAI Responses API format, built in tool calling, and agent memory and orchestration logic.‍
3. Production migration risk. Rewriting or migrating the whole system would disrupt live workflows, consume significant engineering effort, and could break existing agent behaviors.

The question changed from "how do we rebuild for Bedrock?" to "how do we make Bedrock speak the language our agents already use?"

The approach: an Agents Adapter Layer

We designed and built an Agents Adapter Layer, a compatibility bridge between the OpenAI Agents SDK and Amazon Bedrock. Omada's agents keep calling the interface they know. The adapter handles the translation to Bedrock.

The result decouples Omada's agent application from whichever model provider sits underneath. What the engagement delivered:

• ‍Bedrock Adapter. An OpenAI compatible adapter that lets existing agents run on Amazon Bedrock.‍
• Decoupled architecture. Core application logic is isolated from model specific APIs, which removes the single vendor dependency.‍
• Amazon Bedrock integration. Direct access to Bedrock foundation models, with built in guardrails and enterprise memory management.‍
• Advanced capabilities. Support for multi agent workflows, memory, RAG, web search, tool integration and streaming.‍
• Future ready foundation. A base for evaluating and adopting newer models based on business requirements.

Most importantly, all existing agent logic and client integrations stayed intact.

Under the hood: the AWS architecture

The adapter runs as a serverless backend on AWS. Omada's Chat Service sends requests exactly as before, and the adapter handles everything between the OpenAI compatible interface and Amazon Bedrock.

Here is how a single request moves through the system:

1. ‍HTTPS request. The Omada Chat Service calls Amazon API Gateway through an OpenAI compatible API on the /v1/responses endpoint.‍
2. Forward request. API Gateway validates and transforms the request, then passes it to the Bedrock Agents Adapter on AWS Lambda.‍
3. Invoke tools. The adapter, built on FastAPI and the Strands Agents SDK, calls external tools when needed: the Serper API for web search and OpenAI Vector Store for file search and RAG.‍
4. Invoke model. The adapter calls foundation models through the Bedrock API.‍
5. Model response. Bedrock returns the LLM output to the adapter.‍
6. Tool results. Tool outputs flow back into the adapter's orchestration.‍
7. Formatted response. The adapter shapes the answer into the OpenAI compatible format.‍
8. Response. The client receives the response, streaming or non streaming.

Along the way, the adapter handles agent orchestration, tool calling, streaming and conversation memory, which it keeps in Amazon S3. Amazon CloudWatch provides monitoring and logging.

What it changed for the business

The adapter was an engineering fix with commercial consequences. Omada could now say yes to enterprises that required Bedrock, and it gained four lasting advantages.

A loop, not a one time migration

The real value extends beyond moving to Bedrock once. Bedrock gives Omada access to a growing portfolio of foundation models, and the adapter makes switching between them routine. Each time a new model ships, Omada can run a simple cycle against its real world workloads:

The loop has already paid off. Moving from GPT-5.5 to Claude Opus 4.8 improved accuracy by an average of 5.07% across advanced reasoning, tool use and web research, and better models translate directly into better task execution and response quality for Omada's customers, without another migration project.

Key outcomes

The Agents Adapter Layer delivered measurable impact for Omada, with full continuity for its existing agents.

• About 80% engineering effort saved by building are usable, stateful Bedrock Adapter instead of rewriting each agent for Bedrock compatibility
• $2,100 saved per month on average in model spend after moving from OpenAI to Amazon Bedrock, 13.2% lower overall
• 5.07% accuracy gain on average across advanced reasoning, tool use and web research, moving from GPT-5.5 to Claude Opus 4.8
• 85% content time saved, with campaign content produced in minutes, not days, fully automated from brief to publish
• All existing agent logic and client integrations kept intact on Amazon Bedrock
• The same agent interface for every existing agent
• Six advanced capabilities supported: multi agentworkflows, memory, RAG, web search, tool integration and streaming

What this means if you are building on one model provider

Omada's situation is common. Teams build fast on one LLM API, then enterprise buyers ask for a different cloud, a different compliance posture or a better price. A full rewrite is rarely the answer. An adapter layer that keeps your agent interface stable lets you add providers, compare models on your own workloads and adopt the best one, while production keeps running.

Build your agents for the models of tomorrow

As an AWS Advanced Tier Services Partner with AWS competencies in Generative AI Software, AI Services and DevOpsServices, we help enterprises and fast growing platforms take agentic AI from pilot to production on AWS. Founded in 2010, we have 450+ engineers and have delivered 250+ projects for 100+ clients across healthcare, fintech, retail, logistics, SaaS and manufacturing.

Running GenAI in production on a single model provider? Talk to us or your AWS account team about building a vendor flexible foundation on Amazon Bedrock.