Your AI Agents Need a Boss: Managing the Digital Workforce

Charles Skamser

Welcome back to Inside PX42. I'm Charles Skamser, cofounder and CEO of PX42 Consulting, and it's really good to be back. It's October 20, 2026, and I've spent the past several weeks on the road meeting technology executives, partners, and industry and stock market analysts, while my team here has been heads down on new offerings. With me today are two people from PX42 that I trust more than anyone on this subject. Edward Hamilton is an AI researcher with a background in observability, multi-agent systems, and SaaS development. Catherine Spencer is a digital transformation and AI strategy consultant with more than fifteen years of experience working with enterprise clients on AI integration and reinforcement learning. Catherine will run the questions today, and I suspect Edward will not be able to resist jumping in. Our Topic is Your AI Agents Need a Boss: Managing the Digital Workforce Before It Manages You.

Catherine Spencer

Charles, you've just spent weeks in rooms with executives. What was different about those conversations compared with a year ago?

Charles Skamser

The question changed. For the past few years, the conversation was about generative AI, large language models, copilots, and then agents. Can we build one? Can we get a proof of concept running? Now the question is whether an organization can manage hundreds or thousands of agents across its business, coordinate their work, govern their decisions, and keep checking whether they're actually improving enterprise performance. Building an agent has become the easy part. Managing a fleet of them is the hard part.

Catherine Spencer

Hundreds or thousands is a bold phrase. Is that where enterprises are today, or where you think they're heading?

Charles Skamser

I'd call it a trajectory, and I wouldn't attach a number to any particular company. But look at the shape of a large enterprise. Salesforce manages customer relationships. ServiceNow supports technology operations and workflows. SAP or Oracle handles resource planning. Microsoft provides productivity and collaboration, and there are several cloud and data platforms underneath. Now picture every one of those environments introducing its own agents, sales agents, service agents, security agents, finance agents, supply chain agents. At the same time, individual departments are building their own using technology from OpenAI, Anthropic, Google, Microsoft, AWS, and others. Some arrive embedded in applications you already own. And they won't only answer questions. They'll initiate transactions, update records, communicate with customers, and talk to each other.

Edward Hamilton

That last part is where it gets interesting, because agents talking to agents is where you get emergent behavior nobody designed. Charles, you have a favourite illustration of this.

Charles Skamser

I do. Imagine a sales agent trying to increase revenue, a finance agent trying to protect operating margin, and an inventory agent trying to reduce working capital. Each objective makes perfect sense on its own. Now the sales agent offers a significant discount to close an opportunity. The inventory agent, minimizing working capital, reallocates that product elsewhere. The finance agent, protecting margin, tightens the customer's credit conditions. Every one of them is operating correctly inside its own objective. And collectively they've made the enterprise less effective. The deal is discounted, the stock is gone, and the customer can't get terms.

Edward Hamilton

What strikes me, from the multi agent research side, is that there's no bug to find. In ordinary software, when something goes wrong, you trace it to a faulty component. Here every component passes its own test. The failure lives in the interaction between objectives, and that's a much harder thing to monitor, because nobody owns it.

Charles Skamser

Exactly, and that's the sentence I keep coming back to. Optimizing individual activities is not the same as optimizing the enterprise. And the more autonomous these systems become, the more that distinction matters.

Catherine Spencer

You've been describing agents as a digital workforce. That phrase makes some people uncomfortable. Are you suggesting we treat them like employees?

Charles Skamser

No, and I want to be clear about that. They aren't human employees. They don't have human judgment, and they don't carry accountability the way a person does. But from a management perspective they create similar operational requirements. Each agent needs a defined role, objectives, authority, access permissions, performance expectations, and someone accountable for it. It has to operate within enterprise policy. Its actions have to be observable and auditable. And when circumstances change, its authority may need to change too. So the comparison is about the management discipline, not about the nature of the agent.

Catherine Spencer

From the advisory side, that raises an awkward organizational question. Whose job is it? I can think of five departments that would each claim a piece and none that would want the whole thing.

Charles Skamser

That's the point where the traditional boundaries between enterprise architecture, cybersecurity, IT service management, business process management, and corporate governance begin to converge. An enterprise needs to know which agents exist, what they're permitted to do, what information they can access, which systems they can modify, and under what conditions they must escalate to a human. No single one of those functions answers all of that today. That's why I keep saying this is an operating model question, and not only a technology deployment question.

Catherine Spencer

Let's get concrete. You talk about something called the AI agent permission matrix. What is it, in plain terms?

Charles Skamser

Think about the authority structure inside a bank. A teller can process withdrawals up to twenty five hundred dollars. A branch manager can approve up to fifty thousand. A credit committee can authorize ten million dollars and above, and even then it's subject to audit and regulatory requirements. Nobody finds that strange. Authority scales with role and with consequence. AI agents need the same kind of explicit authority structure. The permission matrix defines, for each agent, what it can do based on its role, the action being requested, the sensitivity of the data, the operational context, and the potential blast radius if the action goes wrong.

Catherine Spencer

Give me a worked example, because 'blast radius' can sound abstract.

Charles Skamser

Take an agent investigating a problem on a payment processing platform. It should be able to read transaction telemetry, trace latency, look through error queues, analyze historical performance, and formulate recommendations. That's a lot of useful capability. What it should not have, without explicit approval, is write access to modify fraud thresholds, reroute live transactions, or alter financial ledgers. Those are the actions where a mistake lands on customers and on regulators. The agent can be brilliant at diagnosis and still have no authority to make the change.

Edward Hamilton

Which is really a separation of two things people casually blur. Recommending and executing.

Charles Skamser

That's the core tenet. An agent's ability to recommend an action should never be confused with its authority to execute that action. A very capable agent will often be right about what should be done. That doesn't entitle it to do it.

Edward Hamilton

Now here's where I'd press, because I suspect many teams think they've handled this. They write into the system prompt, you must never modify the fraud rules, and they consider the matter closed. Why isn't that enough?

Charles Skamser

Because a prompt is an instruction, not an enforcement mechanism. The permissions have to be enforced by the surrounding systems, at the infrastructure, API, and platform layer, deterministically. If the agent's credentials don't allow a write to the fraud configuration, it doesn't matter what the agent has been persuaded of. If the guardrail lives only inside the context window, then it's only as strong as the model's behavior on its worst day.

Edward Hamilton

And the model's worst day can be engineered by someone else. Prompt injection is exactly that, an attacker placing text in the data an agent reads so that the agent's instructions change. If your only barrier is natural language, an attacker is playing on your home ground. A deterministic permission check doesn't read the clever paragraph at all. It checks the credential and says no.

Catherine Spencer

I want to pick up one word you used earlier, Charles. Dynamic. You said permissions may need to change when circumstances change. How dynamic should a matrix be?

Charles Skamser

Dynamic enough that an organization can revoke an agent's permissions immediately, or return a workflow to manual control, when necessary. Circumstances shift. A system is under attack, a regulation changes, an agent starts behaving oddly after a model update, a data source degrades. The matrix can't be a document someone wrote at deployment and filed away. It has to be a living control that's enforced in the systems, tied to identity, and tied to observability, so you can see what the agent actually did against what it was allowed to do.

Catherine Spencer

So the matrix is not only about what an agent may do. It's also the thing an auditor reads afterwards.

Charles Skamser

Right. Every action should be logged, attributable, and open to intervention. If something goes wrong, the question 'who or what authorized this' needs a crisp answer. With a human it's a name and an approval. With an agent it should be an identity, a permission, and a record. That's what I mean by accountability for a digital workforce, even though the accountability itself ultimately rests with humans.

Catherine Spencer

The vendors have clearly noticed all this. Where is the market right now?

Charles Skamser

The major providers clearly recognize the challenge, and I expect the competition to intensify. ServiceNow has been advancing its AI Control Tower, and Databricks has been expanding Agent Bricks. Microsoft, OpenAI, Salesforce, Google, AWS, and others are all building more sophisticated enterprise agent capabilities. These are important developments. Edward, you've been reading the details.

Edward Hamilton

I have. Working from a recap of the Knowledge 2026 presentation, rather than from ServiceNow's own documentation, so treat the specifics accordingly. The AI Control Tower is described as working across five dimensions: discover any AI, secure any AI action, govern any AI activity, observe agent performance, and measure AI's value. It's anchored in the ServiceNow CMDB, so agents, models, and MCP servers get inventoried as assets alongside services and people. The recap attributes the engines to three acquisitions. Armis for discovery, Veza for identity and access governance, and Traceloop for runtime observability. The Veza piece is described as mapping more than 300 billion permissions.

Catherine Spencer

And there was a demonstration, I understand, of a kill switch.

Edward Hamilton

Yes. As the recap describes it, a simulated prompt injection attack against a pricing agent was detected, traced through Veza's access graph, and neutralized by a one button action that revoked the compromised agent's permissions. It then generated an incident ticket automatically. It's a tidy demonstration of the capabilities Charles was just describing: revocation, traceability, an audit trail. The same recap says general availability for the full platform was expected in August 2026, and it also cites a statistic that 66 percent of organizations use multi agent AI while only 44 percent trust their agents. I'd treat that as the presenter's figure, not as settled research, but the gap it points to rings true.

Charles Skamser

And on the Databricks side, the Agent Bricks story is about the production gap. The material I've seen reports that more than 100,000 agents have been built on the platform, and that Databricks' own engineers describe the core agent loop as roughly one percent of the real work. The other ninety nine percent is evaluation, governance, cost control, monitoring, and deployment. Agent Bricks sits on Unity Catalog, so the permissions and audit controls that already govern tables and files extend to what an agent can read, write, and expose. It automates evaluation with an Agent as a Judge approach, and it works with multiple frameworks and model providers.

Catherine Spencer

That one percent and ninety nine percent split is striking. It says the agent is the demo and everything else is the product.

Charles Skamser

It does. And I think that's healthy. But they also expose a fundamental architectural problem. Most large enterprises aren't going to operate inside one vendor's ecosystem. A Global 500 company runs SAP or Oracle for ERP, Salesforce for customers, ServiceNow for IT, Databricks or Snowflake for data, and several clouds. So who manages the interactions among all of those environments? How do you establish consistent governance when one agent operates in ServiceNow, another in Salesforce, and a third in a cloud native application?

Edward Hamilton

Let me push back fairly, though. ServiceNow describes the Control Tower as vendor agnostic, and the recap lists thirteen new connectors reaching AWS, Azure, Google Cloud, SAP, Oracle, Workday, and AI platforms like Anthropic, OpenAI, and Copilot Studio. That's not a walled garden. Isn't it a credible answer to your question?

Charles Skamser

It's a serious step, and I'd say so openly. Visibility across vendors is valuable. My view, and I'll flag it as my interpretation, is that the architectural question is who the referee is. When a control layer belongs to one of the players, many enterprises will want governance that they own, one that spans every platform on equal terms. I believe the answer increasingly involves federated control architectures, interoperable governance mechanisms, enterprise identity management, policy enforcement, observability, and coordinated workflow orchestration. In our AIAgentOS reference architecture we treat those as capabilities that can be delivered through multiple platforms, and that includes the ones the vendors are building. We're not competing with them. We're asking how they fit together.

Edward Hamilton

There's another temptation I'd like you to address. The obvious fix for a crowd of agents is to put a supervisory agent on top. A boss agent, quite literally, to match your title.

Charles Skamser

And I don't think the industry should assume that solves it. Supervisory agents can make mistakes too. A supervisor built on a language model is just as vulnerable to hallucination, to goal drift, and to context poisoning as the agents beneath it. So the boss can't be only another model. The control architecture has to combine adaptive intelligence with deterministic rules, enforceable permissions, open standards for telemetry like OpenTelemetry, auditable human workflows, and clear human accountability. The model can advise. The rules and the people hold the line.

Catherine Spencer

Charles, you've lived in monitoring and observability for a long time. How do you place this moment on that timeline?

Charles Skamser

A lot of my career has been in enterprise monitoring, application performance management, and observability. We went from watching servers and networks, to application performance management, to modern observability with metrics, logs, traces, and business transactions. Dynatrace, Datadog, New Relic, Splunk, Elastic, Grafana, and others have contributed enormously. But traditional monitoring tells you something has already gone wrong. Modern observability helps you spot emerging problems and understand probable cause. The next step is combining that with predictive analytics and decision optimization, so you can anticipate a condition and evaluate preventive actions. Listeners who heard our earlier episode on business observability will recognize the thread.

Catherine Spencer

Walk us through what that looks like for something like a payments platform.

Charles Skamser

Picture a large financial institution. The observability environment starts seeing subtle shifts in transaction latency, database utilization, application queue depths, and downstream processing times. None of them has crossed a critical threshold. The applications are available, transactions are flowing, and the traditional dashboards are green. But a predictive model comparing history with current telemetry says there's a growing probability of significant degradation. In our illustrative scenario, say an eighty two percent probability of a sharp rise in payment failures during an upcoming volume peak. That figure is an example to make the point, not a measured result.

Catherine Spencer

And the prediction alone doesn't tell you what to do.

Charles Skamser

Right, that's where prescriptive analytics comes in. The system can evaluate courses of action. Scale up cluster capacity? Reallocate traffic? Adjust the batch execution window? Is there a downstream dependency that needs intervention? And what would each option cost, against what it protects in revenue, compliance, and customer experience? That connects predictive observability, operational decision support, and business outcomes.

Catherine Spencer

You've mentioned reinforcement learning in that chain. I know it's catching attention in boardrooms, so let's be careful. What is it, and what is it not?

Charles Skamser

Reinforcement learning is a machine learning approach where a system learns decision policies through feedback tied to its actions and outcomes. A conventional predictive model estimates what might happen. An RL policy can be trained to choose among actions in pursuit of defined objectives, for example balancing infrastructure capacity, latency, throughput, cost, and availability. But I want to emphasize something. It is not a universal solution, and it must never be turned loose on a live production environment to learn by trial and error. Exploration in production risks serious business, financial, or regulatory damage.

Edward Hamilton

This is the place where the research and the boardroom talk part company. In the lab, exploration is the whole point. The agent tries things, some of them badly wrong, and that's how it learns. You can't hand an agent a live payment system and say, go on, experiment. So the policy has to be developed and stress tested against historical telemetry, controlled testbeds, digital twins, and simulation. And then there's reward hacking. If your reward function says minimize cost while keeping latency under a target, a clever policy may find a loophole that satisfies the letter of the metric while quietly harming something nobody measured. You have to probe for that deliberately, and check behavior under unusual conditions, not only typical ones.

Charles Skamser

And frankly, in many situations established optimization techniques, even classical linear optimization, or deterministic business rules, are the better and safer choice. The objective isn't to use reinforcement learning everywhere. It's to select the most effective analytical technology for the problem. Where RL fits is recurring, measurable decision problems where policies can be rigorously evaluated before they touch production.

Catherine Spencer

Which brings us to autonomy. How should an enterprise actually let a system act on those recommendations?

Charles Skamser

Progressive autonomy. I don't think most enterprises should begin by giving AI systems unrestricted authority over production. We think about a ladder from L0 to L4. L0 is manual, fully human executed. L1 is observe and advise: the agent detects an anomaly, synthesizes telemetry across platforms, and alerts a human. L2 is propose with blast radius: the agent proposes a specific fix, shows the evidence, separates validated causal relationships from statistical correlation, quantifies the risk, and gives a rollback path for human sign off. L3 is act reversibly: the agent executes tightly bounded, preapproved actions with a demonstrated record of reliability and instant reversibility, like resizing a cache or rebuilding affected tables. L4 is fully autonomous, but only across tightly scoped, low risk boundaries.

Edward Hamilton

One thing worth stressing is that the ladder is not a single global setting. It's per domain, even per class of action. An organization might run one workflow at L3 while a neighbouring one, perhaps anything touching customer credit terms, stays at L2 indefinitely. The ladder is granted workflow by workflow.

Charles Skamser

Yes, and that's why I say autonomy is not a destination that every workflow must reach. It is an operating privilege that must be justified by evidence, risk, and business value. Modifying a payment processing policy, changing customer credit terms, or authorizing a significant financial transaction might require explicit human approval forever. And at every rung there are absolute requirements: a real time kill switch, immutable audit logging, instant permission revocation, and automatic rollback. If you can't take the privilege back immediately, you shouldn't have granted it.

Catherine Spencer

So far we've talked about technical health. Charles, you want to go further, to the health of the business itself.

Charles Skamser

Predicting a technical failure is valuable. But apply the same principles to the whole business. A company has gradually deteriorating customer retention. A hospital is approaching a staffing or capacity constraint. A manufacturer faces supplier delays and rising transportation costs. A dealership sees appointment conversion falling even as lead volume rises. Those problems develop slowly, with warning signals scattered across systems, and no single department sees them. That's why I'm so interested in enterprise business health. You examine the relationships among business processes, financial indicators, customer behavior, operations, infrastructure, and external events. Predictive analytics identifies developing risks, optimization evaluates responses, and governed agents coordinate approved actions. The purpose isn't to replace executive judgment. It's to give executives a more timely and actionable picture.

Catherine Spencer

And who builds those models? In my experience the bottleneck is usually the queue for data engineering.

Charles Skamser

That's where our partnership with UBIX comes in, which we introduced earlier. UBIX brings data integration, advanced analytics, and ways of making sophisticated techniques accessible to business professionals. A supply chain analyst should be able to investigate supplier risk and build predictive scenarios without waiting months for a development project. An insurance analyst should be able to explore claims patterns, retention, and underwriting performance. That's the democratization of data and AI. It doesn't remove the need for data engineering, security, governance, or statistical expertise. It lets specialists concentrate on making the underlying systems reliable and governed. And PX42 contributes the enterprise architecture, agent integration, governance, and change management.

Edward Hamilton

I'd add a caution to the democratization point. Letting domain experts build models quickly is wonderful, but it makes the permission matrix and the autonomy ladder more important, not less. More people building means more agents to govern.

Charles Skamser

Agreed, and that's why those pieces travel together. Related to that, I should say something about legacy automation. Enterprises have invested in RPA from UiPath, Automation Anywhere, SS&C Blue Prism, and Microsoft. I don't think they should discard it. RPA is well suited to structured, rules based execution. Agents help with interpretation, contextual reasoning, and exception handling. An agent identifies an exception and recommends a response, an established automation workflow executes defined steps after authorization, ServiceNow or another workflow system manages approvals, and the business health environment measures the result.

Catherine Spencer

Let's talk about PX42 itself. Some listeners will hear 'business health platform' and assume you're becoming a software vendor.

Charles Skamser

We're not. PX42 is not planning to become another general purpose enterprise software company. We're an AI consulting, enterprise architecture, and systems integration business. We help organizations decide where AI creates meaningful value, assess readiness, choose technologies, design architectures, and deploy production grade solutions, and we try to maximize the investments they've already made. That starts with the PX42 AIAgent Readiness Index, which looks at business priorities, data readiness, application architecture, automation maturity, governance, security, operating processes, and financial considerations. It also asks what they already own. Significant ServiceNow capabilities? A UiPath deployment? A mature observability environment? The output is a prioritized roadmap tying business objectives to use cases, costs, risks, and measurable outcomes. And AIAgentOS is a reference architecture, not a proprietary operating system. It covers orchestration, context, identity, permissions, lifecycle, observability, and guardrails, delivered across multiple platforms.

Catherine Spencer

Yet you've announced a spin off strategy. How does that square with staying a consulting firm?

Charles Skamser

The idea is to keep PX42 focused while applying the architectural principles of EnterpriseBusinessHealth360 to specialized markets through separate, industry focused businesses. They'd share intellectual property, integration methods, and technology partnerships, but each would focus on the processes, financial drivers, and decision requirements of its own market, and where commercially justified, develop its own leadership, customers, and revenue model. PX42 would continue to provide architecture, integration, governance, and consulting. But each potential spin off has to stand on its own business case. A reusable architecture does not automatically establish a viable market. There has to be real demand, compelling economics, differentiated capability, and an effective go to market model.

Catherine Spencer

The first is DriveYield AI. Why dealerships?

Charles Skamser

Because a dealership is a surprisingly complex set of functions: internet lead management, the business development center, sales, inventory, finance and insurance, service, parts, marketing. They often run on separate applications. Consider a dealership with plenty of leads and declining conversion. A conventional dashboard shows lead counts, response times, appointments, and sales. An intelligent business health environment can examine the relationships. It might find leads routed to unavailable representatives, scheduling practices hurting conversion, or inventory characteristics affecting engagement. Predictive analytics can estimate which leads are at risk. An agent can advise the business development center manager or sales leadership, and selected low risk follow up could become automated over time. This is not another dealership chatbot, and it's an integration play with the dealer management systems and CRM they already have.

Edward Hamilton

And the second, SupplyChainHealth360, seems to suit the mathematics rather well.

Charles Skamser

It does. Supply chains involve demand, inventory, supplier reliability, transportation capacity, commodity pricing, production schedules, geopolitical conditions, and weather. Say supplier lead times are creeping up while transportation costs and demand variability also begin to rise. None of those triggers an alert alone. Together, predictive analytics can show an increasing probability of shortages or production delays, and the system can evaluate alternative suppliers, routes, allocations, and schedules. Certain decisions could be automated within financial and operational limits. Changing a major supplier or making a substantial financial commitment would still require a human. Beyond those two we're evaluating BankingHealth360, insurance, healthcare, which carries stringent privacy, clinical safety, and regulatory requirements, and adjacent markets like RV and marine retail. Not every initiative will become a company, and not every workflow should become autonomous.

Catherine Spencer

If a chief executive listening wanted to take one thing from today and act on it on Monday, what would it be?

Charles Skamser

Ask a different set of questions, and don't leave them with the CIO. Do we know which agents are operating in our enterprise and what they're authorized to touch? Are we measuring the business outcomes they produce, revenue, margin, risk reduction? Can we connect application and infrastructure telemetry to the performance of critical business processes? Are we using predictive analytics to find operational risks before they become incidents? Do we have a disciplined way to evaluate recommended actions, track their blast radius, and learn from outcomes? And is our governance capable of granting autonomy selectively, with deterministic guardrails and kill switches, without giving up accountability? These belong with the CEO, CFO, COO, chief risk officer, and business unit leaders, because this is an operating model issue.

Edward Hamilton

I'd underline one of your closing thoughts, Charles. The idea that more is not better.

Charles Skamser

An enterprise with a thousand poorly coordinated agents may be less effective than an organization with fifty carefully governed, outcome aligned intelligent workflows. The objective isn't to maximize the number of agents. It's to maximize business performance while keeping control of cost, risk, and complexity. Looking toward 2027, I expect governance to move from model controls toward agent identity, delegated authority, and lifecycle management, and regulated industries to move more slowly, with good reason. If you'd like to talk, you can find us at PX42.ai or connect with me on LinkedIn. Catherine, Edward, thank you both. And to everyone listening, remember: the future isn't about how many AI agents your organization deploys. It's about how intelligently your enterprise operates. Thanks for listening.