For decades, people have joked that their entire business runs on Excel. There's some truth to that. When an ERP or CRM system couldn't keep up with changing business needs, Excel often could. People built their own calculations and models without waiting for IT to make the changes.
The developers behind Excel built the tool. Business users decided what to do with it. When their needs changed, they updated the formulas themselves.
We're seeing something similar with personal AI agents. People can now build their own agents and adjust their instructions without involving developers. That's a welcome development, particularly for internal business use. But there's an unnecessarily wide gap between these personal agents and AI services running in production.
Prompts aren't software code. Changing them shouldn't always require a developer.
Yet that's often how things work. If an AI customer service assistant gives the wrong answer, fixing it typically involves a developer. The business team explains what needs to change, a developer updates the instructions, the change gets deployed, and the business team tests the result. If something's still wrong, the cycle starts again.
That's a lot of unnecessary work just to improve how AI behaves.
Business teams should be able to steer AI themselves
One way to guide an AI system's behavior is through its system prompt: a set of instructions that can define business rules and describe how the AI should handle different situations. In that sense, a system prompt is a little like a formula in Excel. Both can express business logic, even though they work very differently.
Someone working in customer service knows how customers should be answered and when they need to be directed to another channel. They understand the business better than the developer who built the system. Updating those instructions shouldn't always require software development.
This is the idea behind business-owned AI. Developers build the system, while business teams own and evolve the business logic that guides its behavior.
That ability becomes especially important after launch. Real users ask questions nobody thought of during testing. They try to use the service in ways its creators never anticipated. There's little point in trying to perfect an AI service before releasing it. A better approach is to launch it in a controlled way, see how people actually use it, and improve it based on what you learn.
Freedom needs guardrails
For business teams to make changes safely, they need more than a prompt editor. Especially when AI has access to company data or can take actions on a customer's behalf.
For example, an AI model might decide to offer compensation to an unhappy customer. It can suggest an appropriate response, but the maximum compensation amount and any required human approval must be enforced by the system. That way, even if the model gets something wrong, it can't act outside its permitted boundaries.
Developers are responsible for building those boundaries, along with security and integrations. Business teams decide how the AI should serve customers within them. They also need a way to test and release changes, track versions, and roll back when something doesn't work as expected.
In production, trust can matter more than having the smartest possible model. We need to know what the AI is allowed to do, what it can't do, and how to correct its behavior when necessary.
In production, trust can matter more than having the smartest possible model.
What business-owned AI looks like in practice
We've been building this approach with customers including Moi Mobile and Silmäasema.
Moi Mobile's AI assistant is integrated into the Mun Moi app. Customers can describe what they want to do in their own words, whether that's checking a bill or changing their mobile plan. The AI interprets their intent and helps them use the app's existing features.
Silmäasema's AI assistant Silmäbotti answers customer questions on the company's website and helps people find the right service or appointment booking. Customer service specialists monitor conversations and improve the AI's behavior as part of their regular work.
Both solutions run on Codemate's Paimen® platform, which lets business teams develop AI behavior within guardrails defined by developers.
Should AI even be the solution?
AI conversations can also tell us a lot about what customers actually need. Traditional service analytics tells us what users do within the service we've built. We can see which buttons they click, which features they use, and where they abandon a form.
When people tell an AI what they're trying to accomplish in their own words, we get a different kind of information. We can learn about needs that our service doesn't currently address.
In my talk at next.app devCon, I called this measuring the non-existent. AI conversations can reveal things we didn't even know to look for when designing the service.
Sometimes those conversations also reveal problems that shouldn't be solved with AI at all.
If customers constantly need help completing a complicated application form, we could teach the AI to explain it better. But perhaps the form itself needs to be simplified.
We've seen a similar situation with promotional campaigns. The AI was correctly explaining complicated campaign terms, yet customers were still unhappy. The useful insight wasn't that the AI needed better instructions. The campaign communication itself needed to be clearer.
Making sense of these findings requires business expertise. Someone who understands the service can connect individual customer questions to the bigger picture and decide whether to improve the AI, the service itself, or the underlying business processes.
Let business take the lead
When we talk about improving AI, the conversation often revolves around models and what they're capable of. In production, who controls the AI's behavior and who can improve it based on customer needs matters just as much.
Developers need to build a secure, reliable system. Business specialists should be able to improve how that system behaves without sending every change into the development backlog.
When business teams can see what customers are asking for and adjust AI behavior themselves, they also get a better understanding of the service as a whole.
Not every customer problem needs a better prompt. Sometimes the better solution is to fix whatever made the customer ask the AI for help in the first place.
Three things to take away
- Prompts aren't software code. Business teams should be able to improve AI behavior without involving developers in every change.
- Freedom requires guardrails. Developers build the secure, reliable system and define its technical boundaries. Business teams steer AI behavior within those boundaries.
- AI can help improve more than AI itself. Customer conversations reveal needs and problems that may be better addressed by improving the service itself.
This article draws on my talk, “Power to Business: Business-Owned AI — What It Takes to Build and Why It Matters,” at Next.app DevCon 2026, as well as our experience building AI services for production.
Further reading: Paimen · Moi Mobile's ApulAInen · Silmäasema's Silmäbotti
