Eight Principles
The rules that hold no matter which AI wins
Eight Principles
Technology choices will change every few months. These principles shouldn't.
1. Model before you automate
An agent is only as good as its understanding of why the work exists. Before you automate a job, make sure the strategy, money, ownership and rules around it are on a model the agent can read. Automating a job you can't describe just makes the confusion faster.
2. One model, many surfaces
Let people choose their interface — an assistant, a chat tool, an app — but make every interface read the same model. If two AI tools can give two different answers to "what's our committed spend on this initiative?", you don't have a headless enterprise; you have more silos.
3. Broad context, narrow skills
Give agents the whole operating model to read, and narrow, well-described jobs to do. The programs that produce returns start with a handful of specific jobs, not a mandate to "transform everything".
4. People own decisions
Agents prepare decisions: they gather the evidence, draft the options, explain the tradeoff and route it to the right person. People make the call. Write down which decisions belong to whom before an agent ever proposes one.
5. Every agent acts as someone
No agent should have more authority than a person who could be held accountable for its actions. At minimum, an agent acts within a named person's permissions. As identity standards mature, give agents their own identities with delegated, scoped and time-bound access — never a shared superuser.
6. Meter every action
If an agent takes an action, you should be able to say what it cost, which team and outcome it served, and who approved it. Per-action economics make this a finance discipline, not an IT afterthought.
7. Count value only with evidence
Planned value is a hypothesis. Count AI's return only when the link to an outcome and the measurement behind it are both in place. This keeps the program honest — and keeps it funded.
8. Design for the next version
Frameworks, regulations, models and vendors will all change. Keep your operating model your own, keep it portable, and make changing it a routine motion rather than a migration project.