When I write my software as skills that combine command-line tools, my own computer becomes part of the system. That is useful, but it also changes the question of where the software really lives.
If the skill runs on my laptop, then my laptop matters. When I close it, the agent stops working. That is fine for personal experiments, but it starts to feel different when the skill becomes important for other people too.
From personal setup to company infrastructure
In companies, the default answer is usually to run code in the cloud. That is the normal shape of modern software: put it on a server somewhere, keep it running, and make it available to the team from there.
Agent software reopens the question. If the useful thing starts as a prompt, a markdown file, or a skill that calls existing tools, when does that become an actual piece of software?
Maybe the first version is not the final shape
A lot of this work begins locally. One person writes a prompt, adds a skill, combines a few command-line tools, and suddenly something useful exists. Maybe it reads mail, checks Jira, runs a script, or controls a browser.
At first that feels personal and temporary. But sometimes it keeps getting used. The markdown file gets shared. The prompt gets copied. The skill gets better. More people want the result. At that point, it starts to feel less like a trick and more like software.
So where should it run?
That is the real infrastructure question. Should we have a computer at the office that does this? Should we have a place where the skills run? Not just a cloud service in the abstract, but a stable environment that belongs to the company and keeps the useful workflows alive even when one person goes home.
That environment could still be simple. It could just be a Linux machine, an agent runtime, a folder of skills, and a few logged-in tools. It does not need to begin as a giant platform. But it probably does need a home.
When does it become software?
My answer is simple: it becomes software when it stops being only personal memory and starts to become shared capability. A prompt in my notes is just a prompt. A prompt the team reuses to get work done is already closer to software.
The same goes for a markdown file. If it only reminds me what to do, it is documentation. If an agent reads it, follows it, and produces reliable work from it, then it has started to cross over into software.
What changes in a company
In a company setting, reliability matters more than cleverness. That means the question is not only whether a skill works, but whether it can keep working without being tied to one person's open laptop.
Each person may need their own personal agent for personal work, while the company has a place where the shared skills run. That feels more realistic to me than pretending everything should either stay local forever or immediately become a giant cloud product.
The interesting middle layer
This is the layer I keep thinking about. It sits between local hacks and a full formal platform: a shared machine, a team runtime, a place where prompts, markdown instructions, and skills can become repeatable work.
That may be where a lot of prompt-based software really begins.