TL;DR
- Software is no longer expensive to write. We built a week of regimented happy paths, then rewrote the whole thing agentically in two days.
- Behavior buy-in is harder than architecture buy-in. The risk is not the design, it is persuading a utility to put an AI agent in front of its customers.
- Traditional software processes optimize for efficiency. AI product building has to optimize for trust, because the question is not what by when, it is whether it will work reliably.
- Owning the workflow and generating an outcome are not moats any more. Your competitor will do both. The sequence you ship in is what separates you.
We had an interesting week at Moative.
I am in New Orleans this week. One of the highlights for me is to demo a mind-blowingly cool demo of Billie, an AI agent that handles billing and outage reporting/questions from residential home owners, on behalf of the local utilities.
I am going to break down how we approached the build-out and the lessons from it.
The brief, and the traditional route
The brief is fairly simple. There are a handful of questions that a resident will have about their billing.
- What’s my bill?
- How do I reduce it?
- Can I delay the payment?
- (If they are on prepaid), how do I extend my validity period?, and so on.
The traditional software development lifecycle would have had the following steps:
Requirement Gathering (Too many back and forth questions/clarifications because we are still rooted to the belief that writing software and re-writing it is expensive. Requirement gathering is a ‘cover all based’ act.)
Design (There is user flow, information flow, user experience, architecture, database design, may be even test cases. You get the idea. All important, even in AI. But each activity leads to meetings. How are we going to access data? Who needs to get IP whitelisted, where is the user flow diagram, how do we handle latency, etc. – all valid questions and it may take weeks to resolve them perfectly)
Development (The actual act of building the chat bot. Here too, you can go a couple of ways. Map out all the happy paths (the expected questions and the expected answers), check them off one by one and voila you get a chat bot – except that it will be robotic. Traversing across threads, linking them, keeping a decent memory of conversation – all of these are better done through agentic design than hand-building the interactions. What about hallucinations and other unexpected things like memory drops? Hold on to those questions.
Testing and Launch (Model evals based on a multi-faceted criteria, objective scoring instead of vibe-scoring of model performances, user-experience, behavior-alignment, tone testing etc. We don’t have a standard testing framework yet for AI products. Things are evolving)
We could fight like a valiant enterprise program manager with the knowhow gained from all the PM certifications we have subjected ourselves to or just do stuff and show.
Speed, not process
In AI, the moat is not the process, yet. It’s speed.
- Software development is not costly. We went through regimented happy paths over a week and then rewrote to agentic methods in 2 days. Its that easy.
- Behavior buy-in is harder than architecture buy-in. In our case, the biggest risk is in getting utilities to put AI in the front line. We have to show that it works. The ‘how’ of it comes once they buy the premise.
- Address the main anxiety. Traditional software development optimizes for efficiency. AI product building should optimize for trust. The question is not ‘what features at what cost by when’ but ‘will it work reliably.’ The traditional product building process will add to anxiety and not reduce it. No one has the patience to wait for weeks to see the chat working.
- Sequence of what matters: It can work → It works reliably → It can be tested and continuously observed → Its secure and compliant → It can scale economically → It can do everything. The easiest promise to make is to say that the bot will do every thing. In our experience, the users are very happy getting even an hour of their day back, even if the agent won’t do everything.
Product managers are used to the ‘surface area and stickiness’ tropes. We need to own the workflow. We need to generate an outcome. Of course. Yes. But those are not moats anymore. Everyone can build. Your competitor is also going to generate outcomes.
The sequence that matters
What matters is the sequence. The sequence should prioritize shipping speed. It also matters that product managers educate the CIOs and the IT teams to ask the right questions and mostly, hold the horses.
The ‘it can work’ phase is not about resolving access questions. Create synthetic data and show that it works.
The ‘it works reliably’ is not about architecture but model performance and consistency.
Enterprises can waste cycles by getting ready for a mythical perfect launch and pre-maturely reigning in and slowing down the pace.
Users/buyers care that it works and delivers the promise. Then comes the desired enterprise IT friction of governance, security, cost, etc. This is when you slow down. Ideally, its a two-pod structure where one focuses on shipping demos and the other focuses on setting the guardrails.
Well, that’s all folks. Wish us luck for this weekend, as it is ‘show time’ for Billie. If you want to see Billie at work, hit me up and I will show a demo. He talks about power outages as fluently as he knows to slow cook chicken.
PS: I will be in SF, San Diego, Houston, Boston, Chicago and Stamford in the next few weeks. Let’s pour over a coffee?
Where Moative fits
Moative builds in that order on purpose: something working on synthetic data first, reliability second, and the governance conversation once there is a system worth governing. Billie is the utilities version. In healthcare revenue cycle management and claims processing the same sequence applies to denials and submissions, where trust has to be earned on a narrow slice before anyone widens the scope. The enterprise-side counterpart to this argument is in Snail-paced enterprise and Warp-speed AI.
Frequently asked questions
What is the real moat in AI products?
Speed, plus the data and distribution that come from being deployed. Building the software is no longer scarce, so the advantage goes to whoever gets to working, trusted deployment first.
Why optimize for trust rather than efficiency?
Because the buyer's blocking question is whether it will work reliably, not what it costs or when it ships. A process built around efficiency answers a question nobody is asking and lengthens the wait that causes the doubt.
In what order should an AI product be built?
It can work, it works reliably, it can be tested and observed, it is secure and compliant, it scales economically, it does everything. Attempting the last one first is the most common way to fail.
Is agentic design better than mapping every happy path?
For conversational work, generally yes. Traversing threads, linking them and holding conversational memory come out of agentic design naturally, whereas hand-built interaction trees produce something that behaves like a phone menu.
How do you prove an AI agent works without production data?
Synthetic data, in the earliest phase. Access negotiations belong to the reliability stage, not the feasibility stage, and treating them as a prerequisite stalls the project before anyone has seen value.
Should one team handle both shipping and governance?
Two pods works better. One optimizes for demonstrating value quickly, the other for the guardrails that let it survive production. A single team inevitably lets one objective smother the other. Can I delay the payment?(If they are on prepaid), how do I extend my validity period?, and so on. The traditional software development lifecycle would have had the following steps: Requirement Gathering (Too many back and forth questions/clarifications because we are still rooted to the belief that writing software and re-writing it is expensive. Requirement gathering is a ‘cover all based’ act.) Design (There is user flow, information flow, user experience, architecture, database design, may be even test cases. You get the idea. All important, even in AI. But each activity leads to meetings. How are we going to access data? Who needs to get IP whitelisted, where is the user flow diagram, how do we handle latency, etc. – all valid questions and it may take weeks to resolve them perfectly) Development (The actual act of building the chat bot. Here too, you can go a couple of ways. Map out all the happy paths (the expected questions and the expected answers), check them off one by one and voila you get a chat bot – except that it will be robotic. Traversing across threads, linking them, keeping a decent memory of conversation – all of these are better done through agentic design than hand-building the interactions. What about hallucinations and other unexpected things like memory drops? Hold on to those questions. Testing and Launch (Model evals based on a multi-faceted criteria, objective scoring instead of vibe-scoring of model performances, user-experience, behavior-alignment, tone testing etc. We don’t have a standard testing framework yet for AI products. Things are evolving) We could fight like a valiant enterprise program manager with the knowhow gained from all the PM certifications we have subjected ourselves to or just do stuff and show. In AI, the moat is not the process, yet. It's speed. Software development is not costly. We went through regimented happy paths over a week and then rewrote to agentic methods in 2 days. It's that easy.Behavior buy-in is harder than architecture buy-in. In our case, the biggest risk is in getting utilities to put AI in the front line. We have to show that it works. The ‘how’ of it comes once they buy the premise.Address the main anxiety. Traditional software development optimizes for efficiency. AI product building should optimize for trust. The question is not ‘what features at what cost by when’ but ‘will it work reliably.’ The traditional product building process will add to anxiety and not reduce it. No one has the patience to wait for weeks to see the chat working.Sequence of what matters: It can work → It works reliably → It can be tested and continuously observed → It's secure and compliant → It can scale economically → It can do everything. The easiest promise to make is to say that the bot will do every thing. In our experience, the users are very happy getting even an hour of their day back, even if the agent won’t do everything. Product managers are used to the ‘surface area and stickiness’ tropes. We need to own the workflow. We need to generate an outcome. Of course. Yes. But those are not moats anymore. Everyone can build. Your competitor is also going to generate outcomes. What matters is the sequence. The sequence should prioritize shipping speed. It also matters that product managers educate the CIOs and the IT teams to ask the right questions and mostly, hold the horses. The ‘it can work’ phase is not about resolving access questions. Create synthetic data and show that it works. The ‘it works reliably’ is not about architecture but model performance and consistency. Enterprises can waste cycles by getting ready for a mythical perfect launch and pre-maturely reigning in and slowing down the pace. Users/buyers care that it works and delivers the promise. Then comes the desired enterprise IT friction of governance, security, cost, etc. This is when you slow down. Ideally, it's a two-pod structure where one focuses on shipping demos and the other focuses on setting the guardrails. Well, that’s all folks. Wish us luck for this weekend, as it is ‘show time’ for Billie. If you want to see Billie at work, hit me up and I will show a demo. He talks about power outages as fluently as he knows to slow cook chicken. PS: I will be in SF, San Diego, Houston, Boston, Chicago and Stamford in the next few weeks. Let’s pour over a coffee?
