An account executive at WorkOS built a chatbot to answer questions about customers, sales calls and company products. She used Lovable, and the idea was practical: while she was away, colleagues could still get at some of the knowledge she normally carried.
Then they tried to open it.
According to WorkOS's Garrett Galow, even the CEO received an access-denied message. The chatbot worked for its maker, but it wasn't ready for everyone she wanted to help. Two engineers from the applied AI team became involved in moving the app out of its original building environment and making it deployable and accessible.
That's the example Galow gave in his AI Engineer conference talk. It's his account of an internal WorkOS project, not an independently verified deployment history. Still, the handoff is more interesting to me than the fact that someone made a chatbot with AI assistance.
A person who understood the problem had already made something useful. Other people needed to depend on it. Those turned out to be different jobs.
The audience changed the definition of done
When you're making a prototype for yourself, you can fill in a surprising amount of missing infrastructure without noticing. You know where the link is. You're already signed in to the account that created it. You know what the data means. If the app behaves strangely, you can go back to the builder and try again.
A colleague has none of those advantages. They need to find the correct version, sign in, see only the information they're allowed to see, and trust that the tool will still be there next week. If it fails, they need someone to tell.
The WorkOS chatbot appears to have crossed that boundary before acquiring the access and deployment arrangements it needed. Sharing an app doesn't, by itself, establish a shared service.
This isn't a uniquely AI problem. The departmental spreadsheet that becomes indispensable, the macro only one person knows how to repair, and the small script that quietly takes over a business process all have versions of it. AI-assisted building may make more of these experiments feasible. The cited WorkOS example doesn't tell us how quickly the pattern is growing across organizations, and I wouldn't use it to claim that it does.
What changes is where I'd put the next question. Once someone demonstrates that the tool can work, I want to know what has to happen before another person can rely on it.
Someone still has to build the boring parts
Galow's talk describes WorkOS trying to make that transition less dependent on a bespoke engineering rescue. At internal building days, employees outside engineering worked on their own problems while engineers advised them. The employees drove the building process; engineering expertise remained available when the app ran into a technical boundary.
He also described two components of the approach. WOW was a command-line starting point for employee builders, preparing an environment and a usable project. Atlas was the shared infrastructure behind internal apps, with presenter-described capabilities for deployment, hosting, storage, employee sign-in, audit logging and managed secrets. Galow discussed Cloudflare-backed infrastructure, Okta-based company authentication and token-based access for programmatic uses such as bots and APIs.
Those are capabilities reported in a conference demonstration. They aren't proof that every WorkOS app was secure, always available or successfully maintained.
The direction is nevertheless sensible. An employee building a small utility shouldn't need to make independent decisions about cloud accounts, password storage, deployment pipelines and app discovery on every attempt. If a platform can supply common answers, the employee has more room to work on the actual problem.
Instead of eliminating engineering, it simply relocates repeatable engineering work into a shared dependency.
That dependency has an owner too. A change to the hosting layer, sign-in system or storage service may affect many internal apps at once. Someone must handle its incidents, updates and recovery. The individual builder has fewer infrastructure chores because another part of the organization has agreed to carry them, not because those chores have stopped existing.
Company sign-in is not the whole permission model
The original chatbot had an obvious problem: intended users couldn't enter. It's tempting to take the opposite approach and let everyone with a company account into every internal app.
That might be enough for a low-risk lunch-order form. It is much less convincing for a tool that reads customer agreements, personnel records or financial approvals.
Authentication asks who the person is. Authorization asks what that person is allowed to see or do. Being an employee doesn't automatically answer the second question, and appearing in an app catalog doesn't grant the right to read the data behind it.
There are two distinct WorkOS source moments here. In the earlier conference talk, Galow discussed finer group-based or role-based permissions as future development. In a separate WorkOS account of its October 7, 2026 init() event, published the following day, a later Atlas demonstration showed a sales-group restriction being changed and a demo user losing access. The recap also described a fictional Customer 360 breach scenario staged for the demonstration, followed by examples of sign-in, connected data and notes persisting across a refresh.
The staged breach was not a real incident. A stage demonstration of a permission control is also not evidence that all production deployments already enforce that control, or that the platform's security and incident response have been independently tested.
I find it more useful to separate the permissions than bundle them into the word secure. A person may be allowed to open an app but not export its data. They may be allowed to read a record but not edit it. They may be allowed to draft an action but not approve it. Each of those decisions can have a different owner.
Deploying an app doesn't authorize everything inside it
One detail from Galow's examples deserves more attention. He described a changelog tool that helped staff prepare updates, while publishing the finished company announcement still involved review.
That separation matters. Permission to create and deploy software isn't the same as permission for the software to perform every consequential action it offers.
Consider a hypothetical sales assistant. It can have a working interface, an approved hosting environment and valid employee sign-in, and still lack a decision about whose customer records it may retrieve. If it can update the CRM, there's a second decision about whether the user or tool may write those changes without review.
The maker may be best placed to describe the sales problem. A data owner may need to approve access. Someone responsible for the business workflow needs to decide which actions require a human decision. Platform engineering can make the application available without silently becoming the person who authorizes every use of its data.
This is where an internal app stops being just a technical artifact.
It begins making claims on other people's work and on the organization that supplies their information.
The app still needs a product owner
Suppose the platform handles sign-in, deployment, secrets and storage. I would still want answers to four quite ordinary questions before treating an employee-built tool as an ongoing service.
Who owns its purpose and data boundary? A named person should be able to explain what the app is for, which colleagues it serves and what information it is permitted to use. A link in a catalog tells me where the app is, not whether anyone has accepted responsibility for its scope.
Who can approve changes? A builder can revise a screen or connect a new API quickly. Colleagues relying on the existing behavior may not find that exciting. The team needs some way to recognize the current version, check behavior that matters and reverse a harmful change. A low-risk utility needn't inherit a heavyweight release process, but someone can change it is not a complete change policy.
Where does a user report a failure? The answer might be a named builder, a team channel or a shared support path. What matters is that a problem has somewhere to go, and someone can distinguish an app-specific defect from a failure in the shared platform. The original creator's temporary workspace isn't a durable escalation arrangement.
Who can retire it? Internal tools can outlive their source data, their owners and their purpose. Credentials may need revoking, records may need retaining or migrating, and the old app may need removing from discovery. Publishing a tool should come with some way to stop publishing it.
Those are my proposed handoff checks, not a description of WorkOS policy. The available talk and event recap say more about creation and distribution than about long-term support assignments, backup results, incident response or retirement. That gap in public evidence doesn't establish that WorkOS lacks those practices. It means this example can't verify them for us.
An acceptance test that matches the risk
I'd resist making every experimental app satisfy a production checklist before anyone can try it. That would solve the risk of unmanaged internal software by making useful experiments unnecessarily hard.
A small, low-risk team utility might need only an agreed owner, company sign-in where appropriate, a clear data boundary, a way to report errors and a decision about whether it should be kept. An app reading sensitive records or writing authoritative business data has a different failure cost. It may need narrower permissions, approvals for consequential actions, access reviews and a tested way to back out harmful changes.
The distinction isn't engineer versus non-engineer. It's the consequence of someone else relying on the result.
Galow also reported internal app counts and cases where engineers weren't present in an app's commit history. Those numbers may say something about who can now produce application code, but they don't measure engineering consultation, platform maintenance, support quality or business value. A tool receiving requests isn't, on its own, proof that it gives correct answers or has a responsible owner.
I would ask a simpler question on the first day another employee is expected to rely on an app: can they find the right version, enter with the right permissions, use approved data, report a failure and reach someone empowered to fix, restrict or retire it?
The prototype may have been finished when it worked for its creator. The shared product isn't finished by the same test.
// End of transmission. Ownership comes after launch. — ZYANE