AI Agents Make You a Software Company
AI agents do not spare you from becoming a software company. They just make the bill arrive faster while executives f...
From AI Experiment to a Dependable Business Service
13 min read
The Useful Experiment Deserves a Future
27.10.2026, By Stephan Schwab
An employee finally automates the annoying task everyone has tolerated for years. Colleagues start using the result. Excellent. Then the business begins depending on it, while the employee still has another job. AI has made that transition easier to reach, and custom software cheaper to build. The useful next step is collaboration: bring the working experiment, the process knowledge, and the CTO together with experienced developers. A convincing demonstration gives them something concrete to examine. A dependable service needs decisions about behavior, exceptions, and who keeps it working.
Consider an illustrative example. An operations employee at a small wholesaler spends every morning reading customer emails, finding product codes, and preparing draft orders. The ordering system expects tidy fields. Customers prefer sentences, photographs, and yesterday’s terminology.
She tries ChatGPT, then gives Claude Cowork a few examples. After some corrections, it prepares useful order drafts. She checks them. It saves time. A colleague asks to use it too.
This is a good development. Someone close to the work has found a way to improve it, and the experiment reveals more than a meeting about digital transformation ever did.
Then the drafts become the normal way orders enter the business. Other people stop doing the old preparation. Her manager assumes the assistant will run every morning.
Nobody decides that she now operates a business service. Apparently that responsibility came free with her curiosity.
The CTO has a useful opportunity here: help turn demonstrated value into something the company can depend on. That means working with her, preserving what she learned, and choosing machinery the business can maintain.
The Cloud Agents Are Real. Their Boundaries Differ.
A computer that keeps running is useful infrastructure. It does not decide your business rules or take responsibility for the result.
The offerings have moved well beyond a chat window that disappears when you close your laptop. They can use tools, retain context, and continue delegated work in the background. But “cloud agent” covers several different arrangements.
The comparison below reflects vendor documentation checked on 15 October 2026. It describes documented capabilities, not hands-on reliability results. Availability can differ by account, plan, region, and administrator settings; eligible does not always mean enabled.
| Offering | Execution and persistence | Integrations, permissions, and controls | Documented access |
|---|---|---|---|
| OpenAI Dots | Its own cloud computer and browser, saved context, and ongoing responsibilities. Cloud work continues with your devices off. | Connected plugins retain their permissions; local access needs a connected online computer. Workspace administrators control capabilities and app actions. | Gradual rollout to eligible accounts; confirm plan, region, and workspace access. Enterprise administrators grant access through workspace permissions. See Dots and workspace controls. |
| Grok Bot | A persistent cloud computer per user in Cursor’s cloud. Every Bot belonging to that user shares its files and browser logins. | Shell, browser, computer use, and permitted connectors. Network controls, action recording, and enforced approval policies require Enterprise. | Team administration is documented for Cursor Teams and Enterprise, with different controls. Confirm the intended account’s access. See architecture and administration. |
| Meta Muse | A dedicated virtual machine; work continues after the app closes. Context supports ongoing goals. | Business connectors include Meta accounts and third-party tools. Meta says publishing, sending, and spending need approval. | The announcement identifies US and Canada availability; small-business skills and connectors were added in September. See Muse and Muse for Small Business. |
| Claude Cowork | Cloud sessions save work and support scheduled tasks. New Pro and Max tasks run in the cloud from 6 October; earlier local tasks remain local. | Connectors, skills, and plugins. Local folders require the desktop app to be open and connected. Team/Enterprise owners have monitoring controls. | Pro/Max cloud sessions; cloud Cowork is beta on Team/Enterprise. A unified chat-and-task experience is also rolling out under the Claude name. See current availability and access safeguards. |
| Perplexity Computer | Cloud workflows continue in the background; recurring tasks and multiple models support longer work. | Configured connectors and reusable skills; enterprise administrators control users and connectors. The vendor distinguishes its development environment from production hosting. | Enterprise Pro and Enterprise Max are documented in the Computer workshop FAQ. |
| Manus Cloud Computer | Persistent Ubuntu virtual machine: files, installed tools, and processes survive between sessions. Ordinary Manus task sandboxes are temporary. | Command-line applications, scripts, and bots can run continuously. The overview does not establish a company-wide approval or audit model; check that separately. | Requires an active plan; Manus can assign the persistent environment when a task needs it. See Cloud Computer. |
| MiniMax MaxClaw | Vendor-hosted OpenClaw with long-term memory, cloud storage, and recurring work. | Browser and file tools plus messaging integrations including Telegram, Discord, and Slack. The product page is not evidence of enterprise permission controls. | Offered through MiniMax Agent with one-click deployment and vendor-managed updates. See MaxClaw. |
| Kimi Claw | Hosted OpenClaw with long-term memory; alternatively, link an existing instance on your own device. | Chat-channel integrations and group collaboration. Group owners control membership and visibility; those controls do not establish what connected systems allow. | Hosted deployment requires Allegretto or higher. See Kimi Claw and group controls. |
| OpenClaw, self-hosted | You choose and maintain the host, storage, model access, and integrations. Persistence depends on that deployment. | Tool policy, access controls, and sandboxing need configuration. One gateway assumes one trusted security domain, not isolation between mutually untrusted users. | Available for self-managed deployment; operating it is your responsibility. See the security model. |
| Microsoft Copilot Cowork | Multistep Microsoft 365 work and recurring tasks in an isolated environment. Output files persist in OneDrive/SharePoint. | Acts with the user’s permissions; approvals, plugin controls, audit records, and usage limits sit within business administration. Some browser work uses the user’s local Edge. | Generally available; spending policies grant access and enable usage-based billing. See administration and the FAQ. |
MaxClaw and Kimi explicitly describe OpenClaw-based offerings. That does not establish an OpenClaw architecture for Dots, Muse, Cowork, or the rest. Similar-looking delegation is not evidence of shared internals.
Gemini Enterprise belongs in a different comparison: an organizational platform for discovering, building, deploying, and governing agents, with capabilities that depend on edition. Salesforce Agentforce combines model reasoning with explicit flows, code, and API actions inside business processes. Neither is simply another personal cloud computer with a new badge.
These distinctions matter when choosing a tool. They do not settle who owns your order workflow. A vendor can maintain the computer while your business still owns the rules, connected accounts, exceptions, and consequences.
The Office Macro Has Learned to Read the Email
Employees solving problems close to the work is an old pattern. Interpreting messy inputs and choosing actions gives that pattern new reach.
Excel workbooks, VBA macros, Access databases, small scripts, low-code workflows, and RPA all began with some version of “there must be a better way to do this.” Often there was. The person doing the job could see a problem that the official project queue had not reached.
The adoption pattern is familiar. The capabilities are different.
An agent can interpret an email that does not fit a template, investigate an unfamiliar product description, compare information from several systems, and decide which tool to try next. Persistent context helps it carry decisions forward. Broader tool access lets it act beyond the original spreadsheet.
Cloud execution and scheduling are older than this wave of agents. Office Scripts and Power Automate already support scheduled and event-driven spreadsheet work, without somebody keeping Excel open. The meaningful change is the model interpreting inputs and selecting actions where the old workflow needed explicit instructions for each branch.
That is useful when interpretation is needed. It is also a poor reason to make established rules negotiable.
In our illustrative order workflow, reading “another box like last time” may need interpretation and a question. Applying the agreed price, checking the customer account, and preventing a duplicate order should follow explicit rules. The agent can call tools that enforce those rules. It need not invent the ordering procedure anew.
Deterministic code can contain bugs. Agent-selected tools can execute deterministic code. The useful distinction concerns where you allow judgment and where the business needs a repeatable decision it can test.
The lesson from modernizing legacy VBA still applies: find the real behavior, examine exceptions, and turn the important examples into executable checks. A prompt does not exempt the workflow from that work.
Custom Software Has Become a More Accessible Option
AI lowers the cost of building a defined workflow. That makes purpose-built software worth comparing with repeated delegation to a general-purpose agent.
There is another economic change hiding behind the cloud-agent announcements. AI can also help experienced developers create the machinery itself faster.
For a well-scoped workflow with known rules and usable integrations, AI can reduce the effort spent writing and revising code. Test that saving on a small working slice of the actual process before promising a delivery date. Unclear requirements, inaccessible systems, migration, and organizational decisions do not become small because the model types quickly.
That is a reason to revisit an old assumption: that buying a general-purpose tool must be cheaper than building a small service for the actual job.
For the wholesaler, the service might read an incoming request, extract a proposed order, validate product codes against the catalogue, apply the agreed pricing rules, and present ambiguous cases for a person to resolve. Approved orders enter the ordering system through a controlled integration. The result records what happened.
A model can still handle language interpretation. The workflow around it can have a defined sequence, explicit permissions, and tests for known exceptions. If the same message arrives twice, the second attempt must not create another order. If the customer account is blocked, the service must stop before submitting anything.
These decisions become part of the system instead of instructions somebody hopes the general-purpose agent remembers during every run. The business can test them again when the implementation changes.
There are costs on both sides. Agent runs consume resources and somebody’s review time. Custom software needs hosting, dependency updates, integration maintenance, monitoring, and recovery work. Compare the recurring costs and the failure consequences along with the first build.
Cheaper creation makes the choice more interesting. It does not make either option self-maintaining.
Curiosity Is Not an Operations Contract
Knowing the process gives an employee valuable expertise. It does not give them spare time, operating authority, or technical judgment by appointment.
Home Assistant offers a useful analogy. Tinkering with household automation can be satisfying. You learn what a device can do, adjust a routine, and fix something when you have time. Then other people depend on the heating, lights, or alarm working while you are busy with your actual occupation.
The dependency changes the job. Knowing which room needs heating does not automatically teach you how to diagnose every integration failure. Being interested does not mean you agreed to provide support whenever it breaks.
The same applies at work. The operations employee knows why an order matters, which product descriptions are ambiguous, and which customers have special arrangements. That knowledge deserves a place in the solution. She may have neither the time nor the experience to judge a retry strategy, maintain authentication, or recover a partially completed transaction.
Return to the illustrative workflow:
- The ordering system accepts an order, but the connection drops before the assistant records success. A retry can create a duplicate.
- A saved login expires. The scheduled run waits for a sign-in while colleagues assume the orders are ready.
- A price changes between preparing and submitting the order. Someone must decide which price applies.
- Several requests finish and one fails. Restarting the whole batch can repeat completed work.
- The original employee leaves. Her replacement inherits the business process, but the automation still lives under her account.
Those are ordinary operating questions. They require defined behavior and someone who can act when the definition is not met.
In an SME, the first visible problem may simply be ownership: everyone uses it, nobody has time to maintain it. In a larger company, unmanaged accounts and integrations also become shadow IT. Microsoft’s Shadow AI public preview provides detection and limited blocking for unmanaged agents on managed devices. The concern has already reached the administration console.
Blaming the employee would miss the point. She demonstrated a useful improvement. The organization needs to decide how it will support the thing it chose to rely on.
Bring the Experiment to the CTO and the Developers
A working experiment gives professional collaboration concrete evidence: useful behavior, awkward examples, and decisions worth making together.
An abstract request for “AI-powered order processing” leaves a lot to guess. An employee who can show ten real examples, three corrections, and the point where the assistant gets confused brings something much better.
The experiment becomes a shared object to examine. What did it understand correctly? What did the employee quietly repair? Which decisions came from company policy, and which came from the model making something up? Where did the apparent success depend on her being present?
That is a productive starting point for our consulting work: sit with the employee and the CTO, follow the actual process, and make the necessary decisions together. Bring developers and vendors into the parts that need their knowledge. The employee supplies process expertise; technical experience helps choose a maintainable implementation and evidence of success.
Developing Nilo Assistant keeps making those responsibilities concrete. A service that sends an email needs to know what happened if it stops after the mail provider accepted the message. Recording success, recovering uncertainty, and avoiding another send are part of the feature. A friendly conversation alone cannot settle them.
The same questions belong in the employee’s experiment. Clarify the what before polishing the machinery: what should happen, what must never happen, what needs approval, and what should happen after an interruption.
Capture examples and exceptions as tests. Stabilize integrations. Check permissions where actions execute. Make failures visible to someone who can respond. Decide which parts can stay agent-driven and which deserve explicit code or a controlled workflow.
The CTO should be part of those decisions. Outside help strengthens the existing team when it connects business intent, software behavior, vendor limits, and operations. Going around the CTO merely moves the ownership argument into the next incident.
Some customers need help building the service. Others also need someone to operate it. Those are separate commitments, with different work and different costs. State both clearly, including who changes the rules and who responds when a dependency fails.
Finished Means Someone Can Depend on It
Dependable use requires defined behavior, visible failures, recovery procedures, maintained dependencies, and an accountable operator.
“Finished” is an awkward word in software. People often hear it as permission to stop paying attention. A business service needs a more useful meaning: fit for dependable use, with ongoing ownership.
For the order service, that means the accepted behavior and exceptions are explicit. Important promises have executable checks. An operator can see failed and uncertain work, distinguish it from completed work, and recover without blindly submitting everything again. Integrations and credentials have maintainers. Someone besides the original enthusiast can operate it.
The fallback matters too. If automation is unavailable, who prepares the orders, and how does the business avoid processing the same request twice when service resumes? “We will do it manually” needs an actual procedure, not a reassuring wave toward the operations department.
These requirements apply whether the result runs inside a vendor’s agent, a self-hosted system, or a small custom application. A managed platform may supply useful controls. Your company still needs to decide the behavior and fund the operating work.
AI Agents Make You a Software Company made the ownership argument. The practical opportunity now is to make that responsibility affordable: use experiments to discover value, use AI-assisted development to build the right machinery, and give the result an operating home.
Encourage the curious employee. Bring the CTO and experienced developers into the work before the experiment becomes somebody’s unacknowledged second job.
AI makes useful machinery cheaper to create. Turning it into a service remains someone’s job.
Talk It Through
Tell me what is happening. I listen, ask a few practical questions, and reflect back what I see: where the risk may sit, what may be blocking delivery, and what looks worth checking next. No pitch, no obligation. Confidential and direct.
Talk it through. Practical reflection, no pitch.
Start a Conversation
