--- title: "The Sovereign Operating Model" slug: "chapter-20-the-sovereign-operating-model" kind: "chapter" order: 21 label: "Chapter 20" chapter: 20 part: "Running It" partLabel: "Part VI" partNumber: 6 epigraph: "Bring us a hard problem. Keep the code." summary: "The previous nineteen chapters described an architecture. This one describes how an institution adopts it: the first pilot, the operating function that grows out of it, and the posture that keeps t…" words: 1075 topics: - "Start with a hard, multi-system problem" - "Engineers embedded, code owned" - "Evaluations before users" - "A budget cap you set" - "The exit you never use" - "The ten-year view" --- The previous nineteen chapters described an architecture. This one describes how an institution adopts it: the first pilot, the operating function that grows out of it, and the posture that keeps the institution in control for a decade. It is the chapter for the CIO who agrees with everything so far and has to decide what to do on Monday. ## Start with a hard, multi-system problem Most AI pilots are designed to succeed, which is why they teach nothing. Fifty volunteers, a chat window, a general-purpose model, no connection to anything the institution actually runs. The pilot succeeds, the report is written, and the institution is no closer to knowing whether the platform can do real work. A sovereign pilot inverts this. Choose a problem that is hard because it spans systems: a question whose answer requires the student information system and the advising platform and the ticketing tool; a process that today involves three departments passing spreadsheets. Connect those systems through the broker. Build the agent and its skills against live data. Put it in front of the people who do the work, on the surfaces where they do it. The pilot that succeeds at a hard, multi-system problem has proven the data layer, the identity layer, the harness and the operating process at once. Syracuse University's first agent did this: it began with the materials that were easy to reach and connected more systems phase by phase, useful from the first week and more useful every week after. The pilot that merely proves the model can chat has proven what everyone already knew. ## Engineers embedded, code owned The sovereign model of professional services is different from the one institutions are used to, and the difference is contractual as well as practical. The vendor's engineers work inside the institution's team on the pilot problem: they build the connectors, shape the ontology, write the first skills and tune the harness alongside the institution's own people. That is forward-deployed engineering, and it is how the institution's staff learn the platform by building on it rather than by reading about it. The contractual difference is that everything built inside the pilot belongs to the institution: the connectors, the skills, the configuration and the agent. There is no separate line for the intellectual property, no clause that keeps the integration work on the vendor's side of the fence. When the pilot ends, the institution holds a working deployment it can run, extend and, if it chooses, run without the vendor. A pilot priced to leave the institution with nothing it can keep is a sales exercise, whatever it is called. ## Evaluations before users Chapter 5 described evaluation sets as the mechanism for switching models safely. In the operating model they do more: they are the gate between building an agent and giving it to people. Every agent carries a set of representative prompts with the properties a good answer must have. Before the agent reaches users, it is run against that set on its intended model, and the results are reviewed by the people who own the process. When the model changes, the set runs again. When a skill is edited, the set runs again. The results live in the platform where an administrator can see them, not in a spreadsheet on someone's laptop. An institution that does this has an answer to the question every board eventually asks, "how do you know it works?", that is better than "people seem to like it." It has a test, a record of the test, and a record of every change since. ## A budget cap you set The financial posture of a sovereign deployment is a cap, not a seat count. Model usage is paid per token, to the providers directly or through the platform's pooled credits, and the institution sets the ceiling. When the ceiling is reached, the platform stops spending; it does not invoice. Open-weight models on the institution's own hardware have no per-token cost at all, so the volume workloads routed there cost electricity. For planning, the arithmetic from Chapter 1 holds. A campus of fourteen thousand that would pay $3.36 million a year per seat spends a small fraction of that on tokens for the same work, and the platform fee that replaces the per-seat contract does not scale with headcount. The budget line becomes predictable in the way a utility bill is predictable: it follows use, it has a cap, and the institution can see where every dollar went, by agent and by model, in the spend view. ## The exit you never use Chapter 4 argued that the only real exit clause is an architecture that makes the exit a fact. The operating model keeps that fact true. Once a quarter, verify the four questions from Chapter 3. Can your engineers build and deploy the platform from source? Is every connector and skill in your own repositories? Can you switch the model on a production agent today? Does the air-gapped build still start? None of these takes more than a day. An institution that can answer yes to all four every quarter is never negotiating from weakness, and in my experience never has to use the exit it has kept open. The leverage is the point. ## The ten-year view A CIO buying a sovereign AI platform is making a decision whose consequences will outlast every model named in this book, most of the vendors in the market, and probably their own tenure. The question to ask is not which product is best this year. It is which architecture the institution will be glad to be standing on in ten, when the models are commodities nobody remembers the names of, the applications have been regenerated a dozen times, and the data has never left. The architecture this book describes is built to be that: code the institution holds, data that stayed in place, models that are settings, one identity across every surface, and agents in a harness the institution can read. Everything else will change. The people I have worked with at ibl.ai are a family-owned company in New York, and we have built the platform this way because we intend to be here for the long run too, as a partner the institution could leave and chooses not to. Bring us a hard problem. Keep the code. That is the whole operating model, and it fits on a page.