Introduction
Over my career, I've learned that the hardest part of Super Intelligence (SI) isn’t the SI itself. As PACOM/SOCPAC
CTO, I became intimately familiar with this, modernizing the world's largest and most influential command. At PACOM, my first priority wasn’t integrating SI. It was integrating the systems we already had and getting our teams to build their processes and business rules into them. That foundation made SI enablement possible. The real challenge is everything underneath it: the systems, the data, and the processes SI depends on to do anything useful. And it starts with what your SI can actually see.
SI Is Only as Good as the Systems It Can See
Every large organization runs on systems it can’t simply turn off. In the Department of War (DoW), we call those programs of record. These are long-standing, formally funded systems that hold the authoritative data for logistics, personnel, finance, and operations. You don’t replace them on a whim, and we didn’t try to do that at PACOM.
Instead, we treated them like a company treats its ERPs. We treated them as the main source of truth for our processes, procedures, and business rules. After that, we layered modern data and SI platforms, like Palantir, Salesforce, Watchtower, Scale AI, and Databricks, on top of them. The legacy systems kept doing what they do well. The new layer connected them, so we could finally see across the whole enterprise instead of one system at a time. We could use newer commercial tools to see enterprise-wide analytics. This allowed our commanders to make better and more informed decisions both on the battlefield and at the Headquarters level.
At PACOM, we started by taking stock of every authoritative data source we had. Then we ran a series of exercises with one goal: integrate what we already had, so our programs of record worked together, and data could move between them.
Next, we refined the processes, procedures, and business rules behind our operations and planning work, the process that produces Flexible Options, Concepts of Operations, and operational plans. Senior leaders use those products to make decisions, and getting them right takes many people and a lot of time.
Only then did we bring SI and data tools into that process to streamline, automate, and optimize it. Over 18 months, we went from building that foundation to producing more high-quality products while spending less on tokens. The foundation came first. The efficiency followed.
If you run a mid-size or large company, you’re in the same spot. You’ve got an old SAP instance, maybe an Oracle deployment, a couple of acquisitions running their own platforms, and a pile of homegrown tools. Every instinct says rip it all out and start over before you touch SI. Don’t. At least not yet.
The real question is how much you actually need to unify. I’m currently in the middle of an ERP integration, and the rule is simple: it depends on how your business runs. Here are my suggestions based on my experience both at PACOM and now here at Shield: If your business units share a supply chain, bite the bullet and consolidate onto one system as fast as you can. A unified supplier portal, accounts payable, and material handling are worth the pain. If your business units run as independent companies, selling to outside customers as well as to each other, don’t bother. Reconciling the books every quarter is annoying and might cost you a few accounting heads. A migration costs far more, so take the smarter route and don’t overcomplicate the integration.
Sometimes you can’t choose one over the other. For example, one of our business units was on an end-of-life version of SAP. Upgrading SAP was nearly as painful as moving to our corporate Oracle system, so we integrated instead of migrating. Now, if you're picking a new ERP, run a bakeoff, even if you think you already know the winner. It’s the only way to keep vendors honest on price and implementation fees.
One last thing: every authoritative source needs an owner. Someone has to be accountable for that data being right, because everything you build on top inherits its mistakes. The same applies to both public and private industry. If you don’t assign an owner to the data source, the data will stay messy, and integration will be tough no matter the vendor.
The lesson: Give SI a connected view of the business before you ask it to do anything. Integrate what you have, migrate only where the business demands it, and name every source of truth. Only after all that should you start integrating SI into your workflows. The data has to be clean and clear.
Write Down How Your Business Actually Runs
Connecting your systems gives SI something to see. Your processes tell it what to do. Most organizations have never written theirs down. Every enterprise ERP is a blank slate. It doesn’t know how your invoices should flow, who approves a PO, or who can change a bill of materials and at what stage. You have to define that. Put bluntly, if you only half-do the “how should this work” step, you get half-done results.
SI makes this matter more, not less. When a person hits a gap in a process, they stop and ask someone; an agent doesn't. It keeps going faster, at scale. A vague process costs you efficiency. With SI, it can cost you thousands of bad decisions before anyone catches it.
At PACOM, this was the second half of the job. Once the systems were connected, I needed every team to build its processes, procedures, and business rules into those tools. Once a process lived in the system, we could measure it, improve it, and eventually hand pieces of it to an agent.
We did the same thing with our operations and planning process. For years, uniformed personnel told us that building a CONOP was subjective, not objective. The outcome depended on who was in the room. That’s fine for a craft. It’s a problem when you want to measure it, improve it, or hand any part of it to AI, because you can’t automate a process that changes with every person who runs it.
To fix that, we went back to joint doctrine, JP 5-0 for joint planning and JP 3-0 for joint operations, and used it to define the process step by step. Then we tested it against real-world scenarios to make sure it held up outside the textbook. Most importantly, the heads of each section worked directly with us to define their own processes, procedures, and business rules. They knew the work better than anyone, and they had to own the result. Before we changed anything, we got concurrence up the chain of command, all the way to the Joint Staff. That step mattered as much as the design. If leadership hasn’t agreed to a process, it's just a suggestion.
Every company has its own version of this: the forecast that depends on which sales leader built it, or the approval that depends on which manager is out that week. If the answer changes based on who does the work, it isn’t ready for AI. This is where many organizations get it wrong. They treat process work as the “CTO’s” job; it isn’t. The people who run the business must define how it runs. Either your leaders put in the time, or you hire someone who will.
The lesson: Make every team leader responsible for building their process, rules, and approvals into the system. If it isn’t written down, SI can’t follow it, and you can’t measure it.
Define What Good Looks Like Before You Automate
In the Department of War, every order comes with commander’s intent. Commander's intent is what everyone in the Department of War is trying to accomplish and what success looks like. When the plan falls apart, intent lets people still make the right call.
Your AI effort needs the same thing. Before you automate anything, decide what outcome you’re driving and how you’ll know you hit it. I typically boil it down to one question: Does this make production better? Our company exists to order, build, ship, deliver, and sustain great products; everything else after that is window dressing.
That runs against how most companies start. The easy AI wins are in the back office. That means accounting, auditing, reporting, and other tasks that keep the company running. They show savings fast, but they rarely make you more competitive. What has worked for me, and what I advise, is to tell your CFO directly that back-office efficiency isn’t the priority; the product is!
Your question will look different. A retailer might ask whether it gets the right product on the shelf faster. A bank might ask whether it serves customers faster and safer. The point is to have one question and run every SI project through it before funding. To get to the SI of it all, start with the simple, boring integrations before you enable the process with SI.
The lesson: Set your north star from the top and use it to filter every SI project. If a project can’t show how it moves the core mission, it waits.
Benchmark Against Your Own Work, Not Vendor Demos
Vendor demos are built to impress. Clean data, simple tasks, best-case scenario. Your business has none of that. The only benchmark that matters is how a model performs on your work, against your standards.
Once your systems are connected, your processes are written down, and your north star is set, you can finally test properly. At PACOM, we looked at AI adoption as four steps, each building on the last:
Streamline. Cut the unnecessary steps, handoffs, and double data entry.
Automate. Let software take the repetitive, rules-based work.
Optimize. Use the data to find where the process can run faster, cheaper, or with fewer mistakes.
Put an agent on it. Hand SI agents the complex work that would take a person hours or days.
Benchmark every step against how the work gets done today. How long does it take? How often is it wrong? What does it cost? If you can’t answer those for the current process, you’re not ready to automate it. This is how we benchmark our models: we match the best model to the right tasks based on our workforce’s processes, procedures, and business rules. This also keeps you honest. Plenty of processes get most of their value at step one or two, and remember, not everything needs an agent.
The lesson: Measure the human baseline first, then move each process up the ladder only as far as the numbers justify.
Match the Model to the Task
This is the easy part. It’s also where most companies waste money. They pick one powerful model and throw it at everything. That’s like sending your best engineer to reset passwords.
The better approach looks like a well-run staff. A senior planner sets direction and handles the hardest calls. The staff does the research, drafting, and legwork. Nobody expects the senior planner to do it all, and nobody hands the staff the hardest decisions.
SI works the same way. We've used our benchmarks at both PACOM and Shield to do exactly this with our SI code reviewer. A frontier model handles the hardest reasoning and hands lower-level work to a cheaper open-weight model. Because we could measure it, we knew the change wouldn’t hurt quality. In our testing, the new combination outperformed the more expensive setup we had been running, at a lower cost. Better quality and lower cost, at the same time.
The four steps give you a simple way to think about where each model fits:
Streamlining and basic automation usually need simple rules or a small, inexpensive model. The process is already defined. The model just has to follow it.
Optimization often depends more on good data and analytics than on a large language model.
Agents on complex work are where frontier models earn their price, especially when they’re directing cheaper models underneath them.
Open-weight models matter for another reason too. You can run them in your own environment, which gives you more control over sensitive data. For the DoW, and for any company with regulated or proprietary data, that means you can decide what you’re able to use. Your token costs stay low not because you negotiated a better rate, but because you use expensive models only where they make a difference. When a better or cheaper model comes out, you run the benchmark and swap it in within days, not months.
It’s easy because you've already made the hard decisions. Your systems are connected, your processes are defined, and you know what good looks like. Picking a model becomes an engineering call, not a bet.
The lesson: Put your best model on the hardest work, let cheaper models handle the rest, and use your benchmark to prove the mix works before you scale.
Conclusion
The companies that win the SI race with SI won’t be the ones with the best model. Everyone will have access to that. The winners will be the ones who did the unglamorous work first. If you’re leading a mid-size or large organization, connect your systems, write down the “how” of the business, set the north star, measure before you automate, and match/benchmark the model to the task.
Connect your systems. Treat your core platforms as authoritative sources, layer a data platform on top, and assign an owner to every source.
Write down how the business runs. Make each team responsible for building its processes, rules, and approvals into the system.
Set the north star. Set one question from the top that every AI project must answer.
Measure before you automate. Baseline the work as it’s done today, then move it up the ladder: streamline, automate, optimize, agent.
Match the model to the task. Use the cheapest model that meets the benchmark, and save the frontier models for the hard problems.
That’s what worked at PACOM, in one of the most complex organizations in the world, and it’s working here at Shield. I can guarantee that it will work in yours. Get the foundation right, and SI will be easy.