Contributor: Sriram.S, Director of Customer Success, Enterprise Platforms & GPU at RE:AI

Building an AI agent is increasingly straightforward. The harder part comes after deployment: keeping it resilient, cost-controlled and governed as models, workloads and requirements change.

The real challenge is creating the flexibility to adapt without repeatedly rebuilding integrations, reworking controls or adding operational complexity.

Here’s a question most teams never ask: when your app sends a message to an AI model, where does that message get answered? On a big cloud provider, the honest answer is "wherever there was available compute capacity that day." The same model can run out of three different countries in the same week, and nothing tells you which one just happened. For a bank, an insurer, a hospital, or a government office, that matters a lot — they need to know where their data goes. On public cloud, there’s no way to find out.

RE:AI solves this differently. Every request runs on RE:AI's own sovereign GPU infrastructure, under Singtel's own control. Every model you call by name runs on infrastructure RE:AI owns and operates end to end — that's what data sovereignty means in practice.

That’s the first problem solved. The second one is more familiar, and just as costly. Any team that’s tried adding a second AI model to a live product has run into it: "we already approved one model, so we’re covered." That assumption holds right up until the day it doesn’t — when the approved model gets slower, pricier, or simply wrong for a new use case, and there’s no fallback already built in.

A good agent needs more than one model. Easy questions should go to a cheap, fast model. Hard questions need a bigger one. You need a backup for when a model has a bad day. And you need to control what you spend. None of that comes free. Every new model means its own setup: its own security check, its own login, its own quirks, its own code someone must remember. Adding a second model is real work, every single time.

Three months later, the model's price goes up, or it gets retired, or it just gets slow under real traffic. This happens to every model eventually. But the agent was never built with a backup, so it breaks, live, in front of a customer. Whoever's on call ends up hot-patching the integration in production, under pressure, with no test environment for the replacement model — the exact kind of shortcut that creates the next incident.

So, teams stop adding models. Someone tried adding a second one, it broke something, and nobody wants to go through that again. The one model they trust ends up doing every job, even the simple ones that don't need it. And because no app has its own spending limit, one agent stuck in a bad loop can burn through the whole team's budget before anyone notices.

Both problems come from the same place. Once you approve a model, everything about it — its price, how reliable it is, which country it runs in — is locked in for every app that uses it. And you never had control over where it runs in the first place. On public cloud, that was never something you could set.

Token-as-a-Service is the control plane between every agent your team builds and every model in RE:AI's catalogue, running entirely on RE:AI's own sovereign GPU infrastructure. The integration layer is engineered once — not re-engineered per model, per app. Here's what that architecture delivers.

One name for every model. Your code never hardcodes a vendor’s model name — it calls an alias: "the smart model," "the fast model," whatever the workload needs. That alias is the only thing your application ever sees. Swap the model behind it — a new version, a cheaper option, an entirely different provider — and it’s a one-line change on RE:AI’s side. No redeploy, no code review, no hunting through the codebase for every place a model name got hardcoded.

Routing rules built around what you need, not a fixed default. The Gateway doesn’t decide on its own what "the smart model" means. RE:AI works with you to set the rules — route by cost, by speed, by which model is approved for which type of work, or a mix of all three.

Maybe every regulated request has to go to one approved model, while your internal chatbot is free to shop around for the cheapest option. Maybe a task that needs a fast answer goes one way, and a slow background job goes another.

Once the rules are set, the Gateway follows them automatically, every single call — nobody writes custom code for each new model, and you’re never forced to choose between adding a model quickly and following your own rules. If cost is what you care about, this alone can cut what you spend on AI by 30 to 60 percent, because most requests never needed the most expensive model to begin with.

If you care about something else instead — where the data runs, how fast the answer comes back, which model is trusted for which job — the same system enforces that instead.

Every app gets its own key. Its own list of allowed models. Its own speed limit. Its own spending cap. A new project gets a working key the same day, not after weeks of waiting on a ticket. And if one key is ever stolen or misused, the damage stays limited to that one key.

You can see spending in real time, for every key. You know exactly what each app is costing before the bill arrives, not after. If an app hits its spending cap, it just stops. No surprise bill at the end of the month.

Backup happens on its own. If a model slows down or stops working, the request quietly moves to a backup model. No error message. No one gets woken up at 2am. The system fixes itself instead of waiting for a person to notice.

One place to see everything. Every request, every model, every cost, all in one log. You can see straight away which app costs the most or breaks the most, instead of digging through five different tools to find out.

One more thing sits underneath all six, and it never changes: every one of them runs on RE:AI's own sovereign GPU infrastructure. Token-as-a-Service doesn't just abstract away which model answered your call — it keeps the infrastructure fixed, no matter how many models you add behind it.

None of this is complicated technology. It's built once, and every app after the first one gets it for free. Trying a third or fourth model becomes a five-minute change, not a new project.

Adding a model becomes easy. Outages fix themselves. No single agent can blow the whole budget. And every request still lands on the same sovereign ground.

Setting up the first model still takes real work, and it should — someone has to write the rules for the first time. What's different is the second model. Add it three months later, and nobody repeats that work: no new security review, no new backup script, no new argument about where it runs. You're just adding one more option to rules that already exist.

Whatever the rules were built to protect — a spending limit, a speed target, a rule about which model can be used for what — keeps being followed on its own. The hundredth call follows the same rules as the first.

The real win was never that the first agent is fast — most demos are. It's that the second one is fast too, without a new security review, a new backup script, or a new argument about where the data ran.

Building the first agent on RE:AI was never the hard part. Staying fast, staying in the right country, and staying under your own rules after that — that's the hard part. And that's exactly what Token-as-a-Service is for.