Scaling Intelligence Out: Cisco's Vision for the Internet of Cognition, with Vijoy Pandey

Hello, and welcome back to the Cognitive Revolution. Today, my guest is Vijoy Pandey, SVP and GM of Outshift by Cisco. For more than 40 years, from helping to define early low-level protocols that are still in use today to building out the infrastructure that powers modern high-speed networks, Cisco has been critical to how we manage the flow of digital information. Today, Vijoy and the team at Outshift are bringing Cisco’s distributed-systems DNA to the fundamentally new challenges presented by frontier agentic AI systems.

The AI-powered preparation that Vijoy and I each did for this episode demonstrates why this is such an important opportunity. I used Tasklet to conduct deep research on Vijoy’s work and draft a starter set of questions. At the same time, his team ran a deep-research process on me and the podcast and identified a number of suggested discussion topics based on themes that we’ve previously explored. Both agents did a really good job on their respective assignments, but they knew nothing about one another and had no opportunity to collaborate.

Their output was sent from human to human by email, and it was up to me to figure out how to synthesize their work. “What’s missing,” Vijoy says, “is the internet of cognition”: higher-order protocols that AI agents need to share context, understand one another’s intent, build reputation and establish trust, and ultimately solve problems in shared spaces.

The upside of filling this gap, I’m convinced, will be world-changing and perhaps even world-saving. It was, of course, the emergence of language and the evolution of culture that allowed humans to sustain cooperation over long distances and time horizons and ultimately build the global civilization that we enjoy today. The distributed nature of this system makes it extremely difficult and rare for any individual to accumulate a systemically dangerous amount of power.

In contrast, the current AI paradigm emphasizes scaling things up with more and more resources, creating ever more powerful frontier models, each of which is meant to do everything on its own. This kind of concentration of capabilities into just a few systems, and the concentration of power that it could easily bring about, has always struck me as dangerous. I think it’s very exciting to see a major company developing an alternative paradigm that’s meant to scale intelligence out horizontally in a way that is fundamentally distributed and designed to support permissionless participation from the start. I think and hope it could give rise to a more buffered, ecological, and stable network-based architecture for AI.

Importantly, Vijoy also argues that this paradigm gives enterprises what they really want and need: a way to grant agents only the minimum permissions truly needed to perform their roles; a clean separation of concerns; visibility and auditability of their systems; and controlled interfaces through which to interact with the outside world. Of course, this conversation goes well beyond the theory and deep into the progress that Cisco and its partners are making in practice.

Internally at Cisco, they’ve built a system that they call the Community AI Platform Engineer, or CAPE, which is composed of 20 distinct agents that collectively manage complex cloud-computing environments. This system has reduced the load on site reliability engineers and improved response times for end users by fully automating some 40% of tasks. Meanwhile, for the public, they’ve taken the lead on the AGNTCY project, which is laying an open-source foundation for how AI agents representing different interests can connect, communicate, and meaningfully collaborate.

At one point in this conversation, Vijoy fires up a demo that shows how 4 agents, each representing different organizations and specializing in distinct skills, can collaborate to serve a patient in a healthcare setting spanning diagnostics, insurance, pharmacy, and scheduling. He narrates the demo pretty effectively, but I think it would be worth flipping over to YouTube to see that bit in action, if you can. With that, I hope you enjoy this window into some of the most sophisticated systems thinking about the giga-agent AI future that I have found anywhere, with Vijoy Pandey of Outshift by Cisco.

Vijoy Pandey, SVP and GM of Outshift by Cisco, welcome to the Cognitive Revolution.

I’m so excited to be here, Nathan.

Me, too. Lots to learn. I’ve been studying up on your work, and there are many facets to it. I would love to start, if you would indulge me for a second, with just a super-high-level view.

I think everybody in America knows the Cisco brand, but probably even a lot of people who are very into the AI world at this point and know a ton about the intricacies of post-training and building all these agent workloads—if you pressed them and said, “What does Cisco do?”—what I’ve come to in terms of a 3-word answer is: moving information around the world.

That obviously has many different ways to unpack it, but I’d love to get your introduction to the company and the fundamental role that it plays in our modern technological life.

You’re right. It’s moving information around the world. It’s connecting people to machines and to objects. It’s about secure connectivity. It’s about observable connectivity. It’s about collaboration.

If you think about Cisco’s 4 core pillars in its businesses, it’s networking, security, observability, and collaboration. Those are the 4 business units, so to speak, that we go after.

But if I were to take a step back—and because this is an ML/AI audience—the way I think about Cisco in that context is that we are a distributed-systems company. We enable scale-out. We enable horizontal scale.

If you think about servers and making them bigger and bigger, that’s 1 way of scaling. That’s scaling up. Cisco is a company that allows you to take many of these entities, connect them through a network, and enable a cluster of compute. You’re enabling distributed computing and scale-out technologies. You end up doing both—scaling up and scaling out—to get the compute that you need for all of the awesome workloads that we’re trying to run today.

I’m just reflecting on how much we need a robust foundational layer for decentralization. The last week of news in AI has been frontier companies battling against governments. I think about what the original dream of the internet was: this decentralized thing that people could plug into on their own terms and contribute to. I worry that we are losing that a little bit.

I think part of the great hope that I see in some of the work that you’ve done is to help enable that kind of distributed, participatory future. So, let’s take 1 more beat on the fundamentals, because 1 of the big things that you are proposing is an extension to the conceptual framework for networking that people have developed over the entire history of information technology.

Again, I suspect most people don’t know the 7-layer network model. Could you walk us through the 101 framework that guides people in the networking space?

There is, as you said, this OSI 7-layer model for networking, and it’s a wonderful formal theoretical model. People like to stick to the model, but more often than not, people find ways around it. Like with anything that is formal, you make things work; you don’t necessarily stick to what’s out there as a formal stack.

If you were to think about that formal stack, the 7 layers are physical, data link, network, transport, session, presentation, and application. I’m going to walk through all of them, and I’ll give you a sense of where things are pretty awesome right now.

What do you really need to care about? The buzzwords that you’ve probably heard in the literature include Ethernet, which most people are familiar with. That’s a technology that connects computers in a local-area environment, or local-area network. Ethernet operates at the physical and link layers, primarily at the link layer.

TCP/IP is probably the most famous protocol out there, on which the entire internet runs. That covers the transport and network layers—layers 4 and 3.

As you move higher up the stack, the other protocols that people are most familiar with are HTTP and HTTPS. These are layer 7 protocols, or application-layer protocols.

Typically, if you ask somebody, “What are you familiar with in the networking stack?” you would think about HTTP and its secure equivalent, HTTPS; TCP/IP, on which the entire internet is built; and Ethernet, which connects local computers together in a network. Those are the things that people are familiar with.

The rest of the layers are there for formalism, I guess, but they’re not really as important. If you’re a networking geek, you might find that statement a little bit off-putting, but this is the reality of things.

Shoot us straight, always, please. A big question I also had about the world that I enjoy today is how much of the underlying protocols, and the way that today’s major networks are managed, is run on explicit code with rules that we fully understand—rules that somebody sat down and designed and implemented—versus how much machine learning has already penetrated its way down the stack to manage the way that data actually flows.

When issues are happening, how are they detected and remediated, and so on and so forth?

I know that there are people with many PhDs in this area, but I realize I don't know what that boundary looks like between what has been designed and what has been learned through the emergent process. So let's take a look at that from the pre-LLM era a little bit, and even straight-up machine learning and those pipelines that have existed for a while now.

The actual hardware and the actual sending of data across the network are pretty deterministic in nature today. If you think about routing and the routing tables that exist within these large switches and routers, that's a very deterministic process. You don't want to take chances on figuring out where things are sent. You want pretty good determinism between the connection between you and me, Nathan, for example. I don't want that to be left to chance.

But there is a control plane that sits above all of this, and this is where the algorithms sit. This is where—I don't know if the listeners are familiar with BGP and some of these routing protocols that run the internet—there's a control-plane piece of software that figures out who can talk to whom. And that's not just in the regular day-to-day traffic sense of the word, but also when issues and outages happen.

What happens when you need to route around outages? If an undersea cable has been cut, what happens when you have to route around that, for example? These are control-plane entities. They also deal with things like policies between organizations. If Google and Amazon want to connect to each other as 2 separate entities, there are strict policies on how they exchange information, how they exchange routing tables, and how they connect to each other, as an example.

Policies, security, actual routing, control plane, and application software—those are all pieces of software, and we've been using ML for quite some time in those pieces of software. Simple examples: anomaly detection is a common one, where we've used ML pipelines for a long, long time. Traffic predictions, because you can foresee events like the Super Bowl and figure out what needs to be done for an event like that—we've used ML there. We've used ML to predict failures.

There are certain subsea cables and certain choke points in the internet where you need to route around them and be careful around those failure points. We've looked at ML for those things. Also, around the business, we've used ML quite a bit within a company like Cisco, to do things like sentiment analysis around customers. There's a lot of use for ML, even some amazing uses in—like I said, one of our pillars is collaboration, which is Webex, and Webex uses ML pipelines to do things like noise reduction.

We've been using ML in a company like Cisco for a long, long time. But I think, like everybody else, with the advent of generative AI and the practicality of some of these LLMs coming into the enterprise, a lot of that is now changing.

Yeah. Maybe you can tell us more about how it's changing. I was interested to read about Project Jarvis, which is obviously one higher-order, additional layer that's been placed on top. I'm also curious: are the LLMs reaching down into the stack, or is it purely a layering on?

You know, this gets back to the 2 new layers that you're proposing to the network model as well. But I was challenged to think, in the highest-level terms, what is it that we've accomplished recently with language models? It's not just that they've learned to do narrow tasks, right? It's this sort of general-purpose semantic and now even agentic capability that's been layered on top, and so you're building at that layer too. Tell us about Jarvis and other places where language models are starting to change how Cisco operates.

Jarvis was actually one of the first use cases that we deployed, at least within our work at Cisco, and then we've also taken that piece of code and worked with other BUs within the company, like Splunk and Webex and some of these other teams.

The whole notion behind Jarvis was, if you're an SRE, you know this: there are so many tasks that you do day in and day out to support your developer base and your customer base that are repetitive in nature and can be highly automated through generative AI and agents. The way to think about this is to think about everything that's happening in the software development environment through coding agents, and take that paradigm and apply it to site reliability engineering.

That's what Jarvis does. It takes the SRE pipeline and brings in the same agentification—the same number of agents working together to solve a problem—that you would use in a coding environment for developing code. The paradigms are quite similar, and the whole notion behind SREs is to leverage software development to solve for infrastructure and operational needs. There's a lot of commonality in there, but there are also a lot of specific, special cases that we need to handle.

Jarvis was built, and it's called CAIPE, by the way. It's Community AI Platform Engineer. CAIPE has a nice logo with a superhero with a cape on their back. CAIPE is actually a multi-agent system, so it's a MAS that allows for the automation and agentification of the entire SRE pipeline.

What we've done is have 5+ user interfaces that feed into CAIPE. It's doing 100+ tool calls across cloud providers, across cloud-native environments, on-premises, and across various aspects of that cloud-native environment—everything from observability to orchestration to networking to security. It's actually tackling more than 10 workflows today, and it's roughly 20 agents that are working together.

That MAS consists of around 20 agents working together, and the outcomes have been pretty amazing. We've reduced the load on the team by 30%. 40% of the tasks that the team handles have actually been agentified, so we don't even worry about them. They're completely taken care of end to end.

The response time, because we've done all of this, has gone from hours to instantaneous. So it's efficiency as well as morale in the team, because you're not dealing with issues on a day-to-day basis. The developer community that's using CAIPE is also pretty productive now. So it's efficiency for the SRE team, and it's also efficiency for the developer community.

We started here, like I said, and rolled it out to other parts of Cisco. But we've also made this open source through the Cloud Native Operational Excellence, or CNOE, community. It's got members from Adobe—I mean, these are fascinating names—AWS, of course, Cisco, Nike, and a whole bunch of enterprise companies. They've been playing around with this, they've been growing it, and there's a decent community gathering around this CAIPE project.

Can you give us a little bit better sense of what the frontier looks like today? This is a little hard, obviously, because it's such a moment-in-time thing. From GPT-5.3 to GPT-5.4, it's going to move, I'm sure. But what would you say are the upper-end things that a multi-agent system can handle today, and what are the sorts of things that it can't handle, where we need people to bring their expertise?

And how far do you think this kind of thing goes? Is there a vision for extreme—I mean, we're talking in software, right? Obviously, productivity is changing pretty fast. Do we need 10 times as much software? Do we need 100 times as much software? What's the future of this market?

I lack intuition for this. If this were to become 100 times more efficient, do we do 100 times more network management, or does the role change, or do some roles go away? What does even just next year, if you can think that far ahead, look like as models get better and get plugged into the frameworks that you've built?

The one thing that interests me quite a bit is, first and foremost, the definition of what we're trying to achieve as an industry. Whether you're looking at it from the AGI or ASI perspective, there is a definition of what we're all going after. The definition that interests me the most is having a team of agents collaborate to solve for something that is net new, completely novel, and has not been in the training data at all—in any of those models' or agents' training data.

So it's completely net new, and doing it without any human intervention 100% of the time. I'm mixing aspects of the economic and the technical definition, but we've seen variations of this come across from many researchers in this field. That's the one that I align behind. That's the north star that we all want to go after.

I would say we are—I can make a prediction, and there are others who've been making predictions here. The timeline shifts forward and comes back. It's been a back-and-forth on what, how, and when we can achieve ASI. But to me, the big thing that matters is that right now, the entire industry has been chasing 1 vector toward this goal of ASI, and that is vertical scaling.

We're building bigger and bigger models. We're building better and better reasoners. We're throwing data and compute resources at the problem, with more parameters. That's 1 axis that will continue to happen. But we haven't really tapped into the second axis, which is the horizontal axis.

This is where a company like Cisco has a play. This is where I get interested, because I'm a distributed-systems person. What I mean by that horizontal axis is: Can we scale intelligence horizontally? Can we enable collective intelligence, where the collective is always greater than the individual?

Right now, we have not tapped into that piece yet. The big reason for that is we've managed to scale these individual brains, quote unquote. They become smarter and smarter, but we haven't figured out how they can think together—how we can bring them together so that they can have shared intent, shared cognition, and then innovate collectively to solve for this new set of problems without human intervention, which is the definition of ASI.

To me, if you want to pull in those timelines, we have to tap into that horizontal axis of scaling intelligence. That's something that we would like to bring to the table and push toward, because it's completely missing today.

Yeah, I think that's really fascinating. I was just reading J Accutr's latest blog post earlier today. She's now at Meter, and I'm sure everybody's familiar, of course, at this point, with the Meter exponential graph. But she was saying it might be time to rethink the metric. Until now, it has been: How long would it take a human to do this task?

She was pointing out that, in the range we've been measuring—from 0 to whatever, where Claude Opus 4.6 was at around 16 hours, or whatever the best estimate was—it's not too different in that range to have 1 person do the work versus trying to divvy it up and have multiple people do the work, because there are some fixed coordination costs.

Certainly, if you think down to the limit and take a 1-minute task, you can't really parallelize that 8 ways more often than not. But now, as you get past 16 hours and get to maybe a couple weeks' worth of work, it's something where humans can parallelize and take it down in a better way. She was emphasizing that maybe we need to measure AIs by how long it would take a well-organized team of humans to do this thing.

But you're bringing the other side of that to the equation as well. What's kind of assumed here is that it's still 1 AI. With the latest models, certainly Claude is doing this, and Gemini 2.5 made a big point about how it's spawning sub-agents and kind of swarming itself.

I think you have a much grander vision for that, which goes beyond 1 AI self-delegating. That still feels brittle and subject to correlated failures, and potentially—who knows what other kind of resonant weirdnesses might emerge. I hear you saying that, for humans, it's diversity across culture, across time, and across all these additional, richer dimensions of collaboration, rather than just narrowly cloning yourself and delegating a subtask.

Maybe there's the formalism that you're going to add 2 layers to the network stack, and you can touch on those. But then I really want to get into your vision for what AI culture looks like. What does AI cultural evolution look like? What is this world that we're going to step into? And, of course, how are we going to make it work as well? But take me to the vision part of AI collaboration.

Before we get to the vision, let's take a look at human history and human evolution, and how intelligence evolved in humans as well. The 1 thing that we do really, really well in AI is that the human is the bar, and we try to see where we are with artificial intelligence compared to a single human or teams of humans. That's always been the yardstick, though we might be surpassing that yardstick pretty soon.

If you think about human intelligence evolution, humans became smarter and smarter. They became very conversant with tool usage. They became very conversant with symbolic communication for a long, long time. This was happening for hundreds of thousands of years. You could use an axe and an agricultural tool. You could actually paint pictures, raise flags, and communicate in those ways.

But the big paradigm shift—the step function—happened when language was invented. That happened around 70,000 years ago. There's a ton of literature on this, where you can see that the invention of language was actually a step-function change in intelligence evolution within humans and human societies.

Suddenly, you could collaborate on tasks. You could align on intent. Instead of all of us trying to run and capture that hill, it was, “Let's figure out a strategy to go ahead and capture that hill.”

That delegation—that taking a larger task and breaking it down into smaller tasks, giving them to various members of the team based on their expertise, aligning on that intent, coordinating between the members of the team, and then actually executing on that task and solving for a net-new problem, which is, “We've never seen that hill before. Let's figure out how to capture that hill”—that's what unlocked the next revolution in human intelligence.

What we are seeing is that this exact trajectory is actually playing out in silicon. As we're seeing this build-out of smarter and smarter brains and bigger and bigger models, agents are getting better and better. Yes, you're getting these sub-agents in Claude, OpenAI's GPT, and Gemini, but it's still not getting out of that. It's like subprocesses within my brain. It's actually not getting out of that.

We're not looking at teams of agents that can come together and collaborate. Based on that paradigm, what we need to enable is, to your point, looking at longer-duration tasks—tasks that humans do for more than 16 hours, over a few days. Look at the specialization that happens within human teams, and then figure out how agents can actually mimic those behaviors.

What we'll find is that specialized agents—subject-matter experts—can come together, share intent, coordinate, negotiate, then work on shared knowledge and shared context, almost like institutional knowledge, and then innovate on a new problem statement. That's the way to go.

That's what we're calling the Internet of Cognition, because it's going to be distributed across a bunch of agents who, by definition, will come from different vendors. They're all subject-matter experts; they will not come from the same vendor. They will all need to come together, collaborate, and solve for this net-new problem space.

That Internet of Cognition is the vision, and that is the horizontal scaling that we all need to pursue to enable the second axis—to unlock the second axis of scale for artificial intelligence.

So, can we make this really practical for a moment? Let’s look at the interaction that we had leading up to this conversation. I use an AI agent to help me prepare for every episode of the podcast. Specifically, I use Taskade, which basically channels Claude and gives it a robust, cloud-based framework to work in.

It does a pretty good job of going out and researching everything about you, finding all these publications, and bringing me back a good source list. Then it cross-references that against my past work—all the previous outlines of questions that I’ve put together—and comes up with a decent draft for me. I definitely still have to spend time on that, for the record, and usually end up writing my own because I want to be able to be present in the conversation. Just having had an AI do it doesn’t really give me the ability to do that.

But that’s what happened on my side. Usually, the guests don’t really do anything like that. But somebody on your team—I don’t know if it was you, but somebody on your team—did a similar thing and took all your work and cross-referenced it against my recent record of episodes.

There was another thing that got sent over that was like, “Okay, here are all the themes that we know you’re interested in and how Vijoy’s work relates to those.” What didn’t happen at all was that the AIs had any back-and-forth or coordination. It was just two ships passing in the night.

Now I have these 2 side-by-side documents. Both are useful, but there’s no meeting of the AI minds. How do you think that—that’s a pretty basic case, and we can build up from there—but how would our agents in the future come together? What should we expect in terms of additional value from that kind of interaction?

This is an excellent use case, and it’s a pretty straightforward use case. Like you said, it’s simple, so it’ll be easy to understand what we’re thinking about in terms of shared intent, shared context, and collective innovation.

Your agent, Nathan, has got a local optimization function running. There’s a goal there that says, “Let’s produce the best podcast ever in your series, in the entirety of what you’ve done with The Cognitive Revolution.” Then let’s figure out what that entails.

The history or context that your agent has is all of your guests and what they’ve spoken about, and what might be net-new and interesting for the audience based on what that agent is seeing, which is your history. There’s a similar agent, like you said, on our end, which is looking at all the speaking engagements I’ve done or people from Outshift have done, and what’s interesting to folks who have listened to Outshift people or me speak about.

So there’s a context there which is somewhat different. It’s almost like a Venn diagram. One is very Outshift-centric and focused on what works, and one is very Cognitive Revolution-centric and focused on what works. But both of those have a similar goal, which is: can we get together and create, between the two of us, a podcast that is probably going to be the most interesting podcast out there?

As you come together and make that happen, both you and my team—Rebecca and I, on my side—have been working through some concessions. We’ve been working through, “Yeah, that might be a little too marketing-oriented. Let’s get a little real and grounded, and more technology-oriented.” We’ve been looking at how to come to a common goal so that this conversation resonates with the audience that you have.

But that work is being done by humans today. It’s not hands-off. It’s not automated. There’s no agentification at all. What we’re trying to get to is the agentification of this entire pipeline: let’s throw the Cognitive Revolution agent and the Outshift agent together, and let them converge on a common intent—the best episode possible—with some concessions on both sides so that we narrow down the questions and topics that we can talk about.

That’s something that can happen hands-off between the 2 agents. Once you’re done with that and this podcast is out there and you’re getting listenership, now you have common context that both of them can work upon and leverage for the next guest. Maybe I’m there the next time around, and you can leverage that context. You don’t have to redo these things.

Or maybe I’m going on a different podcast, or maybe somebody else from Outshift is coming to your podcast. You have common context that you can leverage over time, that is not lost, and you don’t have to restart that process.

This is something really simple, but it also tells you that even in such a simple example, the humans are doing the intent alignment. The humans are doing the coordination and negotiation. The humans are actually building our context using Google Docs or SharePoint or whatever it is. It’s human glue that is enabling collective intelligence.

How do we codify that? How do we make that automated? What is the infrastructure that we need to build so that this human glue becomes software glue? That’s what we’re trying to do through the Internet of Cognition.

Let’s get into the weeds on that, because I think it is really interesting to imagine. I, of course, have a ton of questions about how it should work very practically. Should we exchange agent ideas and then I give my agent your agent ID? Should they be out there potentially discovering each other? Is there some sort of way to have your menu, or roster, of agents presented in a way that’s attached to your identity?

I have a lot of questions about identity just on its own with agents. I’m very interested in, first of all, how these things discover each other, and how they know, when they do communicate, that they’re talking to who they think they’re talking to.

Then, previewing your additional layers for the network stack—Layer 8 is semantic, and Layer 9 is cognitive—I’ve got big questions there, too. These questions are also very operative in human affairs all the time, right? Are we talking about the same thing? Are we thinking about it the same way? Are we miscommunicating?

Human life is full of miscommunications, minor and major. But it seems like right now the AIs are going to drift off into weird spaces if we just let them sort it out fully. We’re obviously going to need some guardrails and some way to bring them back to true north, at least for now.

So, give me the double-click on the details of how you see all this working.

To walk through all of that that you just asked, there are many, many layers involved here. To walk through each one of those layers, let me show an example. This is a pretty abstract picture, so for everybody who’s listening in, I’m going to describe it as much as I can. But if you can go back and listen and look at the diagram that I’m showing, it actually makes even more sense.

Let me share this picture. To walk through that entire set of questions that you asked, Nathan, there’s a little complexity here. There are many, many layers that need to get involved.

Let’s start with an example here. This is an example that we built. It’s a multi-agent system that we built for a healthcare provider, and the goal here is pretty straightforward. The goal here is to take patient calls.

So, people are calling this healthcare provider, and they need to get routed to the appropriate subject-matter expert—the provider themselves, like a doctor, let's say—based on the patient's history, the availability of the doctor, and the insurance profile of both the doctor and what exists in the hospital.

What you see here are actually 4 agents. For everybody listening in, I'm just going to describe it. There is the scheduling agent on the bottom right, which is the one that is actually interacting with the patient. This one is like a chatbot. You're talking to the chatbot, and it's also doing scheduling at the back end. This is the one that's actually going to go and schedule you sometime with the doctor.

Then there are 3 other agents. There is an insurance agent, which is coming in from the payer's perspective. It's not from the hospital; it's a completely third-party entity. There's a diagnostics agent. This is also a third-party agent, not belonging to the hospital. Then there's a pharmacy agent, which is also a third-party agent, not belonging to the hospital.

The only piece that belongs to the hospital is the scheduling and conversational chatbot piece. The other 3 agents are actually third-party agents. The task is, again, pretty straightforward: get me to the right provider for the symptoms I have, based on my insurance history, my pharmacy record, and so on.

If you think about these other 3 agents—insurance, diagnostics, and pharmacy—first and foremost, all of these agents are independent. They could not talk to each other. So, first of all, they have to be discovered and connected, given the right identity and access, and brought into and stitched together into a multi-agent system so that we can even start doing things like this. That's step 1.

To do that, we launched this whole notion of the Internet of Agents almost a year ago, and we launched an open-source project called AGNTCY. That's spelled A-G-N-T-C-Y. If you're watching this on YouTube, you can go to agntcy.org. That's the landing page for the open-source collective. It's part of the Linux Foundation as well.

Coming back to this example, what AGNTCY allows you to do is first discover these agents. All 4 of them can get discovered. It then allows you to provide appropriate identity and access management attributes to each one of them. We can spend some time on that, but that's a complicated topic.

Once you do that, you can actually start communicating with each other. Traffic starts flowing between all of these agents. They get connected, and they're communicating with each other. There are protocols like MCP and A2A that allow you to have agents talk to tools through MCP, or allow agents to talk to each other through A2A. So, communication happens.

Finally, there's an observability pillar, which says, "Great, these things are working. Are they actually delivering what they're supposed to deliver?" There's a lot of observability from the agentic perspective, from the multi-agent system perspective, and a little bit of evaluation from that perspective as well. We have not solved the evaluation stack completely; we've just touched it a little bit.

That's what AGNTCY does. It is the basic plumbing required to even bring these 4 agents together in an enterprise so that they can start doing what we're trying to do here. This is what we deployed. This is what's working today.

What's not happening today is that all of these 4 agents are actually isolated agents. They can talk to each other, and they can get connected, but the payload is opaque. The payload is just a blob; it's a binary object. You don't know what's contained within those payloads. All you're doing is enabling these things to talk to each other and enabling access to tools, but the coordination, the alignment, the shared memory, the shared context—everything that you see on the right-hand side, which is grayed out—is not happening.

That is still happening through a human in the loop. The human is actually the coordinator. Just like in the previous example we talked about, the human is playing the role of enabling intent.

If you think about what's happening here, you have time-to-route KPIs that the scheduling agent has. You have the diagnostics agent, which is being measured on output or outcome confidence. You have the insurance agent, which is being measured on ROI. Every agent has local optimizations to solve for.

Somebody has to step in and say, "You know what? Each one of these agents has to give a little to get a little." You need to relax your time-to-route KPIs. The insurance agents need to relax their ROI KPIs so that we can get to the proper global outcome for the patient.

There's intent, there's coordination, and there's knowledge and context that need to be shared between all of these agents, because all of these agents have a mix of patient information as well as broad information across all patients.

A couple of questions I'll float to help prompt you: Today, it seems like discoverability is—I had this vision of the human as being like the old switchboard routers. We're doing that now, like we did a long time ago for phone calls, literally plugging things in to make the connections. We're doing that for our various AI systems.

The number of times I go in a week now and say, "Go fetch an API key," or some sort of equivalent of that, you can see here it's going to be, "Okay, well, where do I go get that pharmacy agent ID? Where is that? Who's broadcasting that anywhere? I'm going to have to go figure that out on my own."

I'm interested, too, in general, in what you think the patterns should be for who sets this up. I guess one way to think about it is: who owns the customer relationship? In this case, it would be—if I'm calling the hospital, you framed it from the hospital's perspective and have these other things as third parties, in a similar way that if I call the hospital, they might call my insurance for me and do some background double-check.

But if that's right, does that mean that the shared context lives forever with the same entity that owns the customer relationship? Is that a pattern we should expect, or will these shared-context threads also be jointly owned or shared in such a way that any of these individual entities and their agents could come back and access them later?

Again, we have some patterns like this. If I do a Slack Connect, Slack creates this kind of shared space that both my company and the other company that connected can go back and access. But I'm not sure if we should expect the same. How skeuomorphic should this be? I think that's always a really interesting question in AI, and I don't have a great intuition for that in this connectivity and coordination space.

Yeah, let's take it one at a time. Let's just start with the basic connectivity pieces. The 4 pillars of basic plumbing for multi-agent systems are discovery, identity and access, communication, and observability.

If you get those 4 down, then you can actually create a multi-agent system like the one shown in green here, or teal, and get these agents to at least start talking to each other, even though a lot of the things that you see on the right, which is in gray, are not possible today. What's possible today is the stuff in green, or teal, in the center. They can all talk to each other.

If you think about what we did with AGNTCY, I'm just going to flip over to this window here. For folks who are just listening, if you go to agntcy.org, you'll see those 4 pillars come up here, and you'll see the architecture at the bottom. To your question of how these things get governed, there's a human switchboard, primarily for consumer use cases.

You and I do this all the time. We figure out which agents make sense. We look at their reputation, we look at the reviews, we look at their pedigree, and we say, "Great, I am going to use these." Sometimes we even depend on the LLMs to generate agents on the fly, and we're like, "Yeah, it's good enough," because it's a consumer use case.

But if you think about enterprises, enterprises don't work that way. Enterprises have long procurement cycles. They have trust and safety in the equation, and they have customer trust and responsible AI in the equation. There's a lot of trust, safety, and rigor that goes into how enterprises procure software. Whether it's agentic or not, it doesn't matter.

The way we've tackled this is that each of those 4 pillars has an entity in the software stack—in the infrastructure stack—providing APIs for that. There's an agent directory that does the job of discovery. You can define agents, you can define tools, and you can define multi-agent agents, because in the end, it's turtles all the way down. An agent could be an agent built on many agents.

You can define an inordinate amount of hierarchy within an agent: agent within an agent within an agent. You can define tool access, and you can define software and data-source access.

All of that can be defined within the directory, and it's searchable based on capability. It's like the DNS equivalent for agents. Today, you want to access a website or a remote API, you have a URI, and that gets translated into an IP address. That flows over the network, and you get routed toward it.

Here, it's not as straightforward. You don't have a fixed URI or a fixed website. You can search on capability, and you can search on reputation, so this is a little bit more involved. That's the directory, and what comes back may not be a service endpoint, like an API endpoint or a remote API endpoint. It could also be a Git code branch.

Those agents could be stood up as a service, or they could exist in a Git code tree because they might be local to you. Or you might be pulling one from a Git code tree and deploying it as code within your environment. It's a pretty powerful piece of software that allows you to search across billions of entries, trillions of entries. It's actually built on decentralization principles, so it's got a DHT that supports it in the backend.

It allows you to discover agents, bring them into your environment, and then connect them. That's step 1. Step 2 is giving them the right access and identity, and this itself is a whole different ballgame because agents, as we all know, have human-like characteristics, but they're operating at machine speed and scale.

They have agency. They have decision-making powers. They have semantic communication, which is not deterministic, but they're operating at software speed and scale. This is a blend of human-like and software-like, machine-like capabilities. You cannot rely on the old role-based access control mechanisms that have been in existence for a while.

You need to rethink access control. We've brought in the whole notion of tool- and task-based access control, and that's what the identity piece does in the stack. You've discovered them, and you've given them identity and access. Then you go toward communication.

Communication is of 2 types. One is talking to existing deterministic infrastructure, which is tools and data sources. MCP, or Model Context Protocol from Anthropic, is used for those kinds of communications. Then A2A from Google is the agent-to-agent protocol that allows agents to communicate with each other. We are foundational members of both of those, A2A as well as MCP, and they fit nicely into this architecture.

Finally, there's the whole observability piece. How do you observe not just the containers, the cloud-native infrastructure, or the bare-metal infrastructure where these agents reside, but also the agentic parts of agents? Your service might be up, but the agent might be misbehaving. How do you observe and evaluate the agent that sits within these infrastructure components?

We work together with Microsoft to push a whole bunch of extensions into OpenTelemetry, which is the de facto observability stack, to make observability for agents happen. To me, that's the bare plumbing that you need for this picture to even get connected and for you to start just working.

I'll pause here to see if you have questions, because we haven't even tackled the gray parts. We've just brought them together, and the human is still trying to be the context setter, the intent coordinator, and all of that in the middle.

A couple of questions that are really top of mind. You mentioned the decentralized directory, and I'm interested to understand that a little bit better. Obviously, one of the mega-trends on the internet has been toward walled gardens and platforms controlling the directory in many major spaces where people like to spend a lot of their time.

It seems like that is something that OpenAI might be trying to do again. I don't mean that in an overly pejorative way, but they're trying to create a curated app store like Apple before them, and so many other platforms. They're going to have reviews that they're going to be the owner of on the plugin or app store that they develop.

Then they're also going to have advertising, which is going to bring another whole layer of commerce to all that. What is the alternate vision of something more open? Is there still some sort of centralized DNS equivalent in that vision? I don't know if it goes as far as blockchain things that don't even require that. How decentralized, ultimately, do you think that can and will be?

The 2 things that you touched upon are identity, because a lot flows from identity, and discoverability, which is the DNS statement that you just made. Those 2 are the source of everything else that follows after.

You touched upon both of those problems pretty concisely. If you control the directory pieces—which is how I discover agents and how I even get to the best agent for my task—and if you control the identity, then you control the reputation. You control the security. You control how much you can charge for it and the commerce behind it. Everything flows from those 2 pieces.

We took a lot of care to ensure that, in this architecture, those 2 critical pieces—the identity and the directory—were actually built on DHTs, or distributed hash tables. Nobody owns the directory. You can participate in a directory's decentralized infrastructure.

Similarly, with identity, we do plug into the well-known identity providers, or IDPs, like Okta and Duo and others that exist out there. But we also enable a decentralized identity provider that somebody can deploy and participate in.

We're offering the best of both worlds when it comes to directory and identity, because our vision is for this to be truly open and interoperable. Through all the statements that you made, you can truly be open and interoperable if discovery and identity are also decentralized, and no singular entity owns either of those pieces.

We've taken great care to make sure that those are available as options now. Enterprises might decide to start with Microsoft Active Directory or Okta, because that's what they're familiar with. But soon they'll also realize that role-based access control is great, but they need something like task-based or tool-based access control. They might move toward decentralization.

We're not forcing one or the other, but principally, we're aligned to what we just said: We want this to be decentralized in nature.

Yeah, that's great. I think that is a really important contribution. When it comes to identity, I would love to get a little bit more of your vision for what sorts of identity are going to be supported.

This has been another major point of contention in the digital sphere broadly. Should we have anonymous accounts? What sort of clarity should we have on who's ultimately responsible for this account or this agent, as the case may be?

Now we've got people doing experiments in fully autonomous AI systems. If you give something a credit card, it can pay for its own server time. We're right on that fuzzy border where some of these things might actually be able to persist for a while, potentially not solely due to meme-coin scams, which obviously won't be a long-term strategy for them.

There are so many tradeoffs. It's such a vexing thing, and when I try to think about it, I quickly get overwhelmed. Help me be a little less overwhelmed. You may even start with a taxonomy, but I would love to understand your vision better for identity and, as we go to the giga-agent future incredibly quickly, responsibility and accountability.

Identity is actually the biggest hurdle that we're facing today when it comes to deploying full autonomy, or at least as much autonomy as possible, with agents in the enterprise, at least.

What's happening right now is that, as we mentioned earlier, agents are like humans because they communicate semantically. There's a lot of natural language flowing between agents and agents, and also between agents and humans.

If you look at a multi-agent human team, a lot of the communication is happening semantically. That's ambiguous. It's nondeterministic. There's a lot of decision-making authority that you're giving to agents, and there's a lot of tool-calling authority that you're giving to agents as well.

For enterprises especially—even for consumers when you're actually using a credit card—I would be pretty careful. You have to be really sure what access control you're giving an agent.

What we've seen all along is that identity systems and access management have been built mostly for humans. Over time, we took that as role-based access control, or RBAC. It's a very famous concept. When you think about access and identity, you think of RBAC.

Role-based access control is a very human-oriented view of identity and access. Over time, we realized that there are pieces of software and machines that do not totally align with RBAC. So, we created attribute-based access control, or ABAC.

But it's very similar, because machines don't change their personas if they're not agentic. They're doing one piece of deterministic code day in and day out. It's long-lived.

So, it’s almost like saying RBAC but applied to machines. Those are the kinds of identity mechanisms that have existed in enterprises so far. The problem with agents is that they’re like humans, and they’re shifting around. They might be Vijoy tomorrow; today, they might be Nathan in the next hour, especially in larger teams and enterprises.

We had to go back to basics and look at what it is that we’re really giving access for. When somebody gives Vijoy access within Cisco, I have access to data and systems that I can read or write, given where I’m sitting in the organization and the kinds of skills and roles that I perform. In the end, it all boils down to the tools that I’m accessing, the tasks that I’m trying to do, and the transactions that I’m participating in.

If you take it down to that level of granularity and back to basics, we said agents should use tool-, task-, and transaction-based access control. By default, you assume the lowest layer of access for an agent. Based on the tool or task that it’s trying to execute, you may then elevate privileges just for that task, just for access to that tool, or just for participating in that transaction, if they’re allowed to do that.

Then you bring them back to base-level identity and access—base-level access. You keep doing this in a very ephemeral manner, and you don’t give agents longevity when it comes to access control. This whole notion of TBAC, or tool-, task-, and transaction-based access control, is something that we proposed with Agency. It’s seeing a lot of traction and interest because it goes back to the basics of what we’re all trying to do and what it is that you should be given access for.

In fact, there’s one thing that’s pretty interesting when you start looking at this notion of task-based or tool-based access control. What ends up happening—and to the earlier question that you asked, let’s go back to the networking stack—is that, so far, we’ve been dealing with deterministic pieces of software. All kinds of access control mechanisms that existed out there, even for machines, were built for deterministic pieces of software.

With agents coming in, we’re going toward nondeterminism. We’re going toward semantic communication. When we need to give an agent access for a particular task, the question is: What is that task, and how do you figure out what task the agent is trying to execute?

The way you do that is by tapping into the semantic communication taking place between a human and an agent, or between 2 agents, and figuring out what task they’re trying to execute, what transaction they’re trying to execute, or what tool call they’re trying to make from that semantic communication. Then you give them access for that.

Right away, to enable TBAC, you need to be able to tap into Layer 9, which is semantic communication, to really figure out how to give this agent the right access control. It’s—you said “turtles all the way down.” It also screams “LLMs all the way down.”

I like the idea a lot of the minimum permissions, or the principle of least privilege, I guess, is the fancy way of saying that. Or zero trust. I was just going to go to trust; I guess there’s some repetition.

There’s trust in the first case, and then there’s also the question of whether you can cache this sort of stuff. One big thing that we have as humans, which is to our advantage in our ability to coordinate together, is that while we do, as individuals, change, evolve, and drift over time, that’s a relatively slow process. People can generally expect that one another will be similar tomorrow as they are today, if not exactly the same.

With agents, I’m thinking, “Okay, so let’s say I want to do some delegation, and maybe I want to engage with somebody else’s agents. I want to give them access to some information.” I’m getting a picture of first having my little guardian angel agent that tries to watch out for my interests and determine what I’m willing to give.

Part of how it’s going to determine that, presumably, is some sort of reputation or identity of the agent on the other side. But that still strikes me as fuzzy. Okay, sure, but what exactly am I giving access to, and do I know that it’s the same tomorrow as it is today?

How does it prove that I can trust it at all? Even just inside an enterprise, you could imagine that one department is trying to make its thing do its local optimization a touch better, and they might swap out the model. Great, maybe it tested better on their benchmarks, but over here, where I’m trying to make an independent decision on how much to trust this, can I assume that my last designation was good? Maybe I ran it through a battery of tests last time and it passed.

Under the hood, you swap out one model. Even just a system-prompt change could make a pretty dramatic difference in terms of how it’s going to behave next time. So, if I had to boil all this down, it’s: How do we make the trust designations in the first place? And then how do we have durable identity, so I know that I’m going to get consistent behavior from my counterparties over time?

I think you’re getting to the crux of how I make this nondeterministic system a little bit more deterministic.

You need to be able to reason about things, and you need to be able to persist around certain kinds of state—not all kinds of state, but certain states. The way we’re thinking about this is, again, by going back to the OSI stack. We started there, so let me take you back there.

So far, all the layers that existed in the OSI stack, when 2 endpoints are communicating with each other, assume that all the endpoints connected through a network are deterministic endpoints. They’re exchanging data, and you’re exchanging essentially deterministic state between all the endpoints that exist in that network.

What we’re seeing now is that the world is moving toward nondeterministic, probabilistic endpoints, and these endpoints are intelligent endpoints. Instead of exchanging data, I’m now exchanging cognition state. I’m a cognition entity as a human; I might have 5 agents that are also cognition entities, and you might have 5 more. We’re exchanging cognition state.

The OSI stack doesn’t have the right layers to even support that communication. Why do I need that? The reason I need it is because I need a little bit of determinism when we talk to each other—when all of these agents talk to each other.

I need to understand whether I’m in the intent-alignment state, whether I’m in the discovery phase, whether I’m in the coordination phase, or whether I’m negotiating. There are all of these phases that you go through when you align on intent and work on a common goal. We need to figure out where you are, and we also need to figure out whether you’re trying to take an action during the execution phase.

All of these meta-keywords that need to take shape between agent-to-agent communications are very free-flowing today. You’ve seen some of that happen in the OpenClaw boardroom example a couple of weeks ago, where you had a bunch of OpenClaw agents come together and just talk NLP, of course prompted by a bunch of humans in between. They’re talking NLP, but they’re not building consistent state, and they’re all over the map.

If you want to bring this into an enterprise and actually work toward convergence, if you want to work toward emergent behavior that is constructive and not just divergent in nature, you need to put some structure around it. The way you put structure around it is by making sure that the communication between these agents is also somewhat structured, compared to the any-and-all-NLP Wild West in some ways.

The layers that we’re bringing to the table are the 2 layers of L8 and L9: L8, which is syntactic communication, and L9, which is semantic communication, or cognition-state protocols. The syntactic layer is like grammar. I built an agent on Vertex; somebody else built one on LangGraph or Bedrock. How do I make sure that these 2 agents can talk to each other when their grammars look different, their frameworks look different, and they may not be sending their blobs and payloads in the same formats?

That’s the syntactic layer, and this is where MCP, A2A, and the entire architecture that I showed on Agency come into play. Above this, we bring in the cognition layer, or the semantic layer—that is, Layer 9. Layer 9 is where we look deep inside that packet, deep inside that communication flow, and actually extract the meaning, figure out what it is that you’re truly trying to do, and put some structure behind that meaning.

Instead of it just being plain, simple NLP—which it will be—can we wrap a header around it that says, “This is what I’m trying to do. I’m trying to discover information, or I’m trying to negotiate or coordinate. Which phase am I in in that cycle? Am I trying to access a tool, or am I trying to execute a command?”

There’s a little bit of a meta-header that needs to happen so that you can take action on that and build those trust and governance layers. Without them, even those pieces become a lot more probabilistic in nature. That’s the way we’re thinking about this.

Of course, the lowest common denominator is that, yes, it’s all going to be NLP, in which case, if you’re dropping a guardian angel or a cognition engine, as we call it, that’s trying to contain blast radius, it will also have to be probabilistic in nature. You cannot guarantee 100%. You can guarantee maybe 95% or 99%, but you’re not guaranteeing anything at 99% or 100%.

But if you wrap these with a header and wrap it in a proper protocol, then you can get to determinism on some of these things that are frankly requirements for enterprises to deploy multi-agent systems.

So, is this something that can exist on a spectrum as well, perhaps, when it comes to where this shared history lives? Cisco has Webex, as you said, which is one place where people come together. Those meetings can be recorded, and a lot of shared history and context can be established through that digital space for humans.

One could imagine a Cisco product that gets deployed to enterprises that’s like, “Hey, this is your Webex for agents, where they can come together, where they can create shared state, where you can have a history of this, and then you can invite guests in from other entities as you will.” Does that exist as a distinct enterprise product, or can it also have a long, open, permissionless tail to it?

I’m not even sure if that’s a fully coherent question, but I’m really interested in it. It’s not easy for an individual to interact with an enterprise, but both people and enterprises want to do that.

So, let me take a crack at this, and let’s see where it goes. The way we’re thinking about this whole Internet of Cognition architecture—and if you can see the slide here, I’ll try to describe it as much as I can for people listening in—what you’re seeing here is that the entities in teal or green are the entities that make up the Internet of Cognition. There are 3 layers that we’re thinking about.

The first is a protocol layer, which we just talked about. How can I enable semantic communication to take shape between intelligence endpoints instead of data communication between deterministic endpoints, which is where we are and where the entire networking stack exists today? We’re connecting intelligence endpoints, with semantic communication happening. What you see here in this picture is cognition-state protocols. These are the classes of protocols that enable these kinds of communication.

We have 3 types based on where we are. It could be as simple as natural language, which we’re calling semantic state transfer protocols. It could get better than that—really good—by saying, “Let me just exchange the entirety of the latent space between 2 models and 2 agents.” So, let’s take the entire KV cache and send it across. That is excellent. It’s like implanting a Neuralink chip between you and me, Nathan, so that we don’t have to undertake the cost of tokenization and transmission and detokenization back at the other end.

But I might not allow a Neuralink implant, and you might not allow a Neuralink implant, which is the case today with model providers. You can do this with open-weight models, but you probably can’t do it with closed-weight models, at least not now, unless it becomes a standard. We have this thing called a latent-space transfer protocol, which allows you to do this at really high efficiency.

There’s something that sits in between, which is a compressed-state transfer protocol. This is about maintaining invariance between agents, especially for deployment scenarios where not everything might be within an enterprise or a data center. So, let’s say you have edge cases, with edge deployments like your MacBook, your phone, or your wearable device, and something that sits within a data center. Can we send this information in a compressed way to that edge inference device? We have 3 kinds of protocols, but they’re all within that protocol layer. That’s how we talk to each other between intelligence endpoints.

Then there’s that cognition fabric. The fabric, as the name implies, allows you to scale this out. It allows many, many, many agents to talk to many, many, many agents: many-to-many communication, real-time in nature, at the semantic layer. It also allows you to plug in the memory of your choice.

We are not dictating what you plug in. You could plug in an open-source memory like Mem0 or something else. You can plug in BigQuery. You can plug in whatever your choice of memory might be. What we are suggesting above that is that you store different kinds of memories in the shared-memory and shared-context space.

You’re storing ontologies, beliefs, working memory, and all kinds of memory in memory infrastructure, but we are not dictating what you plug in. When you think about beliefs, context, knowledge graphs, and ontologies, that is shared memory across all of these agents that participate in this cluster.

Finally, the one thing that you alluded to earlier but that we have not talked about is these cognition engines. That’s the third layer. The cognition engines are accelerators or guardians. They are either cognitive accelerators or guardian angels or technologies.

This is the famous Raj Reddy quote: you would want AI to be either a cognitive accelerator or a guardian angel. Those are the 2 types of cognition engines that would exist. More often than not, they would be transparent to everything else that’s happening.

While agents are talking to each other, these are almost like the note-takers that sit within the collaboration environment that you and I participate in. These are the note-takers saying, “Yeah, don’t mind me. I’m here. I’m just taking notes.” Those are the kinds of engines that we’re thinking about. They’re summarization engines, compliance engines, and security engines that actually make sure that whatever happens as collective intelligence is possible and feasible within the guardrails of the enterprise they’re operating within.

This is a fascinating challenge to envision what this is all going to look like. One big question that folks in AI safety have wrestled with for a long time is: to what degree should we allow our AIs to communicate in languages that we don’t understand?

I mean, on the current margin of performance today, there is explicit chain of thought that is very readable and hopefully faithful to what the AI is actually thinking and intending to do. We’ve seen some weirdness in reports around chain-of-thought dialects emerging under intense RL pressure. I was pleased to learn from folks at OpenAI, both in a recent episode and in a paper they put out today, that basically, that hasn’t been as big of a problem as those few reports would have suggested. Mostly, the chain of thought remains pretty vanilla and pretty human-interpretable.

On the flip side of that, there was a paper out of Meta where thinking in latent space is starting to be unlocked. Everything is detokenized: you just pass your last high-dimensional state into the next embedding position, and you might be able to think faster, better, and more in parallel. What was really notable from that paper was that pathfinding algorithms worked better when they were able to think in latent space, so a certain superposition of reasoning was able to be unlocked.

That feels like a pretty natural attractor if we just say we want to make these things work as well as possible. But I’m a little concerned, honestly, that it could get away from us, especially when you combine it with extreme speed.

I don’t know if you’ve had a chance to use chat.jimmy.ai in the last couple of weeks, but this is the company that burned the actual architecture of a specific model into the silicon, and they’re achieving 15,000 tokens per second. Even just a couple of queries on chat.jimmy.ai—I recommend it—are enough to put that in perspective. It’s a pretty basic model today, so I’m probably not going to use it that much, but it’s perspective-forming, for sure, to go see what it looks like to get 2,000 tokens back in 1/6 of a second. It’s wild.

How do we keep our arms around this? Do you think we should set certain rules? Do you think we can use interpretability techniques? Are there AI governor systems that you think we can get to the point of reliability where we can count on them? This is a topic that could go on for hours, but I’m very interested in at least your first layer of thoughts on that.

I believe that we need to move toward unlocking emergent behavior. I’m completely bought into the horizontal-scale aspect, where you need to bring in agents with different expertise and different models.

We’ve seen this pattern in software systems in the past, where you would not want the same piece of code running in your environment because then, for example, you will not discover the right zero-day bugs. Or if there is a zero-day bug, your entire system will go down.

There is this best practice even in deterministic software where, for redundancy and availability, you would want different pieces of code that are trying to achieve similar goals to be deployed in an infrastructure, because at least we’re not hitting the same scalability challenges or the same security challenges.

It's just the diversity that helps you out. The emergent behavior, even with deterministic software, is actually something that we should strive for in large-scale cloud systems. If you take that into these nondeterministic systems, and based on, again, the analysis that we've talked about in the past, where you want to scale out intelligence horizontally because that's how humans evolved and that's how I believe intelligence in machines will evolve, in addition to vertical scaling, I'm of the strong belief that you need to enable these emergent systems to take place. And the more granularity of motion, the better it is because that's how we operate.

I mean, the most chaos you can throw into the environment, the more innovation that you get. Now, that's why the cognition engines exist, because I know I cannot pass through this table because the laws of physics prevent me from doing that. Within an enterprise, these cognition engines are those swim lanes, those guardrails around what's allowable and what's possible. So, you need those to be really effective, and that's a challenge. It's going to take us a little bit of time to get those things right.

But given that construct, I am of the belief that you need to enable emergent behavior. You need to enable teams of multi-agent systems communicating semantically, sharing cognition state, and solving for something net new because that's how it's going to happen. And if you take that premise, why would you slow things down? I would actually want that multi-agent system to reach emergent consensus, hopefully faster than going through NLP and the cost of tokenization, interpretability, and negotiation—all of that actually adds cost.

So, I am of the belief that, yes, agents are human-like, but they're also not human-like. A human cannot make an API call. A human doesn't have a KV cache that I can send across. I cannot ship my latent space to you. An agent can. So, let's leverage the properties of agents that are not available to humans and make them better than humans.

Now, there are pitfalls. You might get into divergent properties and outcomes. You might get into super-specialization, where they're all getting siloed and they're not talking to each other. So, in addition to guardrailing compliance, security, identity, and access, we need to also have these cognition engines, and that's why they're engines and not just guardrails. We are watching out for divergence. We are watching out for extreme specialization and all these problems that might creep into multi-agent systems. This is also an interesting area where we need to start modeling, and there are many, many papers here, when you start modeling multi-agent systems using game-theoretic approaches, because we need to bring those notions into agentic competition as well.

Yeah, I couldn't agree more. A lot has been done, I guess, but it seems like there is just an incredible reservoir of research on how people behave under myriad game-theoretic premises, and we're going to need to get really good at characterizing AIs along similar dimensions, especially if we're going to turn them loose at high speed and with latent-to-latent communication that we'll have a hard time making sense of even post hoc, probably in a lot of scenarios. The ability to even characterize what agents are going to do under various scenarios right now remains really challenging.

We are getting a glimpse of that already, Nathan. If you look at, again, going back to the OpenClaw example, even though, like I said, it's just chatter right now and it's not building shared cognition, there is a Markdown file that we all know about called SOUL.md. Peter actually created SOUL.md to give his agent a personality close to his own personality. I have not turned it on yet, but a bunch of my friends have actually turned on their own OpenClaw agents, and they all have their SOUL.md customized, so we get many, many personalities, as many as there are human individuals.

This is just the beginning. It might seem a little gimmicky, but if you play this out 1 year or 2 years out, you are entering that world where you'll have agents with expertise and personality, just like humans, and they will be your teammates in a multi-agent human society or team. So, how do you make sure that the infrastructure that you build enables this multi-agent human team or society to collaborate together, share intent, coordinate, and then be guarded in the proper ways that an enterprise would want?

And so, we're getting there. I don't think it's science fiction. You can see that path taking shape.

Yeah. That might be a great place to leave it for today. I know that I've already kept you a little bit long. I would love to check back in. I feel like this is going to go pretty fast, but I would be very interested to touch base again in 6, 9, or 12 months—12 feels long—and see how this is coming together, and especially see how those guardrails are developing within the enterprise context, because I see everything else really happening fast.

The one thing that I'm not so sure is going to be able to keep up is the layer that supervises it all and makes sure that we're actually getting what we want out of this whole AI transition, and making sure, obviously, on the flip side, that the whole phenomenon doesn't run away from us. But I do like a lot about what you're saying, because one of the things I've learned in life—I say this episode after episode—is that anything that becomes too concentrated can become dangerous. You see that in drugs, you see that in all sorts of phenomena. And I kind of worry that too much concentrated intelligence itself is also going to be dangerous.

So, what's the alternative to that? It's got to be some sort of distributed, buffered, networked, more ecological, hopefully open at least on some margin, and permissionless system. And I think it is. I was just texting a friend earlier today: We need a decentralized, permissionless coordination and reputation layer so badly. So, I am really excited about the work that you're doing on it, and I'd love to come back again before too long to understand that next level up and how it's evolving.

Actually, the 2 comments that you made there, let me just provide a 1-second overview of that. You talked about the models actually becoming smarter and the guardrails not keeping up. And you also talked about centralization from the capability perspective and the need for decentralization or distribution per se. I'll flip those 2 around and say that in the enterprise, if you want traction in the enterprise, both of those statements actually have to be true.

Because enterprises will not deploy solutions where the guardrails are not well thought out and effective. And that is, to me, a hurdle for this runaway train—which is actually on a good path—that we all call generative AI. That's a hurdle for those things being adopted in the enterprise: getting the guardrails right. Because if you don't get it right, we don't get adoption. So, it's a requirement. So, it's a chicken-and-egg problem.

And the second thing is, in an enterprise, like we discussed earlier as well, you will not get a singular player coming in, because you will get multiple players. Look at us or any other enterprise: you'll have agents from ServiceNow. You'll have agents from Salesforce. You'll have agents from Microsoft, from OpenAI, from Anthropic, from Google, and from Cisco. You'll have agents from all of these companies that will exist in our environment by definition.

And by definition, they'll have to come together, get connected, build shared cognition, align on intent, and work together, because you will not get a singular agent that does all of those functions. At least not in the next 5 years. So, these 2 are requirements. It's not even a good-to-have for anything to get adopted in the enterprise.

Yeah, this has been fantastic. Is there anything else that we didn't touch on that you would want to make sure you leave people with before we break?

Yeah. We've been talking about all of this in the abstract: the whole Internet of Cognition, the 3 layers of shared intent and coordination, shared context and knowledge, and then collective innovation, where we enable emergent behavior. Going back to the Jarvis example that we talked about right up top, where we built this SRE system, a multi-agent system that enables SRE teams to get more productive, we've actually taken it a step further and built a multi-agent system for SREs where an outage has happened, but they're all sharing cognition and state and doing collective intelligence and innovation with other agents from cloud providers, from the marketing team for brand reputation, and from finance, who's looking at costs.

There's a white paper to read through that talks about all of these things in more detail. But also, there's a live demo. I'm just going to quickly share that here. This is a clickable demo that you can go in and walk through. You can go to archif.cisco.com, Internet of Cognition; we'll have it in the show notes. You can see what happens per agent: the activity per agent, the intent that takes place per agent, the context that takes place per agent, and the reasoning that is happening collectively and in an emergent way across the entirety of the multi-agent system. It'll make it a little bit more real behind what we've been just talking about in this episode.

Love it. I always say a working demo is the coin of the realm, so I definitely encourage people to go check it out. I'll click through it myself, no doubt. Okay, fantastic stuff. Vijoy Pandey, thank you for being part of The Cognitive Revolution.

Thank you, Nathan, for having me.