Is Building AI Agents Enough? — Local vs. Global Optimization with an AI Operations Registry
Introduction
Hello, I’m Mia Sato, AI Researcher at GDX.
AI agents are starting to become part of everyday business operations.
One agent may organize customer inquiries. Another may prepare product information, draft translations, check inventory, or generate reports. When each agent has a clear job, it becomes much easier to automate work that people used to repeat manually.
The challenge starts when a company no longer has one or two agents, but dozens of them.
Who created this agent?
Is it still approved for use?
What data can it access?
What actions can it take on its own?
If something goes wrong, who can stop it?
Those questions came to mind when I read Salesforce’s September 2026 announcement of its new AI Control Plane.
Salesforce introduces an AI Control Plane
Salesforce announced its Enterprise AI Harness in September 2026, describing it as an architecture for running enterprise AI with shared context, security, governance, and business controls.
The part that caught my attention most was the AI Control Plane.
The idea is to give companies one place to understand and manage the AI agents and AI capabilities operating across the organization, including third-party AI rather than only Salesforce products.
Salesforce says the control layer is intended to cover areas such as agent discovery and registration, identity and policy, lifecycle management, performance, behavior and outcomes, and cost.
Not all of these new capabilities are available immediately. Salesforce says new functionality and a unified management experience will roll out over time.
What stood out to me is that this is not mainly about building another AI agent. It is about managing what happens after agents begin to multiply.
One agent is easy to remember. A fleet is not.
Imagine an EC team creates a product listing agent, a customer support reply agent, a translation agent, an advertising report agent, and an inventory agent.
Individually, each one may be useful.
Right after launch, the person who created the agent probably remembers that it reads from the product master, or that a product owner needs to approve the output before publishing.
Six months later, that may no longer be true.
The owner may have moved teams. The product master may have changed. Return policies or campaign rules may have been updated.
One of the benefits of an AI agent is that it can keep working without someone giving detailed instructions every time. But that same autonomy makes outdated configurations easier to overlook.
A customer support agent may continue producing perfectly natural replies while relying on a return policy that expired months ago.
So the question is not only whether an agent makes mistakes. It is whether a configuration that was correct when the agent launched is still correct today.
Do AI agents need an operations registry?
Companies already keep records for people and systems.
We track which department an employee belongs to and which systems they can access. Business applications often have documented owners, administrators, and purposes as well.
If AI agents are beginning to perform part of the daily work, perhaps they need a similar minimum record.
A simple AI operations registry could look like this:
| Item | Example |
|---|---|
| Agent name | Product Listing Agent |
| Purpose | Draft product descriptions |
| Owner | EC Operations Team |
| Data accessed | Product master data |
| Actions allowed | Create drafts |
| Actions requiring human approval | Publishing and price changes |
| Last review | September 1, 2026 |
| Status | Production |
The point is not simply to create an inventory of agents.
Who is accountable for this agent?
What can it access?
What is it allowed to do?
Is the current configuration still appropriate?
Once agents are visible in one place, another issue also becomes easier to spot: duplication.
A product listing agent and a translation agent might both be retrieving and transforming the same product data. That may be reasonable, or it may indicate that the same capability has been built twice.
Access is only part of the permission model
When we talk about permissions for AI agents, data access is usually the first thing that comes to mind.
Can the agent see customer information? Can it read the product master?
Those questions matter, but they are not enough.
A product listing agent might only read product data. Or it might draft descriptions, edit information in the EC system, change prices, or publish products directly.
The risk changes significantly depending on what the agent is allowed to execute.
| Action | Approval |
|---|---|
| Read product information | AI can handle independently |
| Draft product descriptions | AI can handle independently |
| Change prices | Human approval required |
| Publish products | Human approval required |
Defining permissions at the action level makes it much clearer where AI autonomy ends and human accountability begins.
It also makes duplicated work easier to identify across the company.
Imagine the EC operations team, customer support team, and marketing team each build their own agent to retrieve and transform the same product master data.
Each department may have improved its own workflow, while the company as a whole has built essentially the same capability three times.
Managing AI agents therefore means looking beyond what each individual agent can do. It also means asking whether common capabilities can be shared across agents and teams.
AI agents need onboarding, role changes, and retirement too
Another aspect of Salesforce’s AI Control Plane that stood out to me is lifecycle management.
An AI agent should not be treated as something that is created once and then runs forever.
Draft → Test → Production → Review → Retired
An agent is designed, tested, put into production, reviewed, and eventually retired.
If a customer support agent relies on a return policy, the agent should be reviewed when that policy changes.
If responsibility moves to another department, the owner should change. If the agent is no longer used, it should be retired rather than left running indefinitely.
Just as companies disable employee accounts when people leave, they may also need a regular way to ask whether an AI agent is still authorized to “work.”
This becomes especially important once AI is treated not as a standalone tool, but as part of the operating process.
You can start with a spreadsheet
Of course, not every company needs an enterprise-scale control plane immediately.
If the number of agents is still small, an Excel sheet or Notion database may be enough to start.
Agent name / Purpose / Owner / Data accessed / Actions allowed / Actions requiring human approval / Last review / Status
Add an agent when it moves into production. Update the record when business rules, source data, permissions, or ownership change.
Then review the registry regularly and ask:
- Do we have multiple agents doing almost the same job?
- Have different teams implemented the same data retrieval or transformation separately?
- Are unused agents still running?
If two agents have almost the same purpose, perhaps they should be consolidated. If the same capability is useful to several departments, perhaps it should become a shared service. If an agent is rarely used but expensive to maintain, retirement may be the better option.
There is also an organizational point here.
If every department makes these decisions independently, the company can quickly end up back in local optimization.
In addition to individual agent owners, there may need to be a cross-company role, such as an AI enablement team or IT function, that can look across agents and workflows and decide where consolidation, standardization, or retirement makes sense.
In that sense, an AI operations registry is more than an inventory for governance. It can become a practical tool for finding duplication and inefficiency across the business.
From AI adoption to company-wide optimization
Salesforce’s AI Control Plane made me think that the purpose of agent management is not simply to count agents or document permissions.
As individual teams adopt AI, each team may become more efficient while the company as a whole accumulates overlapping agents and duplicated processes.
That is a classic form of local optimization.
As AI agents become more deeply embedded in operations, companies may need to ask a bigger question than which agent should stay.
If we were designing this workflow from scratch today, should the process itself still work this way?
I do not think AI agent management is only about controlling AI.
It can also become an opportunity to use AI as a reason to redesign the wider business process.
From AI adoption to AI operations.
From local optimization to company-wide optimization.
References
- Official: Salesforce Introduces the Trusted Enterprise AI Harness / Salesforce / Salesforce
- Reference: Salesforce moves to rein in fragmented enterprise AI with six-product integration / TechTarget Japan / TechTarget Japan
- Official: Salesforce launches new MuleSoft Agent Fabric capabilities and MuleSoft Omni Gateway in Japan / Salesforce / Salesforce
※ Part of this article was created with the support of AI, reviewed by the author, and then edited. The content reflects the author’s personal views and does not represent the official views or statements of GDX Inc.
