AI didn’t add a feature to coworking software. It’s rewriting what the product is.

What an “AI-native” platform means

In a call last week I learned that “AI-native” isn’t about adding AI to an interface. It’s about what the product underneath has to become.

As we release more Nexudus AI Agents, the platform has to let them do more than answer questions. The agents need to understand how different parts of the operation relate to each other to be able to act across the platform. And once you start thinking about the product that way, it also opens up different ways for people to use it.

If we take it from the top, coworking software has been organised around modules for years. A bookings module, a billing module, a CRM module, a reporting module and so on. Each one solves its operational slice of the pie, with slices often glued together through integrations and workarounds. The software bloats and just gets more complicated. But AI gives us the chance to change the recipe.

One common shortcut is to take the existing product, add a chat window on top, and let an AI chatbot answer questions about the data underneath. Nothing about the underlying product changes at all. The chatbot is simply a different way into the same system.

That’s not a shift we’re interested in. We’re interested in whether the product’s underlying logic is rebuilt so AI can reason and act across it properly.

If you think about it, a coworking business doesn’t run in modules. A booking can trigger a charge, change an access permission or create a task for the front desk. When a new member joins, that’s one process, but software can turn it into four separate jobs: set up their contract, arrange payment, give them access and start their welcome journey.

Teams have to move between different parts of the system to make one thing happen. Bolting a chatbot onto that structure doesn’t remove silos. It just gives you a different way into it.

AI isn’t the point

We aren’t talking about adding an AI interface either. That wouldn’t be very interesting.

So, how do you design an AI-native platform for coworking?

A coworking team is never one type of user. A community manager who’s opened the same three screens every morning for two years doesn’t want to have a conversation. They want to get straight to the task, with as little interpretation as possible.

Someone covering for a colleague on leave, or a new hire three days into the job, is a different user. They don’t know which of dozens of menu items contains the setting they need. Forcing them through the same click path as the two-year veteran isn’t a feature. It’s more like a tax on inexperience. Most software makes everyone pay that tax because building one interaction model is easier than building two.

We think the real alternative is giving people a genuine choice in how they get something done, based on how well they already know the process. Not as a fallback for when the “real” interface fails, but as an equally valid front door.

That clicked for me. AI-native doesn’t have to mean forcing everyone into an AI conversation. It can mean designing the product for different people who need different routes to the same outcome.

It also means the cost of a new starter, a staff rotation, or an operator managing five things at once goes down, because the system meets them at whatever level of familiarity they have. We can stop demanding they build a mental map of the product before they can be productive in it.

It also points to why this goes beyond any single feature. It’s really a response to something wider happening across software: people no longer have to learn one prescribed route through a product.

A platform with a switch for every edge case is still, underneath, one rigid model dressed up as flexible.

The alternative isn’t more switches, and it isn’t a chatbot either. It’s a system that can guide someone through whatever process their business uses, at whatever level of confidence they’re bringing to it that day.

This matters a bit more than you think it might

There’s a commercial consequence too.

Every time a new starter has to learn where things live, or an experienced operator has to stop and work out how to complete an unfamiliar task, there’s a cost.

Training takes time, staff change and knowledge walks out of the door. Making powerful software easier to use without slowing down experienced users can make the platform easier, and cheaper, to keep using.

This also changes how we think AI should be tested. A polished demo can make almost any AI feature look good. We need to test solutions against real questions and real points of friction: especially things people contact support about (not curated workflows designed to make the technology look good).

Ask this on demos

Don’t ask whether a platform has AI. Nearly everyone will say yes.

Ask what the AI changes. Does it give your team different ways to get work done, or does everyone still have to follow the same click paths? Does it reduce complexity, or just give you another way to navigate it?

These questions might be handy:

• What can your AI do, other than answer questions?
  Can it take actions in the platform, or is it a chatbot?
• What can it work across?
  Can it understand relationships between bookings, billing, access, customers and tasks, or is it limited to one area at a time?
• What happens when it isn’t sure?
  Does it ask for clarification, flag uncertainty or require approval before doing something?
• Can I see what it did?
  Are actions, conversations and outputs logged so your team can review them afterwards?
• How does it adapt to the way our business works?
  Can it work with our workflows and rules, or does the software expect us to fit a predetermined process?