In part one of our conversation with John Godlove and Piyush Agarwal, co-founders of Fusion Hive, we talked about starting with the workflow instead of the AI. Before choosing a model or building an agent, you need to understand the problem. You also need to understand the process, the data, and what you’re trying to improve.
In part two, we took that conversation further. We looked at what happens when you move from an AI demo into something a business actually depends on. That’s when governance, data privacy, testing, guardrails, monitoring, and cost become much more important. Piyush made a comment that sums this up well. If your workflow is already broken and you throw AI at it, you’re probably going to accelerate the chaos.
About John Godlove and Piyush Agarwal
John Godlove is co-founder of Fusion Hive and has more than a decade of experience helping organizations from startups to Fortune 500 companies build and deploy automation. His background includes work in the Salesforce ecosystem, AI, data, and technology implementation.
Piyush Agarwal is co-founder of Fusion Hive and has more than a decade of experience in artificial intelligence and machine learning. His experience includes financial fraud detection, document intelligence pipelines, generative AI multi-agent architectures, and production machine-learning engineering.
Together, John and Piyush founded Fusion Hive to bring enterprise AI and automation experience to small and mid-market businesses. Their approach focuses on practical workflows, measurable outcomes, governance, and production-ready AI systems.
AI Has a Way of Exposing Problems You Already Had
We’ve been talking all season about AI exposing the cracks in businesses and software development. This conversation was a great example of what we mean. Many businesses don’t have perfectly documented processes. The official procedure may say one thing, while the person doing the job follows a slightly different process because they know what works.
Sometimes that critical business knowledge isn’t documented anywhere. It may be sitting in someone’s head, buried in an email, or handled through an informal process. Humans are pretty good at filling in those blanks and making judgment calls. Software needs us to be much clearer about the rules.
John explained that small and mid-market businesses don’t always have mature governance structures. Regulated organizations tend to have more structure because regulations require it. Other companies may not discover these governance problems until they start looking seriously at AI. The AI project doesn’t necessarily create the crack. It often shines a light on something that was already there.
That can actually be a good thing. An AI project may force you to understand how your business really works. It can push you to document processes, identify ownership, and clean up your data. You may get significant value from that work before the first AI workflow ever reaches production.
AI Governance Is Bigger Than AI
When I asked John and Piyush about governance and protecting customer data, one thing became pretty clear. You can’t treat AI governance as something that exists by itself. Your business already has systems, users, data, security policies, vendors, and access controls. The AI system has to live inside that environment.
Piyush explained that Fusion Hive tries to work within the systems a customer already uses. They don’t automatically introduce another platform. A business may already be heavily invested in Microsoft, Google, Azure, AWS, or another ecosystem. Those existing systems may already provide infrastructure that can support the new workflow.
John added that internal IT departments and managed service providers also need to be part of the conversation. AI governance overlaps with data governance, cybersecurity, access controls, and existing policies. You can’t build one without considering the others.
I think that’s an important way to look at this. AI may feel like an entirely new technology problem, but it’s still another component in your business systems. You still need to know who can access information, where that information goes, and who owns the process when something fails.
Know Where Your Data Is Going
Data privacy becomes even more important once AI enters the conversation. Before connecting business information to a model, find out where that data goes and what happens to it. Does the provider retain it? Can the provider use it for model training? Does the platform provide the protections your business needs?
Those questions become critical in healthcare, financial services, and other regulated environments. Piyush talked about cases where businesses may need specific configurations or agreements with providers. These protections can prevent providers from using company data for model training.
He also pointed out that not every use case requires a frontier model. A smaller or open model may work for some problems. That option may also give the business more control over where and how it processes information.
The exact solution depends on the business. The important thing is to ask these questions before implementation. You don’t want to connect company data to an AI system and then ask where that information went.
The Wrong Use Case Can Make AI Expensive Fast
When I asked John and Piyush about mistakes they’ve seen businesses make with AI, John’s answer wasn’t some crazy technical failure. One of the biggest mistakes is simply choosing the wrong use case.
A business leader hears that the company needs AI. Somebody gets a directive to “get AI live,” and the team builds something impressive for a demo. But nobody defines what business metric the project should improve.
John suggested working backward from the business outcome. Maybe you want to improve margins or reduce turnaround time. Maybe you want to shorten lead qualification or improve the lead-to-cash process. Once you know the target, you can trace that goal back to the workflows that influence it.
This is where I think many AI projects can get into trouble. “We implemented AI” isn’t a business result. If you don’t know what you’re trying to change, you may spend money without knowing whether the investment helped.
You Need a Baseline Before You Can Measure ROI
Of course, that creates another problem. Some businesses don’t know how their existing processes perform today. They know people are busy and a workflow feels slow. But they haven’t measured the time, exceptions, rework, or actual cost.
John talked about measurements such as cycle time, quote turnaround, lead qualification, and lead-to-cash timing. Those numbers give you something to compare after you introduce automation. If a process took 40 hours before AI and takes 20 afterward, you have a measurable improvement. The same applies if errors drop or turnaround improves.
Without a baseline, you’re guessing. Six months later, you might have a cool AI system. But when somebody asks what it saved the company, the answer can’t just be that everyone seems to like it.
Don’t Automate a Broken Process
This is where Piyush made one of the strongest points of the interview. If the workflow is already broken, AI will accelerate whatever already exists. That includes the chaos.
Bad data doesn’t suddenly become good because an LLM reads it. Unclear ownership doesn’t disappear because an agent performs the task. If nobody can tell you whether the result is correct, you’re probably not ready to hand that process over to AI.
Before you automate, you may need to clean the data or document the rules. You may need to fix the process or determine who owns the outcome. That work can slow down an AI project at the beginning, but I’d rather find those problems before production than after.
This reminds me of what we see in testing and automation. Automating a bad test or a bad process doesn’t make it better. It just lets you run the wrong thing faster and more often. AI gives us more capability, but that basic engineering principle hasn’t changed.
Evaluation, Guardrails, and Monitoring
This was probably my favorite technical part of the conversation because it lines up with my testing and integration background. Piyush identified three areas that matter when moving an AI workflow toward production:
- Evaluation
- Guardrails
- Monitoring
Before production, you need to evaluate the workflow against known data. Piyush described maintaining a holdout or “golden” dataset with known expected results. You can run the workflow against that data and check whether the system produces acceptable results.
For developers and testers, this should sound familiar. We’ve been doing versions of this forever. Give the system a known input, define the expected output, run the test, and compare the results.
AI changes how predictable some outputs may be. It doesn’t remove the need to test them. In fact, I think AI’s variability makes evaluation even more important.
Put Guardrails Around What AI Can Do
Testing the output is only part of the problem. Once an AI system can take actions, you need to decide what it’s allowed to do. We’ve already seen examples of public-facing AI systems producing ridiculous results because nobody properly constrained them.
Guardrails should define where the AI has authority and what requires validation. They should also define when the system needs to stop and ask for help. Some decisions may require deterministic rules, while others may need human approval.
This is another place where I don’t think we should look at the problem as AI versus humans. A better solution may combine AI, deterministic software, validation rules, and people. Give each part of the system the job it’s actually good at.
Deployment Isn’t the Finish Line
Piyush’s third piece was monitoring. I think this will become increasingly important as more companies put AI into production. You don’t test the system once, deploy it, and forget about it.
You need to watch what happens after release.
- What questions are users asking?
- What does the system return?
- What new exceptions appear?
- Where does it get confused?
Those production interactions can become part of the feedback loop that improves the system.
That’s not very different from what we’ve learned from building software for years. Production teaches you things your test environment never will. AI can make the behavior less predictable, which makes monitoring and ownership even more important.
Don’t Forget the People Using the System
You can choose the right use case, design the right architecture, and test everything correctly. The implementation can still fail if nobody uses it.
John talked about enablement and training as a critical part of the rollout. This becomes especially important when AI changes an existing business process. Employees need to understand what changed, how to use the new system, and why the organization made the change.
You also need to deal with the obvious concern that employees may think AI is there to replace them. If that’s what people believe, don’t be surprised when adoption becomes difficult. We’ve dealt with change management in software projects forever. AI hasn’t removed the human side of implementation.
The Most Powerful Model Isn’t Always the Right Model
Our bonus conversation moved into another area that more businesses are starting to discover: running AI in production can get expensive. Most people first experience AI through ChatGPT, Claude, Copilot, or another chat interface. Production workflows can look very different.
An agent might ingest emails, read PDFs, extract information, transcribe documents, and call other systems. Now imagine doing that thousands of times. John explained that businesses need to understand these cost drivers because AI expenses can vary much more than a traditional monthly SaaS bill.
Piyush made another good point here. The biggest and most capable model isn’t automatically the right model for every task. If you’re doing a simple email summary, do you really need the most expensive frontier model available? Probably not.
Route the Work to the Right Tool
This brought us back to something we discussed in part one. Sometimes the right solution isn’t AI at all. Piyush described task-based routing, where the system decides what capability a particular task needs.
A simple request might go to a smaller model. A complex reasoning problem could go to a more capable model. A deterministic task might go directly to traditional code. This approach can improve cost, speed, and predictability.
John also talked about making systems LLM agnostic. You don’t want to lock an entire business process into whichever model happens to be popular today. This market moves incredibly fast, and today’s best choice may not be the best choice a year from now.
That’s more than a technical architecture decision. If you’re building something the business expects to run for years, you need to think about changes in pricing, vendors, and technology.
Build for the Business, Not the AI Trend
The biggest thing I took away from this second part of our conversation is that successful AI implementation looks a lot like good engineering. Understand the problem, know where your data comes from, establish ownership, and define the expected outcome. Then test the system, add controls, monitor production, and make sure the people using it understand the change.
AI gives us some incredible new capabilities, but it doesn’t make those fundamentals disappear. If anything, it makes the cracks more obvious when we skip them.
Before you automate that next process, take a hard look at what you’re actually automating. If the process is broken, the data is bad, nobody owns the outcome, and you can’t measure success, AI probably isn’t your first problem.
Otherwise, you may not be automating your business. You may just be automating the chaos.
Stay Connected: Join the Developreneur Community
👉 Subscribe to Building Better Developers for more conversations on momentum, leadership, and growth. Whether you’re a seasoned developer or just starting, there’s always room to learn and grow together. Contact us at [email protected] with your questions, feedback, or suggestions for future episodes. Together, let’s continue exploring the exciting world of software development.
Additional Resources
- AI Governance Framework: Why Guardrails Help AI Move Faster
- AI Governance Framework: Why Every Business Needs Guardrails Before AI
- AI Governance Implementation: Turning AI Policies into Everyday Practice
- AI Implementation Guardrails: How to Scale AI Without Scaling Your Mistakes
- Building Better Developers Podcast Videos – With Bonus Content