What Cisco has actually confirmed
In a post titled "MyAgent and the Rise of Ambient Intelligence: Cisco's Next Step in Enterprise AI", published on Cisco's corporate blog on 27 August 2026 by Thimaya Subaiya, Executive Vice President of Operations, Cisco set out what it is deploying internally. The confirmed picture is narrow, and worth separating carefully from the commentary that has grown around it.
- Scale. MyAgent is, in Cisco's words, "now rolling out to 90,000 employees".
- Foundation. It is "built on Circuit, our secure, governed, multi-model agnostic AI platform" — that is, a platform layer that already existed, not a new one built for this.
- Reach. It operates "across applications such as Outlook, Webex, Jira, and SharePoint".
- Boundaries. "MyAgent operates within Cisco's secure, governed AI environment; it only accesses approved models, approved systems, and enterprise-appropriate data pathways."
- Oversight. "Security and human oversight are baked into the design from the start."
- Interaction model. Employees delegate work by defining an objective and letting the system coordinate the steps — supervised autonomous workflows rather than turn-by-turn prompting.
- Adoption. The one usage figure Cisco does put on the record: "agentic interactions grew nearly 350% quarter over quarter". That is a growth rate for agentic activity on the platform, not a count of MyAgent users or requests, but it is Cisco's own number rather than a reported one.
That is the whole of the confirmed record. Everything else in this article that touches architecture or cost comes from secondary coverage of the rollout, is flagged as such every time it appears, and should not be attributed to Cisco.
The routing percentages circulating alongside this story are reported, not disclosed. Cisco has not published a breakdown of where MyAgent requests go, and the figures below appear in secondary coverage of the rollout rather than in the company's own announcement. They are useful as a plausible shape for a fleet-wide deployment. They are not a benchmark, they carry no stated methodology, and quoting them as Cisco's numbers in an internal business case would be a mistake.
What "a personal agent for every employee" decomposes into
The phrase invites the wrong mental model. It suggests 90,000 copies of a chat window with a large model behind it, which would be both ruinously expensive and largely useless, because a general model with no access to Jira cannot close a Jira ticket. What Cisco describes is structurally different: an employee-facing surface sitting on top of a platform that was already brokering models and already held the connectors.
That distinction is the reusable part. Circuit is described by Cisco as multi-model agnostic and governed; MyAgent is a way of addressing it. Reported in secondary coverage of the rollout, and not stated in Cisco's own announcement, Circuit already routed across Azure OpenAI, Claude, Gemini and Cisco's own Deep Network Model — which would mean MyAgent extends an existing orchestration layer rather than creating one. If that is accurate, the sequencing is the lesson: the platform came first and the fleet-wide agent came second, not the other way round.
| Layer | What it does | Status of the claim |
|---|---|---|
| Employee surface | Takes an objective in plain language and reports back; no model choice exposed to the user | Confirmed by Cisco — delegation by objective, with human oversight |
| Orchestration layer | Classifies the request, decides what should handle it, coordinates the steps | Platform confirmed by Cisco (Circuit); the routing criteria are reported, not disclosed |
| Subagent fleet | Narrow, task-specific workers doing one job each | Reported in secondary coverage as more than 800 backend subagents; not in Cisco's post |
| Model brokerage | Sends inference to whichever approved model fits the task | Multi-model agnostic platform confirmed; the named providers are reported, not disclosed |
| Permissioned connectors | Reaches Outlook, Webex, Jira, SharePoint under the caller's own entitlements | Applications named by Cisco; the entitlement mechanics are not described publicly |
More than 800 backend subagents sitting behind one employee-facing agent — again, reported in secondary coverage of the rollout and not stated in Cisco's own announcement — is the figure that reframes the whole thing. It is not one agent for 90,000 people. It is a switchboard in front of several hundred small, specific workers, most of which almost certainly do something dull and bounded: pull a ticket, draft a status note, find a document, book a room. That is what makes the surface feel general while the components stay testable.
The number that matters is not 90,000
Ninety thousand seats is a procurement fact. It tells you Cisco is confident enough to take the pilot label off and start rolling the agent out company-wide, which is genuinely notable given how many enterprise agent programmes have stalled between demo and deployment — a pattern we looked at when enterprise agentic AI started moving from pilots to production suites. But it does not tell you anything you can build with.
The interesting claim is the routing split. Reported in secondary coverage of the rollout, and not stated in Cisco's own announcement, roughly 50 to 60 per cent of requests are said to go to open-weight models, 20 to 30 per cent to plain software automation, and only a small remainder to a frontier model. If that holds, the majority of what a 90,000-seat internal agent does never reaches a frontier model at all.
| Tier | Reported share of requests | Well suited to | Poorly suited to |
|---|---|---|---|
| Open-weight models | 50–60% | Summarising, extracting, classifying, rewriting, routine drafting — bounded language work where quality is adequate and the volume is high | Long multi-step reasoning; tasks where an error propagates through later steps |
| Plain software automation | 20–30% | Deterministic work with one correct answer and an API: lookups, status changes, record moves, form submissions | Anything ambiguous, unstructured, or requiring judgement about intent |
| Frontier model | A small remainder | Genuinely hard planning, ambiguous or novel requests, tasks where being wrong is expensive | High-volume routine work, where the cost and latency are not repaid |
Set aside the exact percentages, which nobody outside Cisco can verify, and the ordering still carries information. It says that the expensive tier is the exception rather than the default, and that a fleet-wide deployment is affordable precisely because it is arranged that way. If every one of 90,000 employees' requests went to a frontier model, the economics would look entirely different — and the case for building the switchboard at all is that they do not have to.
Why the automation slice is the quietly important line
The open-weight majority will get the attention. The 20 to 30 per cent going to plain software automation — reported, not disclosed — is the line I would put in front of an engineering team.
It says that between a fifth and a third of what people ask an internal agent to do is not an AI problem. "What is the status of my expense claim." "File this leave request." "Move this ticket to review." These have one correct answer, a well-defined API and no ambiguity worth reasoning about. Putting a model in front of them adds latency, adds cost, and adds a failure mode that did not previously exist, in exchange for nothing. The right handler is a function call.
Most agent projects get this backwards. They start from the model, discover that it is unreliable at deterministic tasks, and then spend months adding tool-calling, retries and validation to recover behaviour that a direct integration would have given them on day one. The Cisco shape suggests the opposite discipline: classify first, and let a meaningful share of traffic exit before it reaches any model.
Instrument the classifier before you optimise the models. Log every request with the handler it was routed to, whether it succeeded, and what it cost — then look at what your deterministic share actually is. Teams are routinely surprised to find a quarter of their agent traffic is lookups that a model is being paid to guess at. Our guide to instrumenting agents with OpenTelemetry and cost attribution covers the trace structure that makes this legible, and where tokens actually go in multi-agent systems covers what to do once you can see it.
Routing on task nature, latency tolerance and reliability
The criteria matter more than the split. Reported in secondary coverage of the rollout, and not stated in Cisco's own announcement, the orchestration layer distributes each request based on the nature of the task, the tolerated latency, and the required level of reliability.
Those three axes are worth sitting with, because most routing implementations only use the first. A router that classifies by task type alone will send every summarisation request to the same model regardless of whether a person is waiting for it. Adding latency tolerance separates the interactive path from the background path: a summary a user is watching for needs a fast model, while the same summary generated overnight for a digest can go to whatever is cheapest and slowest. Adding a reliability requirement separates the request whose failure is a mild annoyance from the one that touches a customer record.
In practice that means the routing decision is not "which model is best" but "what is the cheapest handler that clears the bar this specific request sets". That framing is what model routing and cascades exist to formalise, and it is the same logic underneath the gateway layer most teams reach for when they want provider-agnostic routing without writing the brokerage themselves. The gateway question has become more strategically loaded this year, as we noted when Stripe's acquisition of OpenRouter put neutral routing in commercial hands — one more reason a large enterprise might prefer to own the layer, as Cisco appears to with Circuit.
Every article here is written by a Verified Builder. Want your name on the next one?
AI Tech Connect lists AI engineers, founders and researchers across India and the UK — and the people hiring browse it to find them. Adding your profile is free.
Become a Verified Builder →What to copy if you are building this at a GCC or a UK enterprise
Cisco's own numbers are not reproducible outside Cisco, and the reported ones are not verifiable at all. The shape, though, transfers reasonably well — and it transfers particularly well to two kinds of organisation that read this site.
Indian global capability centres are the closest structural analogue in the market. A GCC already runs shared platform teams serving many internal consumers, already has the internal application estate that makes connectors worth building, and already has the volume that makes a routing tier pay for itself. GCCs have also become a large share of India's AI hiring, which means the people who would build this layer are increasingly sitting inside them rather than at vendors. If you are at a Bengaluru, Hyderabad or Pune capability centre being asked for "an agent for the business", the honest first deliverable is the orchestration and permission layer, with two or three narrow subagents on top of it as proof.
UK enterprises arrive at the same architecture from a different direction. A bank in Edinburgh or an insurer in Leeds cares first about which models are permitted to see which data, and only second about capability. "Approved models, approved systems, enterprise-appropriate data pathways" — Cisco's own phrasing — is a governance sentence before it is an engineering one. The useful realisation is that the governance requirement and the cost requirement push towards the same design: an orchestration layer that can enforce which handler a request is allowed to reach is also an orchestration layer that can enforce which handler it is worth sending to.
The part that is not optional
A fleet-wide agent is a permission surface before it is a productivity tool. An agent being rolled out across Outlook, Webex, Jira and SharePoint on behalf of 90,000 people is, viewed unkindly, a very effective way to move data between systems that were previously separated by the friction of a human having to do it. Cisco's emphasis on approved systems and human oversight reads as an acknowledgement of exactly that.
This is not hypothetical caution. We reported earlier this year that 88% of enterprises had experienced an agent-related security incident in the preceding year, and the pattern in most of them is over-broad credentials rather than exotic attacks. Before widening a deployment, the credential model needs to be genuinely per-user and per-task; our guide to least-privilege credentials for AI agents is the practical version of that argument.
The open-weight tier carries its own question. Routing a majority of requests to open-weight models only reduces cost if you are running them somewhere sensible — self-hosted with decent utilisation, or through a provider whose pricing survives your volume. A poorly utilised GPU fleet can cost more per request than an API call. If self-hosting is the direction, the vLLM production playbook covers the batching and utilisation work that determines whether the sums come out.
What we still do not know
Quite a lot, and it is worth being explicit about it. Cisco has not published cost figures, savings, satisfaction data or task volumes; on adoption it has published a single growth rate — agentic interactions up nearly 350 per cent quarter on quarter — and nothing underneath it, so per-seat MyAgent usage, active-user counts and the baseline that 350 per cent grew from all remain unknown. Nothing in this article should be read as implying any of them. The rollout is reported to have begun with Cisco's new fiscal year at the end of July 2026 — again, secondary coverage rather than Cisco's own announcement — which would make this an early deployment being described at a point when outcomes cannot yet be measured. "Rolling out to 90,000 employees" is a statement about availability, not about usage.
Nor do we know how the reported routing percentages were derived: whether they are measured across all traffic or a sample, whether they are a design target or an observed distribution, and whether they have moved since the rollout began. Any of those would change what the numbers mean. The correct posture is to treat the split as a plausible shape for this class of system, and to measure your own — ideally in cost per successful task rather than cost per token, since a cheap model that fails and escalates is not cheap.
What survives all that hedging is a design claim, and it is the reason the story is worth a builder's time. An internal agent at fleet scale is an orchestration problem with a model attached, not a model problem with orchestration attached. The routing layer, the permission model and the narrow subagents are the durable assets; the model behind any given request is the part you should expect to swap. Build in that order and the reported split stops looking like a cost trick and starts looking like the natural consequence of classifying work properly before you spend money on it.