Insights

This Series, Complete: 8 Providers, One API

DNotifier Team12 min readDNotifier × Ollama, part 10 of 10
This Series, Complete: 8 Providers, One API


Closing out the full provider series — OpenAI through Ollama, eight different shapes, one sendAI() call.


This closes not just the Ollama batch, but the full provider series: OpenAI, Anthropic's Claude, Google Gemini, Hugging Face, AWS Bedrock, Perplexity, Azure AI, and now Ollama — eight fundamentally different ways to get a model to answer a request, all reachable through the same sendAI() call in DNotifier.


What eight providers actually taught, provider by provider


OpenAI and Anthropic each run their own model deprecation cycles on their own schedules. Gemini has its own distinct API shape worth understanding on its own terms. Hugging Face carries real licensing nuance that varies model-by-model, not provider-wide. AWS Bedrock needs its own IAM-based account setup and has its own AgentCore layer worth understanding separately. Perplexity isn't a model vendor at all in the conventional sense — it's a search-grounded answer engine, and its Sonar API retired on a real, dated schedule during the writing of this very series. Azure AI turned out to be the most structurally complex cloud provider covered, with a genuine three-name landscape, its own already-past Assistants API retirement, and a deployment-name gotcha specific to how DNotifier calls it. And Ollama, covered in this batch, isn't a vendor at all — it's infrastructure you run yourself, with its own reachability problem, its own hardware constraints, and its own entirely manual model-freshness responsibility.


Eight real differences in how these providers actually work — absorbed by one calling convention, not papered over by one.

Eight real, substantively different stories. Not one of them was a copy of another with the names swapped — every batch in this series found something genuinely provider-specific, verified against primary sources, not assumed to transfer from whichever provider came before it.


The throughline that held across all eight


Despite how different each provider turned out to be, one architectural fact stayed constant: switching which provider handles a given piece of work — cloud to cloud, or cloud to local, as this final batch covered — has consistently been a configuration change inside DNotifier, not an application rewrite. That property held for the API retirements (Perplexity's Sonar, Azure's Assistants API), for the licensing nuances (Hugging Face), and for the fundamentally different operational model Ollama represents. The application code calling sendAI() or a Workflow step didn't need to know, or care, which of the eight shapes was actually behind a given call.


The same orchestration pattern demonstrated for every single provider in this series, now shown spanning all eight at once.

The honest caveat, restated one last time


This series has never claimed DNotifier's orchestration layer is strictly better than building directly against any one of these eight providers. Foundry Agent Service earns its place for teams fully committed to Azure. Bedrock's AgentCore earns its place inside AWS. Perplexity's own agent capabilities earn their place when live search grounding is the actual point. A team with genuinely fixed, architectural data-locality requirements has real reasons to run Ollama directly rather than treating it as one interchangeable option among eight. The honest case for an orchestration layer across all of this was never "always use it instead" — it was "know exactly what you're trading away by not using it, for each specific provider, and decide deliberately." Eight batches of primary-sourced research later, that's still the conclusion.


A use case that ties the whole series together


A team building a customer-facing support platform over the course of this series' publication window ended up using four of the eight providers covered here in a single production Workflow — a fast, cheap model for initial ticket classification, a larger cloud model for drafting nuanced responses, Perplexity for questions needing current information, and a local Ollama-backed step for a narrow category of requests involving data that couldn't leave their own infrastructure. None of those four choices was the "default" — each was selected because of what that specific step actually required, and each could be swapped for a different provider later without touching the other three.


What this sourcing discipline actually protected against


Across all eight batches, this series caught and excluded real fabricated data before it reached an article: an invented model name in the Bedrock batch, a recurring placeholder model string that appeared independently across two unrelated research pulls in the Perplexity and Azure batches, and fabricated-looking Azure pricing figures tied to invented model names. Every claim in every batch was tagged as verified against primary sourcing or excluded outright — not because the rule was decorative, but because it caught real problems, repeatedly, across genuinely different research sessions.


Frequently asked questions


Is this really the end of the provider series, or will more be added later?


Ollama was the last provider on the original list this series was scoped against — if DNotifier adds support for additional providers going forward, that would be a reasonable basis for extending the series, but nothing beyond these eight is currently planned.


Which of the eight providers should a new DNotifier user start with?


There isn't a universal answer — it depends entirely on the task, exactly as every comparison article in this series has concluded. The setup-guide article for whichever provider fits a specific need is the right starting point.


Did any provider in this series turn out to be objectively the best?


No, and that was never really the question this series was trying to answer — the actual finding, repeated eight times with eight different sets of evidence, is that the right provider depends on the task, not on a general ranking.


Is DNotifier's own documentation likely to change any of what's described across this series?


Yes, over time — several batches in this series documented live, dated API transitions happening in real time (Perplexity's Sonar retirement, Azure's Assistants API retirement), which is itself evidence that provider-side change is the normal state of this part of the industry, not an exception.


The Bottom Line


Read part one: Ollama on DNotifier: Setup Guide. Start the full arc from OpenAI: Building AI Agents on OpenAI with DNotifier. Explore dnotifier.com.


DNotifier × Ollama

Part 10 of 10

  1. Part 1Ollama on DNotifier: Setup Guide
  2. Part 2What Makes Ollama Different?
  3. Part 3Choosing a Model to Run Locally
  4. Part 4Ollama Hardware: VRAM & Quantization
  5. Part 5When Local Beats Cloud (And When It Doesn't)
  6. Part 6Tool Calling on Local Models
  7. Part 7Keeping Your Local Models Fresh
  8. Part 8Ollama vs. DNotifier's Cloud Providers
  9. Part 9Securing a Reachable Ollama Endpoint
  10. Part 10This Series, Complete: 8 Providers, One API

Related articles