I spent 25 years in enterprise IT, much of it as a CIO. When I started Graytitude, we focused on mainframe DevOps modernization for banks, insurers, utilities, and government agencies: moving decades-old source control to Git and building CI/CD pipelines on systems that can’t go down. That work put us inside a lot of large enterprises, and we kept seeing the same thing. Very little of their automation actually worked end to end. My co-founder Sanjay Chandru and I built Argo Intelligence to close that gap. What sets it apart is where it runs and who stays in control. It ships with models and inference included, but a customer can run it on their own infrastructure, bring their own model, and connect it to any system with an MCP server or an OpenAPI spec. Their data stays where it is, and a person approves anything consequential before it happens. We didn’t design it in a lab. It comes from years of doing this work inside regulated companies.

Graytitude’s first customers came through relationships. I’d spent my career on the buyer’s side of the table, so I knew how a CIO decides who to trust with a critical system: someone who has done it before and will still answer the phone after go-live. We earned that one engagement at a time, and partnerships with IBM, Ensono, Broadcom and Rocket opened doors to companies such as TD Securities, Visa, AutoZone and Exxon Mobil. Argo’s beta customers came the same way. They were existing clients who had watched us deliver and were willing to test something new with us. Today most new business still comes from referrals and partners, and we’ve added a focused outbound effort aimed at mid-sized banks and insurers who are under pressure to modernize their mainframe operations but don’t have a large in-house team to do it.

The decision was turning our services into a product. For years, our knowledge lived in the heads of our consultants. Every engagement started close to scratch, and we could only grow as fast as we could hire. Building Argo meant taking what we had learned on dozens of projects and putting it into software that does much of the work, with our people overseeing it. We call that service as software. Customers still need the expertise, but projects finish faster and cost less. The mistake: when we first described Argo, we led with automation. Buyers heard “another bot” and filed us with tools they had already tried. What they cared about was who controls the data, what happens when something goes wrong, and whether it would survive contact with their real systems. Once we started there, conversations changed.

Two years ago, most executives wanted to know what AI could do. Now they ask where their data goes, who owns the model, and what it costs to switch. In banking and insurance, those questions come from regulators and boards, not just IT. At the same time, the people who know mainframe systems best are retiring, and companies can’t hire their replacements fast enough. So customers want two things that can seem to pull against each other: more automation, and more control over it. We built Argo around both. It can run entirely inside a customer’s environment; it records what every agent did and why, and it waits for human approval at the points that matter. On the mainframe side, we capture how a company’s systems actually work so that knowledge doesn’t walk out the door with the next retirement.

First, spend time with the people who do the work you want to automate. Not the executive sponsor, the people processing claims or managing releases. Pick one task with a cost you can measure, get it running in production, and let the result make your case for you. Ignore the weekly argument over which model is best. Models change every few months, and your customers don’t buy a model. They buy a result they can rely on, with a clear answer to “what happens if this goes wrong?” Build for that, and keep your architecture open enough to swap models as they improve.