Begin with the process you want to own
Standard software gives a company an established product and operating model. Custom software gives it more control over the fit. Agents can change the effort required to explore a custom approach, but the decision still starts with business value. Which part of the process makes you different? Which parts are ordinary work that an existing product already handles well?
A useful starting point is a narrow gap: a recurring handover, a missing view of information or a small workflow that forces people to copy data between tools. Define the input, intended outcome and person responsible. Build a contained prototype to learn whether the proposed improvement solves the real problem. That learning can be valuable even if the final decision is to buy an existing product.
The application continues after the demo
Generating a first version is only one stage. A business application needs testing, security review, dependable access, recovery and someone who understands its behaviour. Changes to data sources, users and business rules keep creating maintenance work. A decision to build should include that continuing responsibility.
This is where an agent system becomes especially interesting. A feedback queue can capture bugs and ideas. Agents can organise reports, prepare changes, run checks and assemble a review package. The product owner decides priorities and release readiness. After an approved release, communication and feedback feed the next cycle. That is a proposed operating loop, with a clear owner at every consequential transition.
Choose models and infrastructure for the work
Different tasks can justify different models. The appropriate choice depends on capability, data handling, latency, cost and the way the system will be operated. Commercial services and local open-source models can form part of the same architecture. Local execution also brings hardware, maintenance and access-control responsibilities.
I help connect those decisions to a practical workflow: what the agent must do, what information it needs and how its result will be checked. Starting with a hardware shopping list or a favourite model reverses that order. The infrastructure should make the chosen process dependable and understandable to the people who own it.
Keep the first commitment small enough to learn
Choose a process with a visible pain point and a bounded scope. Compare a standard product, a small integration and a custom implementation against the same outcome. Include ongoing ownership and correction effort, not just the speed of the initial build. Use synthetic or approved example data while exploring the concept.
My original post was a provocation about the future of business software. The practical opportunity today is to ask better questions about what you need to own and what you can reuse. With the right operating system around development, agents can help turn those questions into working evidence. Bring the awkward process that standard software never quite seems to fit. That is a useful place to start.