Before the AIPS Framework can do anything useful, a strategy has to exist — and not every document called "strategy" qualifies. This article catalogues what counts as a working strategy in this context, and the cascade of artefacts that turns abstract intent into something granular enough to encode into AI skills.

Many definitions, one shared discipline

The strategy field has no single definition. Mintzberg's Ten Schools of Strategy catalogues ten schools, each with its own vocabulary; Schools of Strategy surveys the wider landscape. But the operational test of whether a document is actually a strategy is more invariant than the definitions suggest. It must:

1. Imply trade-offs — name what the firm has chosen not to do.
2. Pass an evaluation test. The earliest published checklist is Tilles's six criteria (1963): internal consistency, consistency with the environment, appropriateness of resources, satisfactory degree of risk, appropriate time horizon, and workability.^[1] These were tightened by Rumelt's four tests and elaborated by McKinsey's ten.
3. Rest on an explicit theory of the business. Drucker's 1994 formulation: the assumptions about environment, mission, and core competencies must fit reality, fit each other, be known throughout the organisation, and be tested constantly.^[2] See Drucker — The Theory of the Business.
4. Contain commitments, not only postures. Ghemawat: reversibility is the universal solvent of competitive advantage; a strategy whose moves can all be undone in a quarter is operationally interesting and strategically void.^[3] See Commitment — The Dynamic of Strategy.

A strategy you can analyse with the strategy checker passes these tests; the full list of 27 criteria is the operational form of "what counts as a strategy".

A skill is the operational form of strategy in the AIPS Framework. It is a small, named package — system prompt, checklist, optional reference document — that an AI assistant pulls in when a relevant task comes up. This article describes the mechanism and the failure modes worth knowing about before you write your first ten.

How a skill works

The technical mechanism is simple. Each skill has a name, a description / trigger condition, and a body (the system prompt, plus any reference material). When the AI assistant is given a task, it considers the available skills, picks the relevant ones based on the description, and uses the body to shape its reply.

For Claude in particular, skills can be published organisation-wide. Every team member's Claude has access to the same set automatically. Updates propagate instantly. The deployment model is closer to software than to training: you ship a new version, not a new workshop.

A well-written skill has four parts:

With skills deployed (Step 1) and instrumented to declare themselves, the next move is to turn the conversation log stream into something queryable. This article covers what Anthropic provides on Team and Enterprise plans, what you need to build on top, and what to look for once it's running.

What Anthropic Team and Enterprise plans give you

Both Team and Enterprise plans give admins programmatic access to the organisation's conversation logs. The shape of the data — at the time of writing — is broadly:

• Conversation metadata. ID, timestamp, participant, project (when used), model version.
• Message stream. Prompts and replies, in order, with tool calls and skill activations annotated.
• Skill annotations. When a skill activates, it can be configured to include a structured note in the reply. This is where the "skill: pricing-decisions applied" marker shows up, and where a reason field can be captured.

Enterprise plans add SSO, audit logs, finer-grained role-based access, and (depending on the negotiated terms) better export tooling. For the framework, the minimum is reliable programmatic access to the message stream with skill annotations preserved.

When strategy becomes measurable, it immediately becomes an object of change. This is, in many ways, the whole point of the AIPS Framework — not the skills and not the logs, but the feedback loop they enable.

The asymmetry of visibility

Until recently, the dominant signal about whether a strategy was working was revenue, twelve to eighteen months out. Strategies that were silently wrong stayed silently wrong for a long time. Strategies that were quietly right got attributed to other things. The relationship between strategy and outcome was so noisy that most strategy reviews were exercises in narrative — telling a story that matched the numbers, after the fact.

With skills and logs, the signal moves earlier and gets richer:

• Per-decision evidence, not per-quarter aggregate.
• Pattern visibility, not vivid-anecdote bias (see cognitive biases in strategy formulation).
• Actionable resolution: when something is off, you can usually point at which skill, which decision class, which part of the strategy.

AIPS is a framework in active development, and its strongest critics have not been outsiders to AI but practitioners who agree with the underlying motivation. The complaint is rarely that the idea is wrong — it is that the rhetoric outruns the mechanism, and that several preconditions, mechanics, and political realities deserve more attention than v0.2 currently gives them.

Preconditions

The "AI maturity" precondition does most of the heavy lifting

AIPS requires that "most daily decisions are already being made with the help of AI assistants." In practice this collapses into a stronger requirement: most daily decisions are made with one AI assistant whose logs the organisation owns. Few mid-sized companies meet this bar today. Engineering uses Cursor; sales has Gong; marketing has Jasper or its replacement of the month; finance and legal often don't use AI at all; executive assistants are heavy Claude users. The logs available to AIPS are therefore a biased sample of a biased sample — usually skewed toward the functions that adopted the assistant earliest, which are rarely the functions whose decisions move the strategy.

This is not a fatal objection — the framework can be operated on a partial dataset — but it should make any conclusions drawn from the logs locally scoped. See Requirements to the Strategy and Operating Model Design for the surrounding considerations.