In the world of developer tooling, you hear two camps. One camp says: “Give me a framework with strong opinions. I don’t want to think about configuration, I want to build.” The other camp says: “I don’t want vendor lock-in. Give me flexibility.”
When building our platform, we chose both. And that’s not a compromise — it’s a deliberate architecture choice.
The problem with “flexible”
Most agent frameworks position themselves as flexible. Pick your own model, your own vector store, your own deployment target. Sounds great in a README. In practice, it means: you have to figure everything out yourself.
Which embeddings provider works best for Dutch text? How do you configure Redis for rate limiting in a multi-agent setup? Which Kubernetes health check strategy prevents your pods from being recycled while they’re in the middle of an LLM call?
Flexibility without opinions is just work you’re pushing onto the user.
The problem with “opinionated”
On the other hand: opinions that are too strong create lock-in. If your platform assumes you’re running on AWS, you have a problem the moment a client requires Azure. If your framework only works with OpenAI, you’re stuck the moment Anthropic releases a better model. Or the moment a client wants to run on-premise with open-source models.
In the AI world, everything moves fast. Lock-in on models, clouds, or tooling isn’t just annoying — it’s a business risk.
Our approach: opinions on patterns, not on vendors
Our platform has strong opinions about how you do things, not what you do them with:
Strong opinion: Every agent has structured logging with trace IDs.
No opinion: Whether that goes to CloudWatch, Datadog, or a self-hosted ELK stack.
Strong opinion: LLM clients are centrally configured with retry logic and cost tracking.
No opinion: Whether that’s OpenAI, Anthropic, or a local model.
Strong opinion: Deployment happens via containers with health checks that validate dependencies.
No opinion: Whether those containers run on AWS ECS, Azure AKS, GCP GKE, or a bare-metal Kubernetes cluster.
Strong opinion: Secrets are never hardcoded and always loaded via environment variables.
No opinion: Whether those secrets come from AWS Secrets Manager, Azure Key Vault, or HashiCorp Vault.
The pattern is always the same: the platform enforces best practices, but leaves the choice of tooling to the environment.
Why this matters for our clients
We work with companies across different sectors. An energy company running on Azure. A maritime company that wants on-premise. A financial institution with specific compliance requirements for hosting.
If our platform were tied to a single cloud, we couldn’t serve half of these clients. By having opinions about patterns instead of vendors, the same platform works everywhere. The agent logic doesn’t change. The deployment configuration does — but that’s a matter of environment variables, not code changes.
The practical implication
For us as a team, it means every project has the same starting point, regardless of where it ultimately runs. We don’t start with “which cloud does the client use?” but with “what’s the problem?” The infrastructure adapts. The architecture doesn’t.
For our clients, it means they’re not locked in. If they want to switch clouds tomorrow, or model providers, that’s a configuration change. Not a rebuild.
That’s what we mean by cloud-agnostic: not that we don’t have opinions about anything, but that our opinions are about how you build good agent systems — not about which logo is on your cloud invoice.