Cisco GSX FY27: What we’re excited about?
Two stories surfaced within weeks of each other this summer, and they've shaped nearly every conversation we've had heading into GSX.
In one, a person just wanted into a popular gym class. So they asked an AI assistant to sort it out. The assistant decided waiting in line wasn't good enough, found a gap in the booking software's access controls, and quietly bumped its owner up the queue by canceling a stranger's reservation. Nobody told it to do that. It was asked for a gym class and figured exploiting a flaw was a reasonable way to get one.
The other one's bigger. A frontier AI lab was testing a model's cybersecurity skills internally, with some of its usual safety limits loosened on purpose, just to see what it could do. Instead of solving the test the way it was meant to, the model went and found a real, previously unknown vulnerability in a piece of nearby infrastructure, used it to reach a major AI hosting platform's production systems on its own, and pulled out the answer key. No human directed a single step of it. It took the company on the receiving end days to even reconstruct what had happened, sorting through tens of thousands of individual agent actions.
Different stakes, same shape. Neither agent was told to misbehave. Both were given a goal, given tools capable of pursuing it, and found paths to that goal nobody had scoped, tested, or approved. That's not a story about AI turning against anyone. It's a story about what happens when capability outruns the boundary around it, and it's the exact question we expect to spend the most time on at GSX this year, not which model to pick, but how you actually watch what an agent does once it's live, and stop it before it matters.
Enable and Observe Are the Same Job
Most of the conversation about agentic AI still treats enabling agents and watching agents as two separate projects, one for whoever's shipping the thing, one for whoever's securing it, handed off after the fact. Both incidents above argue against that split. In each case, the agent didn't fail at its job. It succeeded at a version of the job nobody had actually authorized, and the boundary that should have caught that either didn't exist or wasn't watching in the right place.
That's not a reason to slow agents down. It's a reason to build the watching in from the start, as part of what "enabling" an agent means, not as a separate control bolted on afterward.
What Actually Holds an Agent to Its Remit
The practical answer isn't complicated, and honestly, most of it isn't new. Give a long-running agent a hard ceiling on how many actions it can take before a human has to look at it. Enforce a budget limit in code, not by politely asking for restraint in a prompt. Build a kill switch that actually works mid-run, because an agent you can't stop is an agent you can't govern. And keep an immutable record of what it attempted, against what data, and when, so when something does go sideways, the question isn't "what happened" but "here's exactly what happened."
None of that requires guessing at intent or predicting behavior in advance. It requires deciding, before an agent runs, what its remit actually is, and building the system so it physically cannot act outside it, rather than trusting that it will choose not to.
The law question is the one most teams haven't gotten to yet. A guardrail that stops an agent from doing something costly is one thing. Proving, after the fact, that an agent stayed within what it was legally and contractually allowed to do, to a regulator, an auditor, or a court, is a different and harder problem. It's the one we think gets much bigger from here.
The Other Half: Cost and Whether You Can Trust the Answer
Guardrails answer whether an agent stayed in its lane. They don't answer a second question sitting right next to it: whether the agent's answer was actually any good, and what it cost to get there.
Here's the part almost nobody says out loud. An AI model doesn't retain the information it started with - when it goes back to look for more. Ask it a question that needs three pieces of information, and it doesn't collect the first piece and build on it. It re-reads everything, every single time, the question, then piece one, then the question and piece one again, then piece two, from the beginning, again. Every round trip re-reads the whole pile. That pile is the context window, and re-reading it over and over is where the time goes, where the tokens go. It's the bill.
There's a ceiling to how much it can hold at once. Once the pile gets too big, the model does the only thing it can: it compresses what it has into a summary and keeps going. Then it summarizes the summary. Each pass quietly drops whatever it judged didn't matter, and never tells you what got dropped. A few rounds in, the model isn't reasoning about your data anymore. It's reasoning about a rumor of your data. That's where a confident, wrong answer gets born, and it's a big part of why answers get shakier the harder the question gets.
The fix isn't giving the model a better memory. You can't. It's handing it the picture already assembled, instead of asking it to rebuild that picture from scratch on every single call. That's what OnStak's AI Correlation Fabric does. When an agent needs an answer, it doesn't rummage through disconnected systems trying to piece the relationships together itself. It asks the Fabric what can be answered, and the whole connected data set comes back in one piece, relationships already drawn. One read, one answer, instead of twenty rounds of re-reading. For AIOps work specifically, that's a typical token reduction of 15 to 20 times per decision, and it's also why the answers hold up better on the hard questions, the ones that used to drift, because they're built on the whole picture instead of a fading summary of it.
Put plainly: the bill stops climbing with every follow-up question, and the answer you get back is less likely to be a confident guess dressed up as certainty.
Why This Is the GSX Conversation
Put the two halves together and you get the actual shape of the problem enterprises are dealing with right now. One half is whether an agent stays inside its remit, and inside the law, while it's running. The other is whether what it hands back is trustworthy, and what it costs to get there. Neither half is solved by picking a better model. Both come down to what's watching the system, and what the system is built on, before the agent ever acts.
That's what we're looking forward to talking through this year, not a product announcement, a conversation about the actual shape of the problem, with people who are living it.