How NetOps Can Embrace AI to Lead Innovation

Chris Wade • 00:05

My name is Chris Wade. I’m a co-founder at Itential. Thanks for everybody’s time. Today we’re going to talk about the intelligence layer, and we’re going to talk a lot about agentic automation. We’ve had a lot of good discussions this week, and what I’m going to talk about is how we’ve really been missing an intelligence layer.

Chris Wade • 00:28

A lot of industries are looking at how to bolt AI onto their strategies, and I think it’s a very natural fit for network automation. When we talk about automation, we’re really talking about how we can have a better operating model for infrastructure. So instead of just talking about devices and services, I think this really helps transform how we talk about operations. The goal of my presentation, trying to be very direct, is to talk about agentic technology. But given the topic and a couple of the jeers this week, it’s not to offend anybody or offer non-constructive hype. So I’m looking for your feedback on that.

Chris Wade • 01:07

Before I get into the next slide, I don’t know if Mike Bushong is still here, but we talked a few weeks ago about how we could tie our presentations together, and after the presentation on Monday it became pretty clear. For those that remember, I’m not going to redo the joke with Collect Underpants, but it was really about AI: there was a big question mark in the middle, and then profit. The purpose of my presentation today is centered on that middle question mark. So we’re going to start with where we’ve seen automation success. This week and in previous AutoCons, we’ve talked about where we are successful with automation, and we tend to talk a lot about hyperscalers.

Chris Wade • 01:47

We talk a lot about data centers. The attributes of these environments are highly standardized infrastructure. We take compute automation and extend it to networking. There’s a lot of replacement lifecycle, typically a Linux-based automation strategy, with a bunch of software developers. And from listening to the speakers here this week and at previous events, most of us don’t live in those types of structured environments.

Chris Wade • 02:17

So we’ve had many attempts at automation. If we think about adding this agentic layer, we’ve tried to build intent-based frameworks. These typically have a lot of data models. We talk about multi-vendor abstractions. We’ve tried to close the loop between these different components. We’re going to talk a little bit about the NAF framework in a bit, and I think we’ve made some great progress there.

Chris Wade • 02:42

Beyond intent-based frameworks, we’ve also talked about data structures and sources of truth. Over the last 10 years we’ve lived in spreadsheets, and we’ve made a lot of progress toward these sources of truth. But this has also been a blocking item for a lot of organizations trying to move forward with automation; they focus a lot of their time on their data strategy. And then infrastructure as code. We’ve all been living this for the past 10 or 15 years, and we’re going to talk about how agentic can help augment and accelerate our journey with infrastructure as code. So intent-based frameworks, sources of truth, and infrastructure as code have been the dominant themes over the past 10 years.

Chris Wade • 03:25

We’ve made a lot of progress. So why have these approaches not gotten us where we want? We’re still, with NAF, asking the key question of why we have not achieved network automation. A lot of these abstractions don’t hold. We have vendors differentiating every day. In the early days we talked about building abstractions across, say, a Cisco and a Juniper infrastructure, and these vendors are constantly innovating and constantly differentiating, which makes those abstractions very difficult to manage over time.

Chris Wade • 03:55

We’ve been through the efforts of retraining our network engineering staff to be software developers. And we have a lot of DSLs. DSLs are awesome. They were invented for us humans. They allow us to build abstractions so we can automate at scale. But these efforts have only gotten us so far. If we talk about infrastructure as code, which has probably been the most dominant positive over the past 10 or 15 years in my opinion, the one downside is that we used to have design documents and methods of procedure, and we’ve basically taken those documents and encoded them into our software.

Chris Wade • 04:30

Which has been great. It makes it idempotent. It allows us to run it at scale and run it headless. But by merging our design documents and our implementation details, we made it not very portable. If I take a pipeline from one environment and go get a job in a different environment, very few times is it portable, because I have my designs, which I think are very portable, and my implementation details, which are not, and I’ve mushed them together into that infrastructure as code.

Chris Wade • 05:06

As we think about determinism, and I haven’t heard the word too much this week, if we talk about all the pipelines and all the scripts, today we live in a deterministic world. That is the tool we have. And the best thing about determinism is that it is deterministic. When we build a pipeline, we generally start with something very simple. Maybe we start with a pre-check, we get some data from a system, we generate some config, we push that config, we do a post-check, and we notify. The initial thought is a very straight-through process. Once we start putting it in production, we start realizing the worst thing about determinism: it continues to be deterministic.

Chris Wade • 05:51

I have to consider every error condition. I have to consider when the devices are offline. I have to consider when the data is not correct. For a lot of us, our pipelines end up looking much messier, because we have all of this execution logic and implementation logic combined with our design concepts. That cost of complexity builds up technical debt. I work for a software company. We have pipelines to build our software.

Chris Wade • 06:21

Whenever we need to make changes, it’s a constant effort to keep tweaking those pipelines. Ultimately, we can only support so many pipelines as an organization. When I talk to folks who run networks at scale, we typically have this conversation: how many pipelines do you have, how flexible are they, what is the technical debt? Typically, we can only automate so much of our infrastructure because of the technical debt associated with our pipelines. Any time I want to change one, the amount of testing I need to do is quite aggressive, and most of our lab environments don’t map to production.

Chris Wade • 06:57

Every edge case makes it harder and harder to manage. So we’re going to rethink automation with agentic. Hopefully that set the stage for where we’re at today. I’m not going to do too much interaction with the audience, but I do want to see how many people are using AI or agentic concepts today. Awesome. I’d say 50 to 60%.

Chris Wade • 07:28

When I talk with teams using AI, it’s generally a GenAI concept. We’re attempting to build configs. AIOps platforms, we’re doing some analysis. We’re typically building tailored charts and analytics. But for today’s presentation, I’m going to focus on agentic concepts, and I’ll frame that up in a second. When I hear people talk about use cases that worked very well and use cases that didn’t, it’s highly dependent on the actual LLM.

Chris Wade • 08:02

We’re going to talk about how to put the LLM in the right position to get the most positive outcome. I borrowed this smiling curve, which was introduced for the PC industry in the 80s, basically talking about value: on the left-hand side, the R&D was high value; on the right, the vendor was highly valuable; and in the middle, the manufacturer sat at the lowest value. When I look at the LLM, there are really two edges where it’s very successful. LLMs are very, very good at general knowledge. If we ask how to do a software upgrade, what a port turnup looks like, what a network looks like in general, theory, practice, fundamentals, it tends to be very good.

Chris Wade • 08:53

It’s also very good in the very, very specific. Things like RFCs, design documents with extreme detail. If you ask it about RFCs, you’ll get very robust answers. The messy middle is where the LLMs tend to be less good. My experience talking with users is that we typically ask LLMs questions in this messy middle, and we tend not to get good answers. OS-specific questions, multi-vendor types of questions. So the question is: why is it less good in this messy middle?

Chris Wade • 09:30

And how do we focus our efforts on those extreme ends where the LLMs are good and our agents will behave very successfully? Again, it’s very good at the very specific and the very abstract. But why is it less good in the middle? Our vendors typically have their specific details behind paywalls. The LLMs don’t have access to TAC tickets. They have not analyzed the code bases of our vendors. That’s the gap we typically need to avoid.

Chris Wade • 10:09

We can all work together, talking to our equipment providers, on how to gain access to this. We might get it in a small language model one day, or we might get it through agentic interfaces. So as we transition into agents: what is an agent? I have it broken out into three layers. At the bottom is MCP. This is really the connector from the agent to our infrastructure. It provides the what.

Chris Wade • 10:41

Think back to a metaphor we’ve had in the past: we used to work with infrastructure through a CLI, and then we came up with a very programmable interface in NETCONF. Vendors started coming out with their NETCONF implementations. Some just wrapped their CLI in NETCONF, which was very poor, and some rethought how to manage their infrastructure through that interface. We really need to focus on the MCP ecosystem, on how we rebuild these interfaces to support agents. And if we think about it, the context window, which we’ll get into in a bit, is the amount of information the agent has to think through.

Chris Wade • 11:24

Our job, when we provide MCP servers, is to provide context to the LLMs in the most appropriate way, similar to how I would have a NETCONF payload in a YANG format so I could make modeling decisions. The layer on top of that is the skills layer, introduced in the last year, which is really teaching the agent how to do something. If MCP provides access to the information, a skill describes how to interact with that data, and it’s a very reusable concept. Ultimately, the agent takes the context, takes the skills you provided, takes the access to information, and decides when it’s going to execute. More specifically, I’m going to spend some time on a ReAct agent today.

Chris Wade • 12:20

If we have just the LLM and a prompt, that’s really our experience with a ChatGPT or a Claude today. I ask it a question, it goes to the LLM. Those who remember when the reasoning models arrived: responses got slower because the model was actually breaking our problem down into smaller problems and reasoning through it. The next thing I can add to a ReAct agent is tools. We just talked about MCP and APIs. Now my agent starts to integrate with the environment. I can still prompt it.

Chris Wade • 12:58

I can still ask it a question. It still goes to the LLM and reasons. But now I can actually take action. I can reason and I can act. I can reason and I can act. And this ReAct agent runs through a loop until it gets to a conclusion. Then I can add knowledge bases and skills to the agent.

Chris Wade • 13:20

The knowledge base might be my network policy or my AI policy. It’s how I influence what this agent can do, and the skills give it the trained understanding of how to do things. When we talk about a ReAct agent, it comes down to the combination of our original prompt and LLM, which was our original chat interface, tools to integrate with the environment, and the skills and knowledge base for a positive outcome. When we wrap all of this context around it, we can see how this agent can be much more successful than we might have thought. Context is everything for agents. The more effort we put into the knowledge and the context, the better outcomes we’re going to have. I like to use a metaphor: we’ve all been on a 2 a.m. outage call.

Chris Wade • 14:13

I get woken up, I dial in, I start asking questions. What have you tried? What is it connected to? What type of outage is this? I think of it as building up my own context so I can make a decision. When we think about building these ReAct agents, imagine the agent waking up at 2 a.m. to respond: what context do I need to provide it? What knowledge does it need? Does it need to work with the environment around it? At the end of the day, my own context window at 2 a.m. is very, very limited. So we should think about how to give the agent the appropriate information for a positive outcome. To extend that further, let’s compare this to a user.

Chris Wade • 15:02

When I’m hiring a NOC employee or a software developer, I think about the knowledge they bring into the job. From an agentic perspective, that’s the LLM: it has been trained on the knowledge base. Then I build processes: what are the processes for that job? Just like the ReAct agent, there’s a corollary in prompting. I also need to train that user, and I need to build skills.

Chris Wade • 15:32

And that user needs access to software and tools to do their job, just like an agent does. As we think about building a full lifecycle around these agents, making them successful isn’t about leaning on the quality of the LLM. It’s about providing the entire context: processes, tools, and knowledge base, so we get a positive outcome. So how are agents different from scripts? I started with our deterministic efforts, and now we’re moving into our reasoning efforts. At the end of the day, we’re not going to replace our deterministic concepts with agents. It’s about finding the right balance.

Chris Wade • 16:13

On the deterministic side, we follow every error path. We fire all this logic, and this is the logic where we don’t want any flexibility in how it executes. On the other side, we have reasoning agents working through problems. I don’t have to predefine every single thing that happens. I can allow some flexibility so the agent can reason through it. It’s about the deterministic clean path versus the complicated, and finding the balance for each use case. We all work in different environments.

Chris Wade • 16:49

We all support different use cases. For each use case in each environment, the answer will be slightly different. That’s where we need to figure out how to balance these different skill sets and concepts for our particular environments. And as soon as we start talking about running agents in our environment, governance comes up. Governance has always been here. When I’m running Python or Ansible or deterministic outcomes, I’m still concerned about guardrails, security, secrets management, and access to infrastructure. With agents, it becomes an even larger conversation.

Chris Wade • 17:26

Most of our organizations have an AI governance framework and an AI governance team. The question is: how do we engage with them? When we talk to different organizations, sometimes that AI governance team sits on a whole different side of the business. Most of us think they’re there to say no to us, but they really have a dual mandate. They’re trying to move us forward with these agentic concepts while also providing the security and frameworks to make sure we’re taking everything into consideration. So, we talked about ReAct agents. I’m going to talk about two different types today.

Chris Wade • 18:10

We’re going to talk about build agents and operate agents. They are very distinct and separate concepts. Everybody’s seen plenty of articles on the internet. We borrow a lot from the software engineering discipline, and we just talked about infrastructure as code. If we look at AI-generated code in software engineering, we read articles every day about it increasing over and over. That’s the result of these build agents.

Chris Wade • 18:42

With build agents, whether we use Cursor or Claude Code or Codex: when we first thought these build agents were coming, we thought we’d have unique agents for different activities in the network. We thought we’d have a build agent, a test agent, a development agent. What’s actually happened is that we have universal code-generation agents, and we provide them skills so they take on different personas. In the software engineering discipline, we call it spec-driven development. I have an image up here, and these things are not happening on their own. They’re very human-led.

Chris Wade • 19:28

We have an automation developer. They’re using their agent harness: Claude Code, Codex, Cursor, your favorite build agent. Then we load specific skills to do each of these activities. You might have a requirements collector. You might have a solution designer. They might generate the code, and you might have a release manager.

Chris Wade • 19:46

You can see this maps closely to how we build code with infrastructure as code today. I’ll go through a quick example. From talking with folks this week, people have done some basics here, but I still think that from a vibe coding perspective, we assume the outcome is very unknown. So let’s look at an example. Port turnup: this is a spec file. It’s very basic, but it gets across how robust these things can be. You define the problem, you give it a high-level flow, you explain the phases.

Chris Wade • 20:26

There are key design decisions. You have in-scope and out-of-scope concepts. You might have the risks, the assumptions, and the requirements. When I think about writing Python or an infrastructure as code pipeline and collecting requirements from my end user, a lot of times I have much less than this. You can imagine that as we enable these coding agents, the more robust the inputs, the more positive the outcomes. I want to show one example of translating this into an actual plan file that a coding agent would generate.

Chris Wade • 21:05

The next step is passing it to the solution designer. You can see it takes my requirements and provides a resolution of those requirements. It tells me whether it’s going to satisfy them. It tells me the design decisions it’s making, where it’s going to build a Python script, where it’s going to build a workflow.

Chris Wade • 21:24

It tells me how it’s going to test it and how it’s going to design it. Ultimately, it gives me a component inventory. How many Jinja templates am I going to build? How many Python scripts? How many scripts and workflows am I putting together? This lets me, as the automation developer, walk that agent through building my outcomes, just like in the software industry, where more and more of the code is being generated.

Chris Wade • 21:50

It doesn’t mean the coding agent is building this on its own. We are shifting our effort from the actual instrumentation of the code into designing these systems. If we think about designing infrastructure, we can put our effort into how we want to architect our networking and our operational procedures, and remove ourselves from some of the implementation details and the technical debt that comes with them. All right, so that’s build agents. And just to back up on build agents: those can be purely deterministic outcomes. For those of you concerned about running agents live in your network, who don’t want agents making config changes, you can still adopt the build side very robustly, and all of those outcomes can be deterministic.

Chris Wade • 22:48

If you want to keep running a deterministic operational model, you can still enable your team to use these build agents agentically to generate that code, so you move from implementation to design. It does not require you to run agents live in your network. But now let’s look at operate agents. These are agents that are actually going to do things in our network. As an end user, maybe in the NOC or managing infrastructure, I’m going to start thinking of myself as managing teams of agents. These could be software upgrade agents, port turnup agents, network troubleshooting agents. And just because we’re running agents doesn’t mean I can’t interact with them the way I have traditionally.

Chris Wade • 23:34

I might still want to put them in a pipeline through APIs. I might want forms. I might want events. The question is: how do I put these agents in my infrastructure and manage them the way I manage other automations today? Just a reminder of what these agents are: they’re probably ReAct agents. They’re probably still being prompted.

Chris Wade • 23:59

They probably still have tools. But in this case, we’re talking about agents that are actually integrating with your environment. Let’s look at an example of a NOC connectivity troubleshooting agent. This is where I prompt it on what it’s going to do. Back to my 2 a.m. call: before we get on the bridge, maybe the agent understands a skill set. Maybe it knows how to ping infrastructure.

Chris Wade • 24:24

We’ve all pinged, run traceroute, et cetera. But now I have a knowledge base, so I’m constraining what this agent can do. It understands our network use policy. It understands our IT AI policy. It understands our maintenance window policy. We’re providing all of this in the context window.

Chris Wade • 24:39

This agent probably has more information than I do when I join the bridge to help make these decisions. So how do these agents work within your environment? They can listen to your ServiceNow queue. They can run tools and updates. They can send emails on your behalf. And they can engage with those around them, just like we do today. Now, I listened to a bunch of great talks this week on the network automation framework.

Chris Wade • 25:14

I typically think of the boxes as being a little simple and the lines as being more complicated. I listened to presentations on both the low-code and pro-code versions of this. Just like we’re talking about agents, the question is: how do agents participate in this ecosystem? Do we evolve the framework? Do the agents live in the boxes? Do the agents engage with the automation framework? Or do we rethink components of how this might work?

Chris Wade • 25:48

When I thought about it, it’s really about complementing the existing framework. We could add skills to the framework. Because a lot of this will be reusable across all of our environments, we could share prompts related to agents. We could create an MCP ecosystem where we share MCPs for the multi-vendor environments we work with today. And maybe one of the core concepts, which I’ve brought up a few times, is getting back to the design documents and the MOPs: decomposing our infrastructure as code strategy into design documents and implementations. If we move to design documents, as I showed with the build agents, we can auto-generate some of our implementations from those designs, based on the NAF framework and the skills we have in place. So when I think about where we are on agentic acceptance, I’m having a bit of déjà vu related to automation acceptance.

Chris Wade • 27:05

Before we had AutoCon Zero, there were a lot of discussions about even the ability to run scripts in production. In the early days of automation, there was a lot of human-in-the-loop. We looked at a lot of diff sets. There were a lot of requirements for humans to approve every change going into the network. We’ve come a long way, in the sense that we have pipelines running headless and we deal with exceptions. But when I look at where we’re at with agentic acceptance, we have the same automation concepts, and we’re recycling back to the beginning.

Chris Wade • 27:39

With this new technology, we’re probably beyond the experimentation phase, and we’re starting to build our first agents. But most organizations want strong human-in-the-loop with where AI is today. I think we can all see where we’re going with AI better than we could with automation, because automation was our first rodeo. AI is, at its core, an automation technology, and we can pattern-match. We have better forecasting of where this is headed. The question is whether we move forward aggressively or not. We’re going to move from human-in-the-loop to human-on-the-loop to human-out-of-the-loop. We’re going to build our first agents.

Chris Wade • 28:26

We’re going to combine them with determinism. We might even create what I call a determinism sandwich, where we put the agents underneath some determinism so we can control them even more. With this new technology, we’re going to want to make sure we’re comfortable with where it heads. When I think about next steps: we’ve all had our ChatGPT experience. We ask it some questions and get an answer we maybe don’t think is correct. But if we think back to where LLMs are good, I do think we should re-evaluate, and think about putting these agents and these LLMs in the best context so we get the most positive outcomes. We can build our first ReAct agent.

Chris Wade • 29:20

We can think about building the skills and the knowledge particular to our environment. And I would ask everybody to reach out to their AI governance teams. We have this internal talk track that those teams are there to prevent us from moving forward with AI. I think we’ll get more support than we expect. Ultimately, we need to work with our vendors on getting quality MCP servers, and getting access to the LLMs and the skill sets they have, so we can move forward with adopting agentic technology. At the end of the day, we can think about how we put agents at the core. A lot of us are thinking about how we bolt on AI, how we bolt on agents, but I think this is truly transformational.

Chris Wade • 30:10

I think it’s going to help us move forward with a lot of the promises we’ve had in NAF with automation. And with that, let’s move to questions.

Scott Robohn (Moderator) • 30:19

I’ll take conference organizer privilege and get the questions started. You’re responsible for shipping real product. You have revenue relying on what you do. You didn’t just wake up on a Tuesday morning after a long weekend and say, we’re going all in on SDD, I’m assuming. What did you do to test, to build trust, to decide this was going to be a good approach for you? And can you apply that to the network operator too? It’s a two-part question.

Chris Wade • 30:59

Sure. I think it’s a longer process than I would have thought. Much like configuring a network, most of our developers are very thoughtful about the code they write. They’re very proud of the code they write. Their experience with LLMs, especially when we started talking about vibe coding, was that they didn’t feel good about the outcome. Ask it to write a function call, and the outcome is something you’re less interested in.

Chris Wade • 31:36

Hopefully, as we saw in the spec-driven development example, when we start thinking about engineering and designing the system versus the implementation, once you build up those spec files, you start to see the quality of the outcome improve. A lot of our developers got to start focusing on larger problems and larger feature sets, and they saw their velocity improve. I think that with spec-driven development for networking, we can get back to the design documents in the same way. I used to work in a NOC where we had a method and procedure book, and depending on the alarm, we would flip to that page, and it was a very detailed procedure. In most environments I see today, that’s disappeared a bit: we either write the code ourselves or we write Jira tickets so other people write the code. Those design documents typically sat on the shelf. They were documents for another day.

Chris Wade • 32:37

The awesome part about spec-driven development is that we can shift, I don’t know if it’s shift-right or shift-left, but we can shift back to our design documents and thoughtfully focus on the architecture and design of our systems. Once you believe the code is free, once you believe the implementation is free, which is where a lot of software developers have landed, it becomes very obvious. I think we’ll go through similar things in networking.

Audience Member • 33:11

Hi, Chris. Thanks. I have a question about the files you showed that you’re using to prep for build, which are essentially the specs. There’s a lot of context there, and it sounds like you’re pretty far along with agentic development. I’m wondering if you’re having any issues with context windows. There are things I would know when I wake up at 2 a.m. on that call: context about the current situation, and I agree the spec doc will have more detail on that than I will at 2 a.m. But there’s another part of the context I carry, which is 15 or 20 years of experience. There are a lot of places where I’ve touched the hot plate and gotten burned, and I don’t know that I can put all of that into the spec file.

Audience Member • 34:02

Or maybe I can. So I’m wondering if there’s a context window issue: how do you build in, and this comes back to some of the security things, the places where I know I shouldn’t expose certain things or do certain things? Is there a limit to how much context you can provide, and does that exclude some of the tribal knowledge you might otherwise get from a developer or an engineer?

Chris Wade • 34:26

Good question. I think the components of the ReAct agent we discussed are the industry attempting to solve that problem. If we think about memory and context, we talked about the knowledge base: how many documents, how many Confluence pages can I put in there? An evolution of that is RAG, where I’m selecting the right document at the right time to fill my context window. That’s where we’re moving from vibe coding to spec-driven, and you’ll also see us moving from prompts to proper context windows.

Chris Wade • 35:09

Can I write enough prompts to fill up my context window? Maybe not. But when I talk about the MCP protocol as an example: instead of just asking the database and getting a dump, it’s about getting the appropriate context, which is why context is in the protocol’s name. The more systems provide context through MCP in the appropriate way, and the more we structure our knowledge base so it picks the right document at the right time, then if the agent can get the right information from the network, with the right knowledge base for how we want to operate our infrastructure, the context windows as they sit today are much larger than we perceive. In software engineering, do you want to shove your whole code base in there? That’s usually where we blow it out.

Chris Wade • 35:55

From a markdown document, a couple of knowledge files, some prompting, and a response from the data, I think the context windows for our use cases are less concerning.

Audience Member • 36:08

Hello, thanks very much. How are you handling token budgeting? Are you giving individual engineers or teams their own budgets, or are you moving toward fleets of agents and the token budgets they’re set against? Or is it a bit of both?

Chris Wade • 36:29

I think we’ve moved beyond token maxing in the industry. But yes, we need to budget for tokens like we do with everything else. I like to split it into two different concepts. When you’re using tokens on the build side, that’s typically a one-off activity, so there’s less concern about how teams leverage their token budgets. Now, if you’re going to run something 10 times in the network, 100 times, 10,000 times, a million times, you start to look at that token concept, and you have a multiplier effect. As we move from humans to agents, agents can scale certain things much better than we can today, just like scripts can. They can do compliance checks every hour.

Chris Wade • 37:25

They can look at every interface every day: things we can’t do today. That’s where we decide: do we want an agent that uses tokens in its reasoning in real time, or do we want to use the build side so it’s very deterministic? Do we want to use CPUs or GPUs is how I like to think about it. And that gets back to the balance of reasoning and determinism, the balance of scripts and reasoning.

Chris Wade • 37:53

When we have that beautiful straight line of determinism, the most common outcomes stay deterministic, so we’re using CPUs. Then we move the error handling and the long-tail effects, the thousand things that could throw the pipeline off, into reasoning. It’s worth my token budget for the reasoning to keep that pipeline from failing in the middle of the night. On the build side, we probably want to unleash this and let our users maybe overextend themselves, because it’s interactive and overseen by humans. I’m not going to throw a thousand loops overnight and come in the next morning having burned 100 million tokens. It’s really about finding that balance, from an operate perspective, of what’s deterministic and what we want reasoned through.