Building Trustworthy AI Into Field Service Operations: An Interview with Zach Gardner, Chief Architect at a Top-Rated U.S. Custom Software Development Firm
We recently sat down with Zach Gardner, Chief Architect at Keyhole Software, a top-rated custom software development firm for mid-size to enterprise organizations across the United States. With over a decade of experience leading modernization initiatives and AI-accelerated delivery for clients in financial services, healthcare, and manufacturing, Zach shared a practitioner’s view on what it takes to build AI and agentic features that hold up in field service operations, not just in a demo.
As organizations increasingly adopt AI for dispatching, scheduling, customer communication, and operational decision-making, the conversation has shifted from whether AI can be implemented to how it can be implemented responsibly. Drawing on Keyhole’s experience designing enterprise software, modernizing legacy systems, and integrating AI into mission-critical applications, Zach explains why trustworthy AI depends less on the model itself and more on the engineering, governance, and architectural decisions surrounding it.
Q: Service businesses are handing more of their operations to AI agents, from dispatch to customer service. As an architect, what separates AI for field service management that a business can actually trust from features that just look good in a demo?
Zach Gardner: The difference is rarely the model itself. It is the governance, architecture, and engineering discipline around it. A demo is built for the happy path. Production AI in field service has to deal with messy data, edge cases, and the fact that its output affects a real job, a real customer, and real revenue. I read a study recently where a vast majority of customer support chatbots, that passed all of their internal QA testing, almost immediately failed when deployed in the field due to unhandled considerations, such as accents and regional dialectics and idioms, and the fuzziness of how people can communicate. Even the best governed AI model will still fall short if the end user is not truly understood and appreciated.
Trustworthy AI agents are constrained, auditable, and reviewable by design. In our experience, the teams that succeed treat an AI agent the way they would treat a new technician on the crew: you define what it is allowed to do, what information it can touch, and who checks its work before it acts on anything consequential.
That’s the philosophy we bring to every AI engagement at Keyhole. Our architects establish the guardrails first by defining system boundaries, data access, business rules, and validation strategies before AI is ever allowed to automate part of a workflow. AI can accelerate development and improve operations, but it should never replace sound engineering practices or accountability. Then we spend more time than others trying to really get into the heads of our end users, understand their proclivities and needs. If possible, doing alpha and beta demos with them, to make sure we have a sufficient understanding of how they’ll interact with what has been built. There’s simply no substitute for real world experience, especially in non-deterministic systems like agentic workflows.
When an agent recommends a quote, reschedules a route, drafts a customer response, or prioritizes a work order, there should always be a clear boundary around what it can decide on its own, what requires human approval, and how every action can be traced back and explained. In production systems, trust doesn’t come from the AI model. It comes from the architecture surrounding it.
Q: What are the most common mistakes you see when companies bolt AI onto field service software or other operational systems?
Zach Gardner: The biggest one is treating the AI as a black box. A team plugs in a model, tests it for accuracy on a handful of cases, and never builds the ability to explain why it produced a given output. That becomes a real liability the first time a wrong answer affects a customer or a payment.
The second mistake is feeding the AI fragmented data. If your scheduling, inventory, and customer records do not agree with each other, the AI will produce confident answers built on contradictions. The fine tuning you put on top of the model is only as good as your understanding of the problem space.
The third is treating prompts and models differently than application code. Most engineering teams have disciplined version control for their software, but they’ll update a prompt, swap models, or change an AI workflow with little or no governance. Six months later, no one can explain why the system behaves differently or when that behavior changed. It can be especially frustrating since by its very nature AI is non-deterministic, and it takes a different skill set to manage than highly deterministic SPAs (single page applications) that most engineers are accustomed to building.
We’ve seen these challenges whether we’re working in financial services, healthcare, manufacturing, logistics, or other complex industries. The technology changes, but the engineering principles don’t. At Keyhole, we approach AI the same way we approach every enterprise system. We define the architecture, establish governance, and build for traceability from the beginning. That’s what turns an interesting AI feature into something a business can actually depend on.
Q: Data is the backbone of any field service platform. How should service businesses get their data and systems ready before they lean on AI and agentic features?
Zach Gardner: Whether we’re implementing Retrieval-Augmented Generation (RAG), AI copilots, or autonomous agents, the same rule applies: the AI only performs as well as the operational data and integrations behind it. Before you lean on agentic features, get three things in order.
- First, data lineage: know where each piece of information comes from and whether you trust it.
- Second, your integrations: a field service platform rarely lives alone, so the connections to accounting, inventory, asset, and customer systems need to be clean and well defined, because that is the data the AI reasons over.
- Third, access scope: be explicit about what each AI component is allowed to read and change.
A lot of the value we deliver for clients sits in those connection points, where custom software development and careful integration work make the difference between AI that helps and AI that guesses. In our experience across many client environments, the readiness work is unglamorous, but it is what makes everything built on top of it dependable.
Q: How does Keyhole build governance and reliability into AI-accelerated development, and what can service businesses learn from that approach?
Zach Gardner: Our approach is architect-led and test-gated. AI helps us move faster, but it doesn’t change our engineering standards. Whether we’re using tools like Claude, Codex, or whatever comes next, every AI-generated change goes through automated testing, static analysis, code review, and senior architect oversight before it reaches production. Nothing goes into a protected branch unchecked. After all, every commit has our name on it, and customers expect the same level of quality as if we wrote every line ourselves. AI tools amplify what we already do well, and we treat it with the same level of rigor as if the code came from a peer.
One of the biggest mistakes teams make is asking AI to solve a problem before they’ve defined it themselves. I establish the constraints, get to understand the problem space, and ask open ended questions. That includes the system boundaries, data contracts, runtime requirements, business rules, and performance expectations. Once those are clear, AI becomes a very effective implementation tool instead of something that’s making architectural decisions. Granted, AI may not be the most effective tool to solve certain problems, which is absolutely acceptable. It’s a tool in the toolbelt, not a panacea.
That process naturally creates a natural audit trail with traceability. You can see what changed, why it changed, who reviewed it, and how it was validated. That’s exactly what clients, regulators, auditors, and executive leadership expect from enterprise software.
The lesson for a service business is simple: when you evaluate any AI feature, ask what the guardrails are, whether there is a human checkpoint on high-stakes decisions, and whether the system can show its work. If a vendor can’t clearly answer those questions, you should think carefully before trusting that AI with an important part of your business.
Q: For a service business leader who is excited about AI but does not have a deep engineering team, what practical advice would you give before going all in?
Zach Gardner: Start with a simple inventory. List every place AI could touch your operation and sort it by what happens if it gets something wrong. Adopt AI first where the cost of a mistake is low, like drafting routine messages or summarizing notes, and keep a human in the loop wherever money, safety, or customer trust is on the line. It’s fine to even treat it with a healthy dose of skepticism, just let it surprise you when it honestly does better than you initially expected.
Choose platforms and partners that can show you their guardrails and audit trail rather than just promising results. And bring in senior engineering judgment for the integration and customization work that off-the-shelf features will not cover, because that is usually where projects quietly succeed or fail. In our experience, the clients who get the most from AI value a partner who sets this foundation correctly over one who just moves fast.
At Keyhole, we’ve found that the organizations getting the best long-term results don’t chase every new AI model or feature release. They invest in a solid architectural foundation first. Clean integrations, governed data, thoughtful modernization, and clear engineering standards give AI something reliable to build on. Once that foundation is in place, adding new AI capabilities becomes much easier and much less risky.
About Keyhole Software
Keyhole Software is a U.S.-based custom software development consultancy specializing in enterprise modernization, cloud-native architecture, AI implementation, and custom application development. Our senior consultants help organizations design, modernize, and integrate mission-critical software systems while applying AI responsibly through architect-led delivery, governance, and rigorous engineering practices. With an average consultant experience of more than 17 years and a long history of serving enterprise clients, Keyhole helps organizations build software that is designed to evolve.
