Why Building Your Own AI Agent Stack Gets Expensive

Charles Skamser

Welcome to the latest episode of Inside PX42 where we talk about driving the intelligent entperprise with AI Agnents-- I'm Charles Skamser, CEO of PX42, here with my normal podcast crew of PX42 Consultants and AI Experts, Catherine Spencer and Edward Hamilton --- I want to start the eposide today with the question that makes executive teams a little uncomfortable: if you're a Global 500 manufacturer, bank, insurer, retailer -- pick your flavor -- and you're NOT a software company, why exactly are you volunteering to build and permanently maintain a full AI Agent stack?

Catherine Spencer

The phrase there is "permanently maintain." Not "can we build a demo by Friday." Not "can our innovation lab wire up a model API." You said FULL stack. That's an operating model decision with payroll, governance, cyber review, release discipline, and ownership attached to it.

Edward Hamilton

And I think executives sometimes answer the wrong question. They ask, "Can Claude or OpenAI help us build something ourselves?" Well, yes, of course. A strong model can help you build pieces of the machine. But that doesn't answer whether you want to RUN the machine. Architect, operator, evaluator, support desk... all of that.

Charles Skamser

Exactly. The first prototype creates this dangerous illusion of "we're almost there." And what it's really proving is that the model is impressive. It is NOT proving that you've solved operationalization. Those are two very different things.

Catherine Spencer

And enterprises have seen this film before. The old mistake was, "Our requirements are unique, therefore we should custom-build the platform." Sometimes that was true at the margin. Very often it was... well, a rather expensive form of self-flattery.

Edward Hamilton

"We are unique" has launched quite a few 20-year maintenance careers.

Charles Skamser

It really has. And the cleanest analogy is COBOL. A lot of enterprises built bespoke systems because they believed their business was special enough that off-the-shelf tools could never fit. Some of those systems worked for YEARS. That's the tricky part. They weren't stupid decisions in the moment. But decades later, those firms were carrying technical fragility, massive maintenance overhead, tiny pools of specialized talent, and a lot of architecture held together with institutional memory and prayer.

Catherine Spencer

That COBOL lesson matters because the error wasn't that the businesses had unique processes. Of course they did. The error was assuming uniqueness required custom ownership of every horizontal capability around those processes.

Edward Hamilton

Let me sharpen that. Uniqueness in underwriting, claims handling, field service, pricing, logistics -- perfectly sensible. Uniqueness in model routing, observability, workflow controls, vector infrastructure, audit trails, and release plumbing? That's a much harder case to make.

Charles Skamser

Bingo. Every enterprise has unique requirements -- but not every enterprise needs to become a platform vendor to handle them. And that, to me, is the whole frame for this conversation. This is not a matter of choosing a leading AI Agent platform like our partner UBIX or a comfortable long-time vendor like ServiceNow over one model or another. This is: do you want to consume a platform for enterprise AI operationalization, or quietly become a partial software company in the name of innovation?

Catherine Spencer

Which is why boards and CEOs should treat this as a management question first. The real issue is not whether AI Agents matter. The market's largely answered that. The issue now is how to turn them into governed enterprise outcomes without creating a fresh layer of technical debt.

Edward Hamilton

Right, so let's make the stack explicit, because the architecture slide is always suspiciously tidy. At the model layer, you typically need access to MULTIPLE frontier models -- perhaps Anthropic and OpenAI directly, perhaps through Amazon Bedrock, Google Vertex AI, or Azure AI Foundry, often some combination. That immediately creates routing, benchmarking, latency, cost, and trust-boundary questions.

Catherine Spencer

The token there is "multiple." Not one model. The briefing is very clear that the market is becoming multi-model by default because different models are better at different tasks -- coding, reasoning, lower-cost high-volume work, enterprise integration, trust-boundary deployment.

Charles Skamser

And once you're multi-model, you're in platform territory whether you admit it or not. Then comes orchestration: agents, tools, human approvals, memory, retries, escalation logic, error handling, sometimes multi-agent coordination. In a code-first world that usually means custom workflow logic and a real release discipline around those workflows.

Edward Hamilton

Then data and retrieval. This is the bit everyone hand-waves with one cheerful box labelled "RAG." In practice: document ingestion, parsing, chunking, metadata tagging, embeddings, search, ranking, vector storage, and permissions-aware retrieval. If the permissions model is wrong, your demo is not clever -- it's a security incident waiting for a calendar invite.

Catherine Spencer

And integrations are where enterprise reality really arrives. ERP, CRM, ITSM, HR, finance, operations, analytics, industry systems -- all of those need APIs, iPaaS, middleware, eventing, connectors, and ownership. The value of an agent is only as strong as the systems it can access and the workflows it can influence.

Charles Skamser

Right. Then security and governance: identity, authorization, secrets management, data masking, audit trails, policy controls, human approval design, logging, maybe private deployment patterns. None of that is optional if you're serious.

Edward Hamilton

And finally observability and operations: tracing, cost monitoring, latency visibility, workflow analytics, incident support, version control, evaluation harnesses, regression testing, dashboards for technical operators and business owners. Plus some user-delivery layer -- portal, case-management flow, dashboard, API, embedded app, chat experience, whatever the business actually uses.

Catherine Spencer

So when an executive says, "We're just building an agent," what they're often really sponsoring is a multi-vendor platform program?

Charles Skamser

That's EXACTLY it. The simple architecture slide somehow becomes six vendors, three security reviews, two integration backlogs, and one permanent queue of "quick enhancements." The prototype looks like a weekend. The operating model looks like a budget cycle.

Edward Hamilton

And somehow the word "just" survives deep into the project.

Catherine Spencer

Which is why comparing a platform subscription to a single API bill is, frankly, not a serious financial comparison. You have to compare lifecycle cost: external tech spend, internal labor, maintenance drag, and the opportunity cost of what your best people are no longer doing.

Catherine Spencer

Let me give DIY its due first. If you build internally, you get maximum control, architectural freedom, and customization. For highly engineering-centric organizations, that can be attractive. But the tradeoff is that three clocks start ticking: time to solution, time to maintain, and time to iterate.

Charles Skamser

Those three clocks are gold. Time to solution is how fast you move from a real use case to a governed capability in the hands of real users. Time to maintain is the recurring tax -- model changes, connector refreshes, framework upgrades, policy updates, incident response. Time to iterate is how quickly you can compare models, refine workflows, update guardrails, and push improvements without destabilizing production.

Edward Hamilton

And the sneaky one is technical debt impact. Because debt doesn't arrive with marching bands. It accumulates quietly: more scripts, more connectors, more evaluation reruns, more governance gaps, more shadow AI, more support dependencies.

Catherine Spencer

Let's make that concrete. Take a customer service agent. It looks efficient in a pilot. But if policies change every month -- and they often do -- then prompts, retrieval content, workflow rules, approval logic, and escalation paths all need updating. You're not maintaining a bot. You're maintaining a living service operation.

Charles Skamser

Or finance forecasting. If finance changes approval chains, source systems shift, cost centers get reorganized, or planning assumptions move, the workflow has to stay aligned. Same for a compliance assistant: access controls change, policies change, audit requirements change. Governance isn't a launch event. It's continuous.

Edward Hamilton

The phrase I've heard Charles use and rather like is "multi-vendor, multi-backlog operating burden." That's memorable because it captures what happens after the fun part. Your smartest architects and engineers end up rebuilding horizontal platform capabilities instead of working on differentiated business outcomes.

Catherine Spencer

Which is the opportunity cost executives under-measure. Every skilled product leader assigned to orchestration plumbing or connector upkeep is not spending time on revenue growth, customer experience, risk reduction, or planning quality.

Charles Skamser

That's why I keep saying the prototype looked cheap. The operating model did NOT. Early experimentation flexibility is real. DIY usually wins there. But once you count integration, governance, support, observability, security, testing, and long-term upkeep, the economics shift pretty materially.

Edward Hamilton

And there is a psychological trap here. Because the original architecture slide still looks elegant long after reality has become messy. People remain loyal to the drawing, not the operating burden.

Catherine Spencer

That's well put. And by the time release management becomes real, cyber review becomes real, support becomes real, and business adoption broadens, you've effectively created an internal AI platform team whether you intended to or not.

Charles Skamser

Which is fine -- if, being a software maintenance organization is a deliberate strategic choice. But for most Global 500 firms, it isn't. They want outcomes. Faster decisions. Better workflows. More governable AI. Not a new forever-project.

Charles Skamser

Here's where the conversation gets more strategic. Democratization of AI, like UBIX has everyone talking about, is not a buzzword to pretty up a keynote. It's a speed advantage. If advanced decision capability stays trapped inside a tiny engineering or data science team, the organization becomes slower exactly when it needs to become faster.

Catherine Spencer

And "slower" has a very specific shape. Operations leaders wait in a queue for scenario analysis. Finance leaders wait for someone to adjust a model. Service leaders wait for a workflow change. If every AI idea has to go through a tiny technical bottleneck, democratization is just a slide-deck word.

Edward Hamilton

The useful distinction is between specialist-only AI and enterprise-wide AI. In the first model, technical teams own nearly all creation, evaluation, and iteration. In the second, business leaders and domain experts can participate directly in building, refining, comparing, and using intelligent workflows -- with guardrails, obviously.

Charles Skamser

And that links directly to PX42's point of view on the Business Health layer. Most enterprises still run the business through fragmented dashboards and lagging KPIs. Infrastructure teams watch uptime. Finance watches budgets and actuals. Service teams watch case volume. Risk teams watch controls and exceptions. Useful views, sure -- but siloed.

Catherine Spencer

The memorable phrase there is "fragmented dashboards, lagging KPIs, periodic reports." Leaders don't need more rear-view mirrors. They need a unified, forward-looking layer that translates signals across infrastructure, applications, operations, finance, service, compliance, and even external inputs into something actionable.

Edward Hamilton

In PX42's framing, UBIX can serve as that Business Health layer across the stack. Not merely the place where agents are built, but the environment where enterprise signals are unified, contextualized, modeled, and translated into business-relevant intelligence.

Charles Skamser

Exactly. Descriptive, diagnostic, predictive, prescriptive. What is happening? Why is it happening? What is likely to happen next? And what should we do about it? That is a much more executive-grade story than "we launched another chatbot."

Catherine Spencer

Give me the practical examples.

Charles Skamser

Operations leaders comparing scenarios without filing a data science ticket. Finance leaders exploring forecast changes directly. Service leaders adjusting case workflows without waiting for a custom build. That's organizational speed. The people closest to the business can act with context instead of waiting for translation through three technical teams.

Edward Hamilton

And because the platform is no-code and business-user-oriented, the comparison of models becomes a repeatable business process, not an isolated technical ritual. That's important in a multi-model world, where "better" may mean lower cost, higher accuracy, faster response, better explainability, or better downstream workflow fit.

Catherine Spencer

So democratization is not about giving everyone a toy. It's about moving decision rights closer to the business while keeping governance intact.

Charles Skamser

That's the prize. More accessible intelligence, faster decisions, better course correction. Not AI as spectacle -- AI as enterprise management.

Edward Hamilton

Which brings us neatly to UBIX. The mistake is to compare UBIX one-to-one with Claude, ChatGPT, Gemini, or another model. UBIX is not "another bot." The more accurate comparison is UBIX versus the burden of assembling and maintaining model APIs, orchestration frameworks, vector databases, integration tooling, workflow engines, governance layers, observability, DevSecOps, and support operations yourself.

Charles Skamser

That's the whole game. UBIX should be evaluated as a platform to build and operationalize AI Agent solutions -- connecting data, comparing models, creating workflows, productionizing solutions, and enabling both technical and nontechnical users. It's a broader operating environment, not a single model decision.

Catherine Spencer

And it matters because of those three clocks again. Time to solution, time to maintain, time to iterate. A purpose-built platform should have a structural advantage in getting to the FIRST governed solution faster, reducing maintenance drag, and letting teams compare models and refine workflows without rebuilding the stack every quarter.

Edward Hamilton

The multi-model point is especially important. As we indicated earlier, the market is moving toward portfolios of models, not one model to rule them all. That means model selection becomes a recurring operating process rather than a one-time procurement event. UBIX's model-comparison positioning is strategically significant because it lets users choose one or many models, compare outcomes, and identify the best fit for a given task.

Charles Skamser

And UBIX can work WITH the existing estate. This is not rip-and-replace fantasy. ServiceNow, Salesforce, hyperscalers, Boomi, UiPath, ERP platforms, data platforms like Databricks and Snowflake, observability tools -- they all still matter. In many cases UBIX sits above or alongside them as a business-led decision-intelligence and AI operationalization layer.

Catherine Spencer

Use cases make that tangible. Business Health observability is the most strategic one from PX42's perspective -- unifying signals from infrastructure, applications, AI agents, ERP, CRM, finance, service, operations, and external inputs into a forward-looking view of enterprise health.

Charles Skamser

Then financial planning and forecasting. Customer service, 311, and intelligent case management. Risk, compliance, and exception management. Industry-specific decision platforms in banking, insurance, healthcare, retail, CPG, manufacturing, logistics, telecom, public sector. Wherever the problem is fragmented data plus slow decision cycles, the UBIX story gets stronger.

Edward Hamilton

So the practical line is: UBIX helps the enterprise consume a platform, not become one.

Catherine Spencer

Which, for a C-suite audience, is wonderfully plain English. You're not buying magic. You're reducing moving parts while increasing accessibility, governance, and business usability.

Charles Skamser

And PX42's role is to make that choice disciplined. We help executive teams assess current architecture, economics, governance maturity, workflow fragmentation, and use-case value -- then define what should be owned, what should be consumed, and how to move from pilot theatre to governed production.

Catherine Spencer

Let's bring back COBOL, because it's the analogy executives tend to remember. Many enterprises built custom COBOL systems because they sincerely believed packaged tools could never reflect their unique processes. Some of those systems delivered value for years. But they also left behind legacy burden, technical fragility, scarce skills, and enormous maintenance overhead.

Edward Hamilton

And the parallel to AI Agents is not exact, but it's close enough to be instructive. Just because your workflows are unique does NOT mean you should custom-build every horizontal capability around model access, workflow plumbing, observability, governance, or security. Uniqueness belongs in business logic; it needn't live in every inch of the platform substrate.

Charles Skamser

That's the C-suite question right there: do you want to differentiate in your market, or do you want to become a software maintenance organization? Because those are different strategies, and too many firms drift from the first into the second without ever saying it out loud.

Catherine Spencer

So the decision framework becomes pretty crisp. Own differentiated capabilities. Buy horizontal platform capabilities. Reduce technical debt instead of adding to it. Improve speed, governance, and business access. And be honest about where democratization should happen so the business isn't perpetually waiting on a central queue.

Edward Hamilton

But we should be careful not to oversimplify. The strongest architecture is often hybrid, yes? Hyperscalers have a role. ServiceNow has a role. Salesforce, Boomi, UiPath, custom engineering -- all useful in the right places.

Charles Skamser

Absolutely. This is not a purity argument. It's an operating-model argument. For most Global 500 organizations, the smartest path is NOT building a sprawling internal AI platform from scratch. It's using the ecosystem intelligently, keeping custom engineering focused on differentiated business outcomes, and leveraging a platform like UBIX where horizontal burden would otherwise pile up.

Catherine Spencer

And this is where PX42 matters as the advisory partner. We separate what should be owned from what should be consumed. We define where AI should be democratized, where governance must be explicit, and how to move from experimentation to production with metrics that actually matter -- time to solution, time to maintain, time to iterate, governance readiness, business value.

Edward Hamilton

I rather like that the final framing isn't "AI equals automation." It's larger than that. Democratized intelligence. Better decisions. Faster action. Earlier course correction. A more unified model of business health.

Charles Skamser

That's the prize. So I'll leave executives with the question that started this whole thing: if the goal is business value -- governed, repeatable, enterprise-grade business value -- why would a Global 500 company choose to become a platform company unless that is truly its business?

Catherine Spencer

That's a very good place to leave it.

Edward Hamilton

Slightly uncomfortable, which usually means it's the right question.

Charles Skamser

We'll take slightly uncomfortable. Thanks for listening to the show.