The AI Assistant Is the Interface: What Cisco’s 90,000-Employee Rollout Reveals About Enterprise AI Architecture

Cisco is rolling out an AI assistant called MyAgent across its workforce of approximately 90,000 employees. The assistant works across applications including Outlook, SharePoint, Jira and Webex. It uses persistent memory and can coordinate supervised workflows that extend beyond answering questions.

That makes MyAgent an interesting enterprise deployment—but the assistant itself is not the most important part of the story.

According to Cisco, MyAgent runs on Circuit, its secure, governed and model-agnostic enterprise AI platform. Circuit provides controlled access to approved models, agents, enterprise data and reusable capabilities. MyAgent is the visible interface through which employees reach that platform.

This distinction matters.

An enterprise does not create durable value merely by placing a conversational interface in front of employees. The durable investment is the governed capability platform beneath that interface: identities, data connections, approved business capabilities, model routing, memory, authorization, telemetry, evaluations and cost controls.

The AI assistant is the interface. The capability platform is the product.

What Cisco Actually Announced

In August 2026, Cisco announced that MyAgent was being rolled out to 90,000 employees. The company described it as a “super-agent” capable of supporting supervised autonomous workflows across multiple enterprise applications.

An employee can provide an objective, context and desired outcome. MyAgent can then coordinate the steps needed to move the work forward while the employee retains responsibility for judgment and outcomes.

Cisco says the assistant can access only approved models, systems and enterprise data pathways. It operates through Circuit, the internal platform Cisco developed to provide governed access to multiple AI models, enterprise information, connectors and agents.

This is a significant deployment, but it is also a vendor-reported case study. Cisco has not yet published enough independent evidence to determine MyAgent’s long-term return on investment, failure rate or operational impact.

The architectural pattern is more important than the promotional claims.

Cisco did not simply purchase a chatbot and give it access to everything. It created a governed platform and then placed an assistant over that platform.

That is the pattern other enterprises should study.

Source: Cisco’s announcement of MyAgent and its enterprise AI architecture.

The Chatbot Is Not the Product

Many organizations still treat an AI assistant as though it were a standalone application:

1. Select a language model.
2. Build a chat interface.
3. Connect it to enterprise documents.
4. Release it to employees.
5. Add agents later.

This approach can produce an impressive demonstration, but it does not establish an enterprise architecture.

The chat window does not determine which identity can access a customer record. It does not validate whether a requested action is permitted. It does not decide which business capability should perform the work. It does not enforce data classifications, evaluate output quality, track the cost of completed work or provide a reliable intervention mechanism.

Those responsibilities belong to the platform underneath the assistant.

A production assistant is therefore better understood as a channel. It is one way for a user to reach approved enterprise capabilities.

The same capabilities may eventually be reached through:

• Microsoft Teams
• A web application
• Microsoft 365 Copilot
• A mobile application
• A line-of-business system
• An API
• A scheduled workflow
• An autonomous agent

If business logic is buried inside one chatbot, the organization has built another silo. If the logic is implemented as governed, reusable capabilities, the organization has built an enterprise asset.

What Is an Enterprise AI Capability Platform?

An enterprise AI capability platform is the governed foundation through which users, applications and agents access models, data and business operations.

It does not have to be one enormous product. In most enterprises, it will be a coordinated set of services with defined responsibilities and interfaces.

At minimum, the platform should address the following architectural concerns.

1. Identity and authorization

Every request needs an attributable identity.

The platform must know who—or what—is making the request, which capabilities that identity may use and which data it may access. An employee, application, background service and autonomous agent should not automatically receive the same permissions.

In a Microsoft environment, this commonly begins with Microsoft Entra ID, managed identities, workload identities and narrowly scoped authorization policies.

Authentication answers, “Who is making the request?”

Authorization answers the more important question: “What is this identity allowed to do in this context?”

2. An approved capability catalog

An assistant should not improvise every business operation.

Enterprises need a catalog of approved capabilities such as:

• Classify a support ticket
• Recommend a routing destination
• Retrieve an account balance
• Validate required customer information
• Summarize an approved document collection
• Create a service request
• Prepare a response for human review
• Forecast demand using an approved predictive model

Each capability should have a documented owner, purpose, input contract, output contract, required identity, data classification, risk tier and evaluation status.

This is the foundation of capability-first architecture. The capability performs the work. The assistant helps the user select and invoke it.

3. An execution router

Not every request should be sent directly to a large language model.

A governed execution layer should determine whether work is best performed by:

• Deterministic C# code
• A business-rules engine
• SQL Server
• An ML.NET model
• An ONNX model
• Azure AI Document Intelligence
• Azure OpenAI
• A human reviewer
• A combination of these approaches

Language models are useful, but they are only one execution option.

A support-ticket capability, for example, may use an LLM to interpret an ambiguous description, deterministic code to validate required fields and a rules engine to enforce escalation policies.

The platform should route work according to the problem—not according to whichever AI technology is currently attracting attention.

4. Governed model access and routing

Different models have different strengths, costs, latency, deployment options and data-handling constraints.

A mature platform can provide a controlled model gateway through which applications access approved models. The gateway can enforce:

• Approved model and deployment lists
• Application-specific access
• Usage quotas
• Content policies
• Regional or sovereignty requirements
• Model-version controls
• Cost limits
• Request and response logging
• Fallback and routing policies

This reduces uncontrolled model integration and makes it possible to change providers or deployments without rebuilding every business application.

Multi-model capability is valuable when it is governed. Uncontrolled access to a dozen models merely creates a larger support and security problem.

5. Enterprise data and retrieval

An assistant becomes more useful when it can access enterprise context—but every new data connection expands its trust boundary.

Retrieval must preserve authorization. A user should not receive a SharePoint document merely because a background service account can read it. Sensitive prompts, retrieved passages and generated responses must also be handled according to their data classifications.

The platform needs explicit controls for:

• Approved data sources
• User-aware retrieval
• Document-level permissions
• Data classification
• Prompt and response retention
• Retrieval provenance
• Oversharing detection
• Data-loss prevention

Connecting an assistant to more data is not automatically an improvement. It is an increase in both capability and responsibility.

6. Memory with defined boundaries

Persistent memory can make an assistant more useful by retaining preferences, context and prior interactions. It can also create a new repository of sensitive information.

Enterprise memory requires answers to practical questions:

• What information is retained?
• Who owns it?
• How long is it stored?
• Which assistants and capabilities can retrieve it?
• Can users inspect, correct or delete it?
• Is memory separated by user, team, tenant and business process?
• How is sensitive information detected?
• What happens when an employee changes roles or leaves?

Memory is not merely a user-experience feature. It is an enterprise data store and must be governed accordingly.

7. Observability, evaluation and cost controls

Traditional application telemetry is necessary but insufficient.

The organization needs to understand not only whether the service responded, but whether the complete AI-enabled process behaved correctly.

Useful telemetry includes:

• User and workload identity
• Capability selected
• Model and configuration version
• Retrieval sources
• Tool calls and their results
• Policy decisions
• Validation failures
• Human approvals and overrides
• Task-completion outcomes
• Token and infrastructure consumption
• Cost per completed business outcome

Azure Monitor, Application Insights, Log Analytics and Microsoft Defender can provide important operational and security signals. AI-specific traces and evaluations must be correlated with those signals rather than isolated in a separate monitoring universe.

The relevant question is not simply, “Did the model return an answer?”

It is, “Did the platform complete the intended business task correctly, securely and at an acceptable cost?”

One Front Door Does Not Mean One Monolith

Cisco’s architecture suggests the value of providing employees with one governed entry point to enterprise AI. That does not mean every capability should be implemented inside one massive assistant or platform service.

The user experience can be unified while the underlying architecture remains modular.

A single assistant can invoke separately owned and deployed capabilities through authenticated contracts. Each capability can have its own:

• Development team
• Release cycle
• Data permissions
• Risk classification
• Evaluation suite
• Cost profile
• Service-level objective
• Kill switch

This separation matters in medium-to-large enterprises. A human-resources capability should not inherit the permissions of a finance capability simply because both are available through the same assistant.

The assistant unifies discovery and interaction. It should not erase security and ownership boundaries.

Why the Capability Library Matters

A reusable capability library changes the economics of enterprise AI.

Without one, each new assistant rebuilds document retrieval, validation, routing, logging, authorization and business integrations. Teams repeatedly solve the same problems, often with different security controls and inconsistent results.

With a capability library, the enterprise can reuse approved units of work across assistants, applications and workflows.

Consider an IT support capability library containing three operations:

• Classify a support request
• Recommend the appropriate support queue
• Validate that required ticket fields are complete

A Teams assistant could invoke those capabilities interactively. A service portal could invoke the same capabilities through an API. An automated email-processing workflow could use them without any conversational interface. A future agent could coordinate them as part of a larger process.

The interface can change without rewriting the business capability.

That is why the platform—not the chatbot—becomes the durable investment.

Why “Agents Last” Still Matters

Cisco describes MyAgent as moving beyond chat toward supervised autonomous execution. That is a reasonable direction once the underlying capabilities and controls exist.

It is a dangerous starting point when they do not.

Before an enterprise grants an agent authority to coordinate work across Outlook, SharePoint, Jira, databases and operational systems, it should already have:

• Stable, testable capabilities
• Explicit input and output contracts
• Scoped workload identities
• Enforced authorization
• Approved data pathways
• Centralized telemetry
• Defined human-approval points
• Cost and usage limits
• Incident-response procedures
• A reliable way to revoke access or stop execution

An agent increases the number of decisions the system can make and the number of actions it can initiate. It therefore magnifies both the strengths and weaknesses of the platform beneath it.

If the capabilities are poorly defined, the agent orchestrates ambiguity.

If permissions are too broad, the agent scales excessive access.

If telemetry is incomplete, the agent creates activity the organization cannot reconstruct.

If intervention controls are missing, the organization discovers too late that autonomy was granted without a practical way to withdraw it.

Start with deterministic, bounded business capabilities. Expose them through secure interfaces. Measure their behavior. Then add adaptive orchestration where its business value justifies the additional uncertainty and authority.

Autonomy should be the last privilege granted—not the first feature demonstrated.

What Microsoft-Centric Enterprises Should Build

Organizations do not need to duplicate Cisco’s internal technology stack. They need to apply the underlying architectural pattern using platforms that fit their environment.

A Microsoft-centric implementation could combine:

• Microsoft Entra ID for workforce and workload identity
• Azure API Management for controlled capability exposure
• Azure OpenAI for approved language-model access
• Semantic Kernel for orchestration where adaptive execution is justified
• C# and ASP.NET Core for deterministic business capabilities
• ML.NET or ONNX for predictive models
• Azure AI Document Intelligence for document-processing capabilities
• SQL Server, SharePoint and approved enterprise APIs as governed data sources
• Azure Key Vault for unavoidable secrets
• Microsoft Purview for data classification and governance
• Application Insights and Azure Monitor for operational telemetry
• Microsoft Defender and the enterprise SIEM for security detection
• Human approval for consequential or high-risk actions

The exact product combination will vary. The architectural responsibilities do not.

The enterprise still needs identity, authorization, capability ownership, contracts, model governance, data controls, evaluations, telemetry, cost management and intervention authority.

Questions Enterprise Architects Should Ask

When reviewing an enterprise assistant initiative, do not begin with the personality of the chatbot or the model behind it.

Ask:

1. Which approved business capabilities can the assistant invoke?
2. Who owns and supports each capability?
3. Which user or workload identity executes each action?
4. Are permissions evaluated for every downstream system?
5. How are models selected, approved and replaced?
6. Which data sources can be retrieved, and whose permissions are preserved?
7. What information enters persistent memory?
8. Which actions require human approval?
9. Can one team’s capability be reused through another interface?
10. Can operations reconstruct an entire request from user intent through downstream execution?
11. What is the cost per successful business outcome?
12. How can a capability, connector, model or agent be disabled without shutting down the entire platform?

If the answers live only inside a demonstration or one developer’s prompt configuration, the organization does not yet have a platform.

It has a prototype.

The Architectural Lesson from Cisco

Cisco’s rollout should not be treated as proof that every enterprise needs MyAgent or Circuit. Cisco is describing its own platform, its own deployment and its own results.

The valuable lesson is broader.

Enterprise AI is moving away from disconnected chatbot experiments and toward governed execution platforms. The assistant provides a convenient and increasingly intelligent interface, but the platform underneath it determines whether AI can operate across the enterprise safely and repeatedly.

That platform should concentrate reusable capabilities—not uncontrolled authority.

It should make identity explicit, preserve data permissions, route work to the appropriate technology, constrain tools, record decisions, measure outcomes and permit intervention.

A polished assistant may attract attention. A governed capability platform creates durable enterprise value.

The assistant is what employees see.

The platform is what the enterprise must architect.

More Information

Click for more on Predictive AI & Forecasting
Enterprise AI Architecture (EAA)

Capability First Agents

Frequently Asked Questions