---
title: "A 90-Day Sovereign Pilot Plan"
slug: "appendix-f-a-90-day-sovereign-pilot-plan"
kind: "appendix"
order: 28
label: "Appendix F"
letter: "F"
summary: "A week-by-week plan for an institution at Level 1 or 2 in Appendix A to reach Level 3 with one working, governed, multi-system agent in production. It assumes a sovereign platform deployed from sou…"
words: 949
---

A week-by-week plan for an institution at Level 1 or 2 in Appendix A to reach Level 3 with one working, governed, multi-system agent in production. It assumes a sovereign platform deployed from source into the institution's own cloud account, a vendor engineering team embedded with the institution's, and a hard problem chosen in advance. The plan is deliberately front-loaded with decisions, because the decisions are what take time; the engineering is faster than most institutions expect.

## Before day one

- **Choose the problem.** One process that spans at least two systems of record and that real people do every week. Write down what "better" would mean in a sentence a department head would sign.
- **Name the owners.** A CIO sponsor, a process owner from the department, an engineering lead, a security lead, and the vendor's embedded engineers.
- **Settle the contract.** Source under perpetual license; everything built in the pilot owned by the institution; model providers paid directly or through capped credits; no per-seat line.
- **Pick the deployment tier.** For the pilot, the institution's own cloud account.

## Weeks 1 to 2: Deploy and sign in

- Deploy the platform from source into the institution's cloud account, by the institution's engineers with the vendor beside them. Record the steps; they are the beginning of the runbook.
- Connect institutional single sign-on. Verify roles and organization scoping with three real users of different roles.
- Configure two commercial model providers and set a spend cap. Confirm the spend view shows tokens by agent.
- Run the four exit questions from Chapter 3 as a baseline. Two will be yes already; write down the other two as the pilot's structural goals.

**Milestone:** a signed-in user can chat with a default agent on the institution's own deployment, with a visible cost.

## Weeks 3 to 4: The first connector and the broker

- Stand up the broker inside the institution's account, empty policy, deny by default.
- Connect the first system of record through a Model Context Protocol connector, running in the institution's account, with its credential in the broker's secret store.
- Write the first policy rows: one role, read scope "own" or "caseload," no writes.
- Build the pilot agent with that connector and a first skill written by the process owner in plain language.
- Verify the audit log shows every call with user, role, tool and decision.

**Milestone:** the agent answers a real question from live data, as the asking user, and the call is in the log.

## Weeks 5 to 6: The second system and the ontology

- Connect the second system of record. Define the three or four concepts the pilot needs in the ontology and map them to the two connectors.
- Extend the skill to use both systems. Add the identity-resolution rule that links the person across them.
- Write the evaluation set: thirty to fifty real prompts with the properties of a good answer, graded by the process owner.
- Run the evaluation on both configured models. Record the results in the platform.

**Milestone:** the agent completes the multi-system task; the evaluation set exists and has been run.

## Weeks 7 to 8: Surfaces and memory

- Put the agent where the work happens: the browser side panel for the process owner's team, the desktop application for anyone who wants it, an embed on the relevant internal page.
- Turn on memory with the three scopes; have two users verify they can see and switch off their own.
- Write the agent's shared memory: the standing facts and rules the process depends on, by the process owner.
- Set the approval mode to ask-first for any write tool, and add the first write tool if the process needs one.

**Milestone:** the team uses the agent from the side panel in their daily work; memory and approvals are visible and governed.

## Weeks 9 to 10: Governance and the local model

- Add a classification tag to the restricted connector's results and a routing rule confining them to an approved model.
- Stand up one open-weight model on a team-tier machine or a cloud GPU; add it to the router as the restricted target and as the fallback.
- Re-run the evaluation set on the local model; record the difference.
- Attempt to violate a policy from the chat window, twelve ways; confirm the broker, not the model, refused, and that the attempts are in the log.

**Milestone:** restricted data never leaves the institution's infrastructure, and the attempt to make it leave is on record.

## Weeks 11 to 12: Operate and verify

- Hand the runbook to the institution's team. Perform one deployment of a platform update end to end without vendor hands on keyboards.
- Re-run the four exit questions. Three or four should now be yes.
- Score Appendix B for the pilot estate. Set the target for the next quarter.
- Present to the sponsor: the sentence from before day one, with the evidence: usage, evaluation results, cost by model, the audit log, the exit verification.

**Milestone:** Level 3 in Appendix A for the pilot, with a documented path to extending it across the estate.

## What the plan does not include

It does not include a data migration, because there is none. It does not include a security review of a new authentication system, because the pilot reused the institution's. It does not include a procurement cycle for hardware, because the local model runs on a team-tier machine or a rented GPU for the pilot. Each of those is a quarter in a conventional plan, and their absence is why ninety days is realistic.