Agent operating model
Turn a single AI pilot into a business process that runs under control.
That takes clear responsibilities: who builds agents and tools, who approves them and who is accountable for day-to-day operations. Once several agents work in your systems, an agent operating model sets these rules.
An agent operating model is the governance and organizational model for AI agents in a company. It defines who develops agents and agent tools, who approves system access, policies and releases, who decides on exceptions in daily business, and who owns operations, monitoring and outcomes. Nexus maps these roles in the platform.
Such a model doesn’t have to come first. It takes shape once the first process runs in production and the second builds on its tools, policies and lessons. By the time several business units want agents of their own, though, it becomes a prerequisite.
Who builds, who approves, who runs.
A typical split of roles. Team names differ from company to company; the tasks hardly do.
| Role | Accountable for | In Nexus |
|---|---|---|
| Process owner (business) | Business rules, thresholds and target KPIs of the process | Guarded Autonomy policies, outcome dashboards |
| Builder team or AI CoE | Building, testing and evolving agents and agent tools | Builder, evaluation, versions in DEV and TEST |
| Owners of business systems such as SAP or Salesforce | Which system functions are released as tools, and with which permissions | Tool release, a technical user per agent |
| CISO and IT security | Security requirements, identities, data access, audit | Central policies, audit trail, relay configuration |
| IT operations | Releases to PROD, monitoring, incidents | Separate environments, versioned deployments, monitoring |
| Day-to-day decision-makers | Approving exceptions such as discounts or payment terms | Approvals in Teams or Outlook, with full context |
In smaller organizations, one team holds several roles. What matters is that every task has a named owner.
An operating model isn’t created on paper.
It grows with every process that goes live.
How the operating model grows with every process.
Six stages, each building on the one before. You decide the pace based on results.
One process
One process pack, such as order processing, runs in production with your real systems and measurable KPIs.
More processes
Quotes & pricing, service resolution or delivery exceptions are added in the same systems.
Reuse tools
A tool such as erp.customer.check, released once, is used by several agents. Each new process needs less integration work.
Centralize policies
Approval routes, thresholds and permissions are defined once and apply to every agent.
Bring in external agents
Joule, Agentforce, Copilot and your own agents call tools through Nexus and run under the same rules.
Operating model
Clear ownership, separate environments, monitoring and outcomes for every agent in the company.
What grows with every process.
The second process goes live faster than the first, because much of what it needs already exists.
Agent tools
Released tools from your systems, such as SAP, Salesforce or Microsoft 365, are available to every further agent.
Policies and approval routes
Guarded Autonomy applies consistently: execute, approve or block, by the same rules.
Monitoring and outcomes
Straight-through rate, exception rate and cycle time are measured the same way for every process.
Environments
DEV, TEST and PROD with versioned agents, tools and policies. Every release stays traceable.
Security
A dedicated identity per agent, an audit trail for every action, and systems that stay behind the firewall via the relay service.
Know-how in your team
With continuous enablement, your teams build their own agents and tools, supported by voluro.
Typical starting points.
Hardly any company starts from zero. There are usually AI pilots, a few tools and high expectations, but no process running in production yet. That’s where we start: with one process that measurably changes something.
Sound familiar?
- “We have several AI pilots, but none of them is in production.”
- “Every business unit is experimenting on its own.”
- “IT security won’t approve write access to SAP.”
- “Agentforce, Joule or Copilot don’t cover our end-to-end process.”
Frequently asked questions about the agent operating model
Who should own the operating model?
Usually a central team from IT and the business, often set up as an AI CoE. It sets standards for tools, policies and releases. The business rules of each process stay with its process owner.
Do we need an operating model before we start?
No. We recommend going live with one process. Nexus brings governance, monitoring and separate environments from day one, and the operating model grows on top of that.
We already use Agentforce, Joule or Copilot. Does that fit?
Yes. Nexus integrates these agents and lets them call tools under the same policies. They keep their strengths within their own platform.
What role does our AI team or CoE play?
A central one. It sets standards and prioritizes the next processes. Nexus provides the shared platform, and voluro helps build your own builder teams.
How long does it take to reach stage 6?
That depends on your processes and priorities. Each stage delivers measurable value on its own, and you don’t have to go through all of them.
Read on
Process packs
Where most companies start: order processing, quotes & pricing, service resolution, delivery exceptions.
Scaling
How we continue together after the first process.
From pilot to production
Why AI pilots get stuck and what makes the difference.
Start with one process.
30 minutes · free · with a senior architect. You get a verbal initial assessment and concrete next steps.