"Edgee has become our governance layer for AI usage": an interview with Qonto's Kevin Prettre

A conversation with Kevin Prettre on buying an Agent Gateway, rolling it out through existing tools, and controlling AI spend at scale.

By 10 September, 500 Qonto engineers were running their coding agents through Edgee. Migration had begun in late July. During the opt-in phase, adoption grew from 10 to 350 engineers in five weeks, before Qonto made Edgee the default.

With compression and its first routing rule in place, Qonto already reports a 37.7% reduction in cost. This is a first step, with further routing optimizations still to explore. Its engineers keep using their existing harnesses, while the company gains shared controls over model usage and spend.

We spoke with Kevin Prettre, Director of Infrastructure and Engineer Support at Qonto, about why his team chose Edgee, how it assessed compliance, and what remains difficult even with a gateway in place.

Qonto's rollout at a glance

These figures describe Qonto's deployment and measurements. Compression-only and combined savings are separate measures; they should not be added together.

An Agent Gateway for the tools engineers already use

Qonto's starting point was practical: let engineers choose the right model for each task, without making the infrastructure harder to operate.

For an engineering organization, that involves more than providing an API endpoint. Coding agents work across CLI tools and desktop applications, carry long conversations, and repeatedly send context and tool results to models. The gateway needs to handle those workflows while preserving attribution to the person behind each session.

Edgee is an Agent Gateway: it sits between coding agents and LLM providers to route requests, track usage, and compress tokens. At Qonto, the decision to buy one came down to the work around the proxy: compatibility, identity, ongoing maintenance, and controls that engineers could use without changing their tools.

Kevin's answers follow in full.

In conversation with Qonto

Kevin Prettre

Director of Infrastructure and Engineer Support
Qonto

Why didn't you build it yourselves?

Several months ago, we set out to make large language models a commodity at Qonto: our teams should be able to choose the right model for each task without friction. Amazon Bedrock gave us access to a broad range of models, but deploying it at scale was cumbersome, as it required provisioning a Bedrock identity for every employee and every feature.

Qonto could have built a gateway itself. The question was never whether we could build a proxy, but whether we wanted to own everything around it. Our engineers work across a dozen agent harnesses and four to five desktop surfaces, each with its own integration patterns, and these harnesses change how they call models on a near-weekly basis. On top of that sit prompt cache management and tool-call optimisation. An open-source option such as LiteLLM would have left us either maintaining that compatibility layer ourselves or depending on the community to keep pace. Even a minimal identity and attribution layer on top of Bedrock represented roughly a month of development, with AI-assisted coding, before accounting for ongoing maintenance and the feature work that inevitably follows. What we needed was not a proxy but a product, and we chose to buy it rather than staff it.

Introducing a third party into the path of every AI request is a sensitive decision for a regulated financial institution. How did you assess Edgee on data residency, auditability and access control?

We assessed Edgee with the same scrutiny we apply to any provider. Inference runs on AWS Bedrock, which is where our data residency and no-training guarantees are enforced. Edgee processes requests in transit, including context compression, but does not store payloads unless we explicitly enable it. We nonetheless required EU residency, both for the data Edgee holds directly, such as employee identities, and so that we could enable session debugging when needed without leaving our compliance perimeter. Edgee is GDPR compliant, and under DORA it is classified as a non-critical ICT third-party provider. It supports no critical or important function; an outage would affect developer productivity, not our banking services, and our harnesses can fall back directly to the underlying model providers.

For auditability, our security team relies on its own source of truth: OpenTelemetry exporters instrumented directly on the agent harnesses. What Edgee adds is the link between the two, tying each harness, session and model to an employee identity.

What role does Edgee play today, and how do you know re-routing doesn't hurt quality?

In practice, Edgee has become our governance layer for AI usage. Compression is applied company-wide, combining tool surface reduction, token compression and output brevity, and delivers a median cost reduction of 17%, reaching 20% depending on the period and usage patterns. Model re-routing adds further savings by directing requests to cheaper models where they perform equally well. Combined, our latest measurement shows a 37.7% reduction in cost.

We do not yet run a formal evaluation platform, so our confidence in re-routing rests on team feedback, delivery velocity and an experiment we ran during our evaluation of Edgee. For two weeks, a team of ten engineers had their frontier-model traffic silently rerouted to an open-weight model, and none of them could tell the difference.

Why not a general-purpose gateway?

We evaluated a leading general-purpose gateway during our proof of concept and never rolled it out. The gaps were concrete: models we needed were missing, bring-your-own-key was not available on the provider we required, and the vendor's sales and support capacity for the European market fell short of what a company of our size needed.

The deeper issue, however, is one of design. A gateway built for applications assumes a known set of services, stable request shapes and service-level identity. Agent traffic breaks all three. Behind every request is a person, working in one of a dozen harnesses or desktop surfaces that evolve every week, over long sessions in which cost is driven by context and tool payloads rather than by request volume. We needed a gateway designed for that reality, with routing policies that act on the task rather than the endpoint, compatibility with both command-line and desktop harnesses, and identity carried through the entire session. We also needed live visibility into cost, token consumption and model mix, down to the level of tokenomics: how consumption and spend break down by function, across reasoning, completion and tool calls. Edgee's vision and roadmap matched those ambitions.

What did deployment look like in practice?

We ran the blind test from mid-May and extended it through June. Migration began in late July, and by 10 September, roughly six weeks later, 500 engineers were running through Edgee.

We deliberately started with an opt-in phase. We presented the tool and its capabilities, and the main draw was simple: engineers could use other models inside the harnesses they already worked in. Adoption grew from 10 to 350 engineers in five weeks without any mandate. We then made Edgee the default for everyone, without asking engineers to change their habits. Using our device management platform, Jamf, we deployed the alias provided by the Edgee CLI, so that every new harness session was preconfigured to route through Edgee. The remaining engineers were onboarded shortly afterwards. Our first governing routing policy went live on 1 September, moving traffic from one frontier model used for task execution to a cheaper frontier model of the same class.

The harder problem lies elsewhere, and it is not one a gateway can solve. Without an evaluation platform at scale, it remains genuinely difficult for engineers to right-size the model they use for a given task. We are also contending with the pull of LLM marketing, which steers engineers toward the newest and most heavily promoted models regardless of fit. We are not yet satisfied with our model and token mix. That is a question of engineering skills, culture and the way these products are sold to developers, and it is where our work continues. Edgee gives us the visibility and the controls; using them well is on us.

What this partnership makes possible

Qonto's rollout shows how adoption and governance can develop together. Engineers first opted in to access other models from familiar tools. Qonto then made Edgee the default through Jamf and introduced a shared routing policy.

Kevin's description captures the result: “In practice, Edgee has become our governance layer for AI usage.” At Qonto, the Agent Gateway gives the team a place to connect model choices, spending, and employee identity.

His final point matters just as much. Visibility and controls help teams act, but choosing the right model still requires evaluation and engineering judgment. The ten-engineer experiment offers useful feedback from one deployment; it is not a formal demonstration that models are interchangeable across tasks.

Our work with Qonto continues around those practical questions: how to make model choices with better evidence, keep spend under control, and give engineers useful options inside the tools they already use.

Thank you to Kevin and the Qonto team for sharing both the results and the work ahead.

Rolling out coding agents across your engineering organization? Talk to us.

Try Edgee with your coding agent. Get started.