The book is the unit of design
The GTM edition of this bookshelf is built for the commercial engine. This edition is the whole organisation: founding intent, governance, strategy, management, execution, knowledge, agent capabilities, systems and infrastructure. It exists because an agent that is useful in Sales will sooner or later touch finance, procurement, people operations or a system nobody in GTM owns — and the question "who may decide this?" has to have an answer there too.
A book can be a charter, a policy, a playbook, a workflow, a register, a data contract or an enforced control. Each has an accountable owner and an approved scope. Agents draw from several shelves for a task; knowledge, governance, security and learning connect the whole bookcase. Every book carries six fields:
Purpose & scope
What this book governs, when it applies, and what it excludes.
Accountable owner
Who maintains it, approves changes, and resolves ambiguity.
Authority & permissions
Who can read, propose, approve, execute, or override.
Version & review
Which edition is approved, when it takes effect, and when it needs review.
Sources & dependencies
Canonical evidence, linked books, systems, and conflict-resolution rules.
Acceptance & controls
How quality is checked and which limits are enforced in software.
Intent & authority ↓
- Purpose and boundaries shape decisions and work.
- Founding intent interprets goals; Governance turns rules into permissions; Strategy allocates; Management assigns owners; Execution moves work to an accepted result.
Evidence & learning ↑
- Results inform reviews and proposed changes.
- Knowledge keeps what is trusted; Agent capabilities evaluate before autonomy widens; Systems and Infrastructure make limits real in software.
Instructions alone do not enforce authority. A rule that is not translated into a permission, an approval gate or an enforceable limit is a hope — and the agent will eventually act on the hope.
9 shelves, one question each
Each shelf answers one question and carries one rule for how agents use it — that rule is what turns a document into a boundary. Read down for intent and authority; read up for evidence and learning.
| Shelf | The question it answers | How agents use it | Books |
|---|---|---|---|
| 01 · Founding | Why do we exist, and what value should this organization create? | Use founding intent to interpret goals. Founding changes stay with accountable leadership. | 6 |
| 02 · Governance | Who may decide what, within which boundaries? | Translate rules into permissions, approval gates, and enforceable limits. Instructions alone do not enforce authority. | 6 |
| 03 · Strategy | Where will we compete, and how will we allocate scarce resources? | Plan and recommend within approved strategic choices and budgets; route changes to the relevant decision owner. | 6 |
| 04 · Management | Who owns outcomes, and how is the organization coordinated? | Assign explicit human accountability and bounded agent mandates. Review outcomes, capacity, cost, and exceptions. | 6 |
| 05 · Execution | How does work move from a request to an accepted result? | Work through explicit triggers, inputs, permitted actions, acceptance criteria, and escalation paths. | 6 |
| 06 · Knowledge & memory | What do we know, what is trusted, and what must be remembered? | Retrieve the relevant approved context with provenance and access controls. Separate evidence, assumptions, and instructions. | 6 |
| 07 · Agent capabilities | How do agents reason, act, get evaluated, and improve? | Bind capabilities to role authority and approved tools. Evaluate proposed changes before expanding autonomy or releasing updates. | 6 |
| 08 · Integration & systems | How do business applications, agents, and data connect? | Expose typed, authorized interfaces. Reconcile system changes and design repeated actions to avoid duplicate effects. | 6 |
| 09 · Infrastructure | Where does everything run, persist, and receive technical protection? | Enforce scoped access, budgets, isolation, recovery, and operational visibility in the runtime itself. | 6 |
Founding
Why do we exist, and what value should this organization create?
Use founding intent to interpret goals. Founding changes stay with accountable leadership.
Purpose
The enduring reason the organization deserves to exist.
A one-page purpose statement.Mission & vision
What we do today, for whom, and the future we are trying to create.
A mission statement and a concrete future-state narrative.Customer promise
The outcome customers should reliably receive and the experience we commit to.
A customer promise with explicit boundaries.Business model
How value is created, delivered, and captured; who pays and why.
A business model map with revenue and cost drivers.Values & identity
The principles that guide trade-offs and define the organization's character.
Values illustrated with real decision examples.Stakeholders
Whose interests matter, who is accountable, and which commitments shape the organization.
A stakeholder and commitment map.Governance
Who may decide what, within which boundaries?
Translate rules into permissions, approval gates, and enforceable limits. Instructions alone do not enforce authority.
Decision rights
Which decisions belong to owners, leaders, teams, or agents, and who is accountable.
A decision-rights matrix.Codes of conduct
Expected behavior toward customers, colleagues, partners, and other stakeholders.
A code of conduct with concrete examples.Autonomy boundaries
Where an agent may observe, recommend, draft, act with approval, or act independently.
An authority matrix by action, scope, and risk.Approvals & escalation
When work must pause, who resolves exceptions, and how humans can intervene.
An approval and escalation map with stop conditions.Risk & assurance
How risks, privacy obligations, policy conflicts, and incidents are reviewed.
A control register with owners and evidence requirements.Procurement rules
Vendor selection criteria, purchasing authority, spending limits, and exceptions.
A procurement and spending policy.Strategy
Where will we compete, and how will we allocate scarce resources?
Plan and recommend within approved strategic choices and budgets; route changes to the relevant decision owner.
Markets & positioning
The customers, problems, markets, and alternatives we choose to compete around.
An ideal customer and positioning brief.Strategic bets
The few choices and assumptions expected to produce an advantage.
A strategy memo with bets, exclusions, and assumptions.Goals & outcomes
The results to achieve, their definitions, targets, and time horizons.
An outcome tree and metric contracts.Financial strategy
Revenue logic, unit economics, capital allocation, runway assumptions, and financial constraints.
A financial model with explicit assumptions and limits.Portfolio & roadmaps
How initiatives are sequenced, funded, compared, stopped, or expanded.
A prioritized portfolio and outcome-based roadmap.Sourcing & partners
Which capabilities to build, buy, partner for, or keep under direct control.
A build-buy-partner decision map.Management
Who owns outcomes, and how is the organization coordinated?
Assign explicit human accountability and bounded agent mandates. Review outcomes, capacity, cost, and exceptions.
Org & capability map
Departments, teams, capabilities, and the relationships between human and agent contributors.
An organization map connected to a capability map.Roles & mandates
The purpose, responsibilities, authority, and limits of each human or agent role.
Role charters covering inputs, outputs, and authority.Outcome ownership
One accountable owner for an outcome, process, metric, system, or agent.
An ownership register with escalation contacts.Cadences & planning
The recurring cycles for planning, allocation, review, coordination, and improvement.
An operating calendar with required inputs and decisions.Reporting & monitoring
Which business results, operational signals, agent behaviors, and exceptions are reviewed by whom.
A management scorecard with alert and action thresholds.Capacity & dependencies
Available people, agent capacity, operating budgets, bottlenecks, and inter-team dependencies.
A capacity and dependency board.Execution
How does work move from a request to an accepted result?
Work through explicit triggers, inputs, permitted actions, acceptance criteria, and escalation paths.
Value streams
The complete journeys that deliver value: acquire-to-renew, hire-to-onboard, or procure-to-pay.
A value-stream map with customer and business outcomes.Processes & SOPs
Repeatable steps for sales, service, finance, procurement, people operations, and other functions.
A process card with trigger, owner, steps, and outputs.Playbooks & workflows
Guidance for variable situations and executable flows for repeatable work.
A playbook linked to its corresponding workflow.Handoffs & promises
What another team or agent receives, in what format, by when, and with which acceptance rules.
A handoff contract covering inputs, outputs, and service levels.Quality & acceptance
How a deliverable is checked and who or what can accept it as complete.
A definition of done and a quality checklist.Exceptions & recovery
What happens when data is missing, a tool fails, policy blocks action, or a result must be reversed.
An exception runbook with retry, rollback, and escalation rules.Knowledge & memory
What do we know, what is trusted, and what must be remembered?
Retrieve the relevant approved context with provenance and access controls. Separate evidence, assumptions, and instructions.
Shared definitions
The common meaning of customers, stages, revenue, success, risk, and other business terms.
A glossary and versioned metric dictionary.Trusted facts
Which records and sources are authoritative, how current they are, and who maintains them.
A source-of-truth register and freshness rules.Domain context
The product, market, customer, and operating context needed to interpret a task.
Curated domain briefs linked to approved policies.Decision memory
What was decided, by whom, based on which evidence, and what could trigger reconsideration.
A decision log with rationale and review conditions.Evidence & provenance
The traceable link from a claim or output to the records and sources supporting it.
An evidence catalogue with source and timestamp fields.Knowledge lifecycle
How context is approved, versioned, scoped, refreshed, archived, and removed.
A knowledge lifecycle policy and content ownership map.Agent capabilities
How do agents reason, act, get evaluated, and improve?
Bind capabilities to role authority and approved tools. Evaluate proposed changes before expanding autonomy or releasing updates.
Skills & instructions
Reusable procedures, task instructions, and tool-use patterns for particular kinds of work.
A versioned skill catalogue with prerequisites and limits.Planning & coordination
How tasks are decomposed, assigned, checkpointed, and coordinated within a mandate.
A planning and coordination specification.Model selection
Which model or reasoning approach is suitable for a task's quality, cost, and latency needs.
A model selection policy with fallback rules.Evaluations
How quality, policy adherence, tool behavior, and business usefulness are checked.
Representative evaluation cases and release thresholds.Feedback & learning
How results, corrections, and failures become proposed improvements with evidence.
A feedback log and controlled improvement loop.Agent lifecycle
How an agent is registered, configured, released, monitored, paused, rolled back, and retired.
An agent registry linked to owners and release records.Integration & systems
How do business applications, agents, and data connect?
Expose typed, authorized interfaces. Reconcile system changes and design repeated actions to avoid duplicate effects.
Business applications
CRM, finance, support, HR, and other systems that hold records or perform business operations.
A system catalogue with owners and authoritative records.Tools & connectors
The approved capabilities agents can call, their effects, and their required permissions.
A tool catalogue with input, output, and permission contracts.APIs & endpoints
The interfaces through which systems read, write, or trigger actions.
An interface register with ownership and versioning.Events & data contracts
The meaning and structure of events and data passed between systems.
Versioned event schemas and data contracts.Identity & record mapping
How the same customer, company, user, or object is recognized across systems.
A canonical identifier and field mapping specification.Sync & reconciliation
How changes propagate, conflicts are resolved, and systems converge after failure.
A sync policy with reconciliation and duplicate-prevention rules.Infrastructure
Where does everything run, persist, and receive technical protection?
Enforce scoped access, budgets, isolation, recovery, and operational visibility in the runtime itself.
Compute & runtimes
The environments that execute software and agents, including scheduled and long-running work.
A runtime map with capacity and environment boundaries.Storage & indexes
Where records, documents, files, logs, and retrieval indexes physically persist.
A storage map with retention and access classifications.Identity & access
The service identities, authentication, authorization, and least-privilege access behind actions.
An access model linking roles to actual permissions.Secrets & network
How credentials, connectivity, isolation, and endpoint access are managed.
A secrets and network boundary map.Telemetry & costs
The technical logs, traces, runtime metrics, usage limits, and cost signals operators need.
An observability and cost-control configuration.Backups & recovery
How data and service are restored, incidents contained, and recovery validated.
A tested backup and recovery runbook.How the loop works
Approved intent and rules guide work. Actions produce results and evidence. Reviews turn that evidence into proposed changes, which follow the decision rights and controls set by Governance. Nothing on the lower shelves may rewrite an upper shelf on its own — it proposes, with evidence, to the owner named on that shelf.
Start with one book per shelf that a real task touches
- Pick a task an agent already does or should do — a procurement request, a customer reply, a monthly close step — and write down which shelves it touches. Usually five or six.
- Create the first artifact for each touched book using the suggested filename. One page each. Name the owner in the first line.
- Give the task the smallest autonomy that is useful, translate the boundary into an actual permission or approval gate, and run it on real cases before widening anything.
Where the familiar items live
Most organisations already have a mission, a code of conduct, a finance function, a procurement policy, an org chart, monitoring and storage. They do not disappear; they are split so that the intent, the rule, the choice and the transaction each have an owner.
| Starting item | Placement in this model | Reason |
|---|---|---|
| Mission & vision | Founding | They express enduring intent; strategy describes choices for achieving it. |
| Codes of conduct | Governance | They set behavioural boundaries for decisions and execution. |
| Finance | Strategy → Management → Execution | Financial direction, operating budgets and transactions need distinct artifacts. Spending authority sits in Governance. |
| Procurement | Strategy → Governance → Execution | Separate sourcing choices, purchasing rules and the procure-to-pay process. |
| Roles & departments | Management; connected to Execution | The organisation assigns ownership and mandates; processes describe the work. |
| Monitoring | Management, Agent capabilities, Infrastructure | Business performance, agent evaluations and runtime telemetry answer different questions. |
| Storage | Infrastructure; connected to Knowledge | Storage holds bytes and records. Knowledge defines meaning, authority, freshness and appropriate use. |
| Tools & endpoints | Integration & systems | These expose capabilities. Runtime access, secrets and network controls sit in Infrastructure. |
How to use it — and what it is not
- Not an org chart. Departments and teams appear on the Management shelf; the bookcase is about what has to be written down for people and agents to act.
- Not a tool recommendation. Business applications, connectors and runtimes are catalogued, never chosen, by the framework.
- Not fifty-four documents on day one. One task, the five or six shelves it touches, one page per book.
- A v0.1. The shelf rules are the stable part; expect book titles to move as real organisations use it.
The Agentic Organisation Bookshelf, working framework v0.1 — Revenue Puzzles. Sibling editions: the GTM edition (nine shelves, sixty-six books, three execution lanes) and the Product edition (twelve shelves, eighty books, agents in the team and in the product). The book cards and the complete guide are generated from the same list, so the three stay in step.
The first session is one task and the shelves it touches, not a tool. Tell me what is going on and I will say which books come first.