← Blog

What an applied AI lab in Singapore should build first

Contents
  1. The boring thesis
  2. Seeding is the product, not the setup
  3. Integration breadth is the silent killer
  4. The handoff is the product
  5. Stub it out
  6. Hyperlocal, not generic-SEA
  7. The tension I have to admit
  8. What I'd actually do on day one

This week OpenAI announced a S$300 million applied AI lab in Singapore, scaling to 200+ technical roles. First lab outside the US. I've been building applied AI products from this country for eighteen months, at Voltade, where we run an agent platform for SMEs across Southeast Asia. So I've been thinking about what I'd actually build first if it were me.

Most of the answers I've seen are some version of "smarter agents" or "models that understand the region". That's not it. Or rather: it's the wrong place to start.

The thing applied AI labs underestimate is that the model isn't the constraint. The wrapping is.

#The boring thesis

If I were running the lab on day one, I'd build operational scaffolding before I built another agent. Specifically: integration adapters, multi-channel abstraction, and demo data infrastructure that treats seeding as a product feature.

That sounds boring. I'll defend it.

#Seeding is the product, not the setup

A few days ago I was scoping a round of Envoy demos for SMEs across five different verticals. A bakery, a spa, a furniture retailer, an HR platform, an education business. Different industries, different tech stacks, different conversation histories. When I wrote about Envoy in detail I focused on the customer experience. What I should also have written about is the demo infrastructure that makes the customer experience legible in the first place.

Here is a near-verbatim from one of my own planning notes that week: "the issue with the voltade demo one is all 4 usecases sharing 1 account, WA conversations have error due to the blast, confusing knowledge base." The "issue" wasn't agent quality. It was that the demo environment couldn't represent what real customers actually look like. One shared account collapses five different businesses into noise.

That is why I split the demo into separate environments by use case, and wrote, out loud, to myself: "EVERYTHING should be inside. Conversations seed, channels, knowledge base, broadcast, analytics, workflows. Every tab on LHS panel needs to have everything available."

Seeding is the product. The agent is downstream.

#Integration breadth is the silent killer

The other thing applied AI loses to that nobody talks about is integration breadth. Look at the list I drew up for one customer segment: Shopify, WooCommerce, Plato, WESS, Odoo. Five POS or ecommerce stacks for one SME vertical. None of them speak the same dialect.

The lab's stated brief is "make AI accessible to enterprises and the public sector". Accessibility is not a model problem. It is an integration problem. If you ship the smartest agent in the world but it can't read the customer's order history from Plato, the SME doesn't care that it's smart.

A research lab in Singapore that doesn't budget for a deeply unglamorous integrations team in year one is going to spend year two relearning this lesson the hard way.

#The handoff is the product

A specific example, and the one customer I can name. At Cake Inspiration, Kai's bakery, the most valuable thing the agent does is recognise when not to answer. Custom cake requests get forwarded to a human designer immediately. The agent isn't trying to be smart there. It's trying to escalate well. The product is the handoff, not the conversation.

That is what an applied lab in this region should optimise for. Not "the agent talked beautifully to the customer". But "the agent knew when to step aside, and the human got there in time, with the right context."

#Stub it out

There's a phrase I keep typing into my own session notes. "Stub it out." When an integration is too complex to wire cleanly into a demo, I'd rather have it return a 501 than have a broken pipeline pretending to work. Same principle for agents. Better to ship the parts that work and clearly mark the parts that don't than to ship one polished thing that hides the seams.

A research lab that ships clean demos to the public sector will get one chance to embarrass itself. The operational discipline of marking your own seams is, paradoxically, what lets you move fast.

#Hyperlocal, not generic-SEA

One more thing the lab should build, and this one is the most uncomfortable. Hyperlocal SME use cases, not generic "SME tools".

When I was scoping a spa demo last week I caught myself thinking, what kind of spa? Then: confinement. Singapore has a specific cottage industry around postnatal confinement businesses that doesn't exist most places. The right product isn't "a CRM for spas". It's "a CRM for confinement businesses" with the right vocabulary, the right channels (WhatsApp, mostly), and the right escalation paths to humans who actually know what a confinement nanny does.

If you're building a lab in Singapore and not absorbing this texture in the first six months, you're going to ship the generic Silicon Valley version of a Southeast Asia product. The model won't save you.

#The tension I have to admit

The honest part of this post. My own work doesn't always practise what I'm preaching. I write publicly about evaluation frameworks, agent reliability, 99.65% task success rates. Those numbers are real. But when I'm in the actual product, I'm rarely thinking about them. I'm thinking about whether the demo environment is seeded correctly, whether the integration into the customer's Shopify works, whether the handoff to Kai's designer goes through.

The public narrative around applied AI says "models". The work says "operations". I think the lab in Singapore is going to learn the same thing about itself within six months. The sooner the team is wired to handle it, the better.

#What I'd actually do on day one

None of this is anti-research. Smarter models matter, evaluation infrastructure matters, agent capability matters. These are second-order problems. The first-order problem for an applied AI lab is whether the agent it ships can actually plug into the customer it is trying to help. Most of the work to make that true is plumbing.

I might be wrong. The lab probably has a clearer view of the region from inside the org than I do from outside. But if anyone there reads this and wants to argue about it, I'm in Singapore too.