Global Advisors built a shared skills library to capture how AI-enabled work should be carried out across the firm. What began as useful instructions for individual assistants developed into a managed capability layer containing operating guidance, deterministic scripts, schemas, validation rules, routing logic and evidence requirements.

The library addresses a practical problem in enterprise AI: a good answer once is not the same as a repeatable organisational capability. To make AI work dependable, the firm had to define how capabilities are discovered, selected, executed, checked, improved and reused across different working environments.

Maturity: implemented and in active internal use, with broad capability coverage and automated repository controls; portability, observational testing and lifecycle discipline continue to develop.

Early AI adoption often produces a collection of promising prompt fragments. One person knows how to prepare for a meeting, another has refined a research workflow, and a third has worked out how to turn analysis into a client-ready document. The knowledge is useful, but it remains tied to a person, conversation or interface.

That pattern creates several problems:

• teams solve the same operating problem repeatedly;
• instructions drift between assistants and users;
• important checks depend on memory rather than the workflow;
• a model may choose an attractive but unsuitable capability;
• integration steps become buried in prose;
• improvements are difficult to test or propagate; and
• changing the underlying AI environment risks losing accumulated know-how.

Global Advisors wanted a durable way to accumulate capability. The goal was to preserve effective working methods as organisational assets while keeping human authority, access rules and business judgement outside the model's discretion.

We designed a canonical library in which each skill is a bounded operating contract. A skill explains when it applies, what inputs it needs, which actions it may take, what evidence it must retain and how completion is verified. Where precision matters, prose is supported by scripts, schemas and tests.

Several design choices shaped the system:

• Shared capability is maintained in one reviewed location instead of being copied into multiple assistants.
• Every new request is assessed against an explicit catalogue, with one primary route selected or a deliberate decision not to route.
• Permissions, approvals, side effects and completion checks remain rule-driven even when a model helps interpret intent.
• Skills and subskills have durable identities, allowing the implementation to evolve without breaking every consumer.
• Complex workflows pass structured tasks and evidence between capabilities instead of relying on ambiguous conversational continuity.
• General working method is separated from assumptions belonging to one assistant or interface.
• Experimental capabilities can mature into the shared canon through review and validation.

Together, these choices made the skills library part of the firm's operating architecture.

The library now supports a wide range of recurring knowledge-work and operating needs, including research, writing, document production, analytical workflows, meeting preparation and review, recruitment, finance, productivity, knowledge ingestion and the evolution of the library itself.

The implementation includes:

• a structured catalogue for discovering the appropriate capability;
• concise entry instructions with deeper references loaded only when needed;
• deterministic helpers for operations that should not depend on generated prose;
• shared schemas and definitions for consistent inputs and outputs;
• composition rules for parent and child capabilities;
• negative routing examples to prevent plausible but incorrect selection;
• checklists for workflows whose cost, risk or length makes silent omission likely;
• correlation identifiers and evidence ledgers for multi-stage work;
• read-back requirements after important external changes;
• tests for structure, references, routes and behavioural assertions;
• a distinction between local experimentation and reviewed shared capability; and
• repository standards requiring documentation and handover to change with the implementation.

At the time of this study, the canonical repository contained more than 180 skills and over 500 automated validator runs completed without failure. More than 250 routing assertions had been evaluated, including positive cases, exclusions and boundary tests. These figures are useful evidence of scale, but they do not imply that every possible real-world behaviour has been observed. The test model explicitly distinguishes deterministic validation from assertions that require live observation.

Portability requires deliberate separation

Useful methods easily become entangled with the commands, paths and assumptions of one runtime. We separated reusable method from environment-specific execution and treated adapters as replaceable. This allows the operating knowledge to survive changes in models, interfaces and orchestration tools.

Quality cannot be inferred from catalogue size

A large count can conceal duplication, stale instructions and untested routes. We built compliance checks around required structure, references, scripts, evaluation cases and routing behaviour. We also retained an honest category for claims that require observation rather than pretending a static validator proves live performance.

The library must be able to improve itself safely

The people and agents using a capability are often the first to find its weaknesses. We established a controlled evolution path: capture evidence, identify whether the issue is local or shared, change the canonical source, run validation and record the handover. This converts operating experience into reusable improvement without allowing every session to rewrite the rules informally.

• Reviewed, versioned capability definitions;
• explicit applicability and exclusion rules;
• one primary route for each current request;
• deterministic approval, permission and side-effect gates;
• structured inputs, outputs and cross-capability hand-offs;
• checklist and evidence ledgers for consequential workflows;
• automated structural, reference and routing validation;
• read-back after material external changes;
• separation of experimental and canonical capability; and
• change records that state what was tested and what remains observational.