How the market pulled us into becoming an agentic platform

Key Points:

• Qovery is now an agentic platform - the control plane where agents and humans provision, deploy, observe, secure, and optimize infrastructure safely.
• We didn't set out to build this. Our customers pulled us into it, because the moment they put AI agents to work, infrastructure was the first thing that broke.
• Existing tooling buckles under agents. GitOps, Terraform, and review flows were designed for how humans work, not for the volume and pattern of agentic operations.
• The real challenge is speed with control - governance, approvals, and compliance become critical the moment you put a budget behind agents.
• Security by design, since day one - Qovery separates the control plane from your data plane, so your code and data never leave your cloud. That is why regulated industries run on it.

We didn't decide this - the market pulled us there

We come from pure infrastructure. That is what we have always done. So when the "agentic platform" positioning landed, it wasn't a pivot we chose on a whiteboard - it was the market pulling us there.

Teams at companies like Tint, Alan, Zoom, and Talkspace pushed us hard on AI, because they hit the ceiling on infrastructure faster than anywhere else. Some saw it before we did.

The clearest example was Jonathan, a founding engineer at Tint. He had built sandboxed AI capabilities for his team directly on top of the Qovery API - governed, isolated environments where his people could put agents to work safely. We met in Paris, at Le Train Bleu, for half a day before he flew back to San Francisco. Half a day was enough. What he had built on Qovery was so impressive that it changed my whole perspective on the market and where we needed to be. That meeting was the starting point.

What struck me was that our API already answered exactly what he needed: centralize every operation through one interface, see everything that happens, and put the right guardrails around it. He didn't ask us to build something new - he built it himself, on what was already there. Once we saw it from the infrastructure side, the pattern was obvious.

Another signal is who we onboard. We are onboarding more and more non-technical users - and the trend is only accelerating. It doesn't mean everyone becomes an engineer; it means the potential is there for every person in an organization to be a builder. That is the generalization of the platform idea taken to its extreme: the whole point of a platform was always to make people more autonomous. Agents just took that idea and pushed it much, much further.

And almost 100% of the conversations we have today are about exactly this.

The problems nobody planned for

Here is what actually happens when a company starts adopting AI seriously. New load shows up that nobody planned for:

• Builders multiply inside the org. People who never touched infrastructure start shipping. Non-technical teammates start building.
• Pull requests explode. More PRs means more CI, more reviews, more deployments - a whole new tax on the delivery pipeline.
• New use cases appear that were not predictable before AI. They were not on anyone's roadmap, and now they are the bottleneck for most organizations.

There is a second, quieter problem underneath the volume: adoption is broad but shallow. In most companies, lots of people are already using tools like Claude every day. But there is very little depth - few people really understand the models, the context window, how tokens are spent, or the good practices that separate a useful agent from an expensive one. That gap is exactly why guardrails matter more, not less. You have a lot of hands on powerful tools and not enough shared discipline behind them.

And then there is the effect on the people who were already there. When you produce more, you overload your developers with even more to know and master, over shorter and shorter cycles. Teams are not used to that pace. The counterintuitive discipline that separates the teams who survive it is knowing when to put the pen down - to pause the agents, step back, and keep quality from drifting.

Why infrastructure is the first thing to break

Everything that came before was built for a human workflow. GitOps, Terraform, review flows, approvals - all excellent principles, all designed around how humans work.

The moment the work goes agentic, that stops working well. Almost not at all, honestly.

You can already see it in the wild: GitHub is getting bombarded - the deluge of AI-generated pull requests has grown so overwhelming that GitHub is weighing restrictions to protect maintainers. It has quietly become the operations center for agents. But the products underneath - even the infrastructure products - were never designed to be operated by agents. Teams that start doing serious agentic work discover very quickly that their existing stack doesn't hold. It buckles in every direction, and that pressure cascades into everything else downstream.

To see why it breaks, look at how most companies wire agents up today. The default approach is to point the agent directly at every infrastructure component. A single agent ends up carrying 10+ integrations and 10+ access tokens, running from one developer's laptop, fanning out to CI/CD, the registry, Kubernetes, secrets, DNS, monitoring, and more. It works - and nobody controls how.

That works for exactly one person. Then you multiply it by the whole team. Every developer's agent - and every new agent someone spins up - gets its own copy of those tokens, wired into the same systems. The web of direct connections explodes, and there is no single place that knows what is connected to what.

This is the exact moment infrastructure breaks, and it breaks in four specific ways:

• No control over who does what - any agent can touch any system.
• Credentials on every machine - tokens are copied onto every laptop that runs an agent.
• No audit trail, no traceability - when something goes wrong, you cannot tell which agent did it.
• It breaks at team scale - what works for one person collapses once the agents are not just yours.

This is exactly the problem we came to solve, and it is a whole category on its own. We wrote up the full anatomy of it in What is an agentic infrastructure platform?.

For companies built before this wave, there is an extra layer: the brownfield problem. Fitting agents onto an existing stack has two blockers. The first is mentality - how mature the organization and its management are about this shift. The second is infrastructure - whether the existing stack lets you adopt agents without itself becoming the brake.

Beyond operations: the governance and security problem

The four failures above are operational - they slow you down and eventually break. But there is a deeper, more dangerous class of problem hiding underneath them: governance and security.

Look again at the traditional approach. Every agent holds real credentials to your most sensitive systems - DNS, databases, secrets, production. Multiply that by every developer and every new agent, and you have quietly created a security posture nobody signed off on:

• Secrets sprawl - the same access tokens are copied onto every laptop that runs an agent. Each copy is a new place they can leak.
• Over-privileged agents - with no scoped identity, an agent can touch far more than the task in front of it requires. Least privilege goes out the window.
• No audit trail - when something goes wrong, you cannot say which agent did it, on whose behalf, or when. There is no traceability.
• Unbounded blast radius - a non-deterministic agent acting directly on production can cause damage no human explicitly approved.

For any company that has to answer to a regulatory framework, this is not a theoretical risk - it is a direct compliance failure. Auditors check for exactly the controls this approach destroys:

• SOC 2 - access control, least privilege, audit logging, and change management.
• HIPAA - access controls and audit controls over every system that touches protected health information.
• ISO 27001 - access control, logging, and monitoring of who did what.
• NIST (800-53 / CSF) - access control (AC), audit and accountability (AU), and enforced least privilege.

And that is before you get to PCI-DSS, GDPR, DORA, and the EU AI Act, to name just a few. An agent that can touch anything, running from a laptop, with shared credentials and no audit trail, fails these frameworks by construction - not because the team was careless, but because the architecture was never designed to be governed. The honest truth is that most teams track this very badly today, and very few are compliant across everything.

The only way to keep the velocity agents give you and stay auditable is to stop wiring agents directly into your infrastructure. Every action - human or agent - has to flow through a governed layer with a scoped identity and a complete audit trail. That is the whole reason infrastructure has to change.

The real problem: speed with control

The instinct is to hand everything to the agents and let them run. That is a Ferrari without brakes. It doesn't usually end well.

Every leader we talk to feels a version of the same existential question: a new generation of companies is emerging with far higher delivery capacity, and management genuinely asks whether they are at risk of being out-executed. The honest answer is that the winners are not the ones who simply go fastest - they are the ones who can go fast and see what is happening.

Because with agents, the risk is a loss of visibility and control, exactly like the early days of cloud. And most companies are not well equipped on that front. The moment you put a budget behind agents and send them off, control and observability become critical:

• Governance and auditability - who (or what) did what, when, and why.
• Approvals and policy - guardrails on what agents are allowed to touch.
• Compliance - SOC 2, HIPAA, ISO 27001, NIST, and regional frameworks like DORA, GDPR, and the EU AI Act. As covered above, giving agents broad access breaks the exact controls these frameworks require, and in regulated environments that puts fine exposure directly in the spotlight.

You have to be able to measure. Speed without measurement is not speed - it is just risk moving faster.

What makes Qovery different: the centralized control plane

Here is the default setup most teams start with: an agent runs on a developer's laptop and inherits that person's credentials. It operates directly on every component - DNS, databases, production. It works for exactly one person. It does not scale, and it stops being safe the moment the agents are not just yours. You are not going to hand out production access to everyone, and routing every operation through one trusted person turns that person into the bottleneck.

The natural answer is a centralized layer that delegates and governs those operations. That layer is what Qovery provides, and it is the cornerstone everything else rests on. Every action - human or agent - flows through one centralized API instead of raw credentials scattered across laptops.

That single design choice is what gives you:

• Auditability of every action - who, or what, did what, when, and why.
• RBAC over access - agents get scoped, delegated permissions, never the keys to everything.
• Unified operations across your whole infrastructure, through one interface.

Security by design, since day one

This is not something we bolted on once agents showed up. Qovery has been built security-first from day one, and the reason it holds up under agents is architectural: the control plane and the data plane are separated.

Qovery's control plane handles orchestration, scheduling, and metadata. Your data plane - your code, your data, your secrets, your workloads - runs and stays entirely on your own cloud. Your infrastructure initiates a secure connection to the control plane, so there is no hard dependency the other way: even if Qovery were down, your infrastructure keeps running. The two are completely isolated by design.

That separation is exactly what makes it safe to let agents operate. Agents act through the governed control plane - scoped, authenticated, audited - but they never get raw, standing access to the data plane. Your data never leaves your perimeter.

This is why regulated industries run on Qovery. For healthcare under HIPAA, financial services and insurance under DORA, and European companies under GDPR, data residency and a clean separation of control are not preferences - they are legal requirements. The plane separation is what makes SOC 2, HIPAA, and ISO 27001 achievable by construction rather than bolted on after the fact. In these environments, governance and security are not an option, and the architecture was designed for exactly that. We go deep on this in what makes Qovery secure and our security and compliance approach.

And because Qovery is built in the language of platform teams, the guardrails are real platform-engineering capabilities, baked in rather than bolted on:

• Per-project quotas and limits on how many projects users can spin up.
• Auto-deletion of resources, so agent experiments do not quietly pile up.
• Cost and token visibility - an admin panel showing running environments, who uses what, and how much, with tools like OpenCost integrated natively.

The framing we keep coming back to: how do you help people do as much as possible themselves, while preventing the worst?

The use cases we see every day

Once that control plane is in place, three use cases open up naturally - the same three we lead with across the product.

Build with AI, Deploy with Qovery

Claude, Cursor, or any coding agent builds - Qovery ships it, governed by construction. The agent writes and iterates; Qovery is the governed path to production, so velocity never comes at the cost of control. See Build with AI, Deploy with Qovery and our Terraform provider.

Spec to Production

A Linear or Jira ticket triggers an agent sandbox - code, test, iterate, open a PR. The spec becomes a running, isolated environment automatically, with full platform control over what runs and where. See Spec to Production.

Anyone is a Builder

Lovable for Enterprise - business teams describe what they need, and the platform makes it safe. Non-technical teams build their own tools on the company's own infrastructure, each in a scoped, secured workspace. See Anyone is a Builder.

How Qovery delivers it

One control plane, many interfaces - UI, CLI, API, the Terraform provider, and an MCP server. Every actor, human or agent, goes through the same governed, auditable path - with delegated, scoped access through the API instead of raw credentials on a laptop. That is what lets a team give agents real autonomy without giving up control.

That is the whole idea behind an agentic platform, and why we believe it is the next infrastructure category.

Further Reading

• What is an agentic infrastructure platform? - the full anatomy of the category and why every company needs one.
• Agentic AI infrastructure: moving beyond Copilots to autonomous operations - what changes when agents operate infrastructure, not just write code.
• Build with AI, Deploy with Qovery - the governed path from any coding agent to production.