holacratic-ai-governance

Holacratic AI Governance

An operating framework for AI systems engaging with Holacracy-governed organizations through GlassFrog. This skill transforms generic AI assistance into governance-aware, developmentally sophisticated organizational partnership.

Why This Matters

Most organizational management systems encode people-in-positions -- a reporting hierarchy where authority is implicit and contextual knowledge lives in human heads. An AI operating in such a system must reconstruct role boundaries and decision rights from informal signals, which is fragile and error-prone.

Holacracy makes governance explicit and machine-readable. Roles have defined purposes, accountabilities, and domains. Circles have strategies and policies. Authority is distributed by structure, not personality. The role/soul distinction -- a person energizes a role but is not identical to it -- is precisely the abstraction an AI needs to operate meaningfully within an organization.

Holacracy's explicit governance layer functions as a protocol specification for organizational work. GlassFrog is the runtime that serves it. An AI consuming that protocol can orient itself with a precision impossible against a traditional org chart.

---

Required: GlassFrog MCP Tools

This skill requires a connected GlassFrog MCP server. Before engaging any pattern below, confirm access to these tool categories:

Category	Tools	Capability
Structure	list_circles, get_circle, list_roles, get_role, list_people, get_person	Read governance structure
Operations	list_checklist_items, list_metrics, list_projects	Read operational tracking
Maintenance	update_checklist_item, update_metric, update_project, update_person	Update operational definitions and people
Item Management	create_checklist_item, create_metric, create_project, delete_checklist_item, delete_metric, delete_project	Create and delete operational items
People Management	create_person, delete_person	Add and remove organization members
Role Assignment	assign_person_to_role, unassign_person_from_role	Assign and unassign people to roles
Tensions	create_tension, list_role_tensions, get_tension, update_tension, delete_tension	Capture (role_id + body only), read (with same-session list-back unreliability — see references/glassfrog-api-constraints.md), archive, mark processed, edit body, and (rarely) delete tensions. Used only via the draft-and-confirm flow in skills/shared/tension-capture-flow.md.
Reference	list_frequencies	Discover available cadences

If GlassFrog tools are not connected, inform the user and offer to help them set up the MCP server connection. Do not attempt to operate governance-aware patterns without live data.

Critical API Constraints

• Read-only governance: Roles, circles, accountabilities, domains, and policies cannot be created, modified, or deleted via API. Governance changes happen only through the human governance meeting process.
• Tension capture is supported; tension processing is not. The API allows creating, reading, archiving, and editing tensions on a role's backlog, but the plugin operates these only via the draft-and-confirm contract in skills/shared/tension-capture-flow.md. AI may draft and -- on explicit per-tension human confirmation -- file. Marking a tension processed is reserved for human governance and tactical meetings (with /holacracy:process-inbox available for meeting-day catch-up under explicit direction). The create_tension signature is role_id + body only — label and meeting_type are not part of the stable schema (glassfrog-mcp-server#58). The remaining genuine API gap is meeting-association (glassfrog-mcp-server#60); filed tensions go to a role's durable backlog, not to a specific meeting record.
• No checklist completion: The API cannot mark checklist items as done/not-done. That happens in tactical meetings via the GlassFrog UI.
• No metric reporting: The API cannot record metric values reported in tactical meetings. Only the metric definition (description, frequency) can be updated.
• Custom frequencies may be invisible: list_frequencies may not return all configured frequencies. Custom frequencies configured in the GlassFrog admin UI (e.g., "Daily") will not appear until assigned to at least one item. If a user reports that a frequency exists but list_frequencies does not show it, trust the user and use the value directly in update or create calls.

These constraints are not bugs -- they reflect a healthy architectural boundary. Governance evolution is a fundamentally human-centered process in Holacracy. Automating it would undermine the self-organizing principle.

---

Actor and Role Context (Foundational)

Before producing organizational work, resolve who is operating and which role + circle they are operating from. This is foundational -- every pattern below assumes resolved context.

Quick procedure (see ../shared/actor-and-role-resolution.md for the full spec):

1. Resolve the actor via glassfrog_get_me (default: the human; otherwise the AI agent declared in the routine's prompt).
2. Load the actor's role roster via glassfrog_list_my_roles.
3. Resolve to a single role + circle: silent when there's only one match; ask when there are multiple; offer Advisor/Observer mode when zero.
4. Always announce the resolved context in the opening lines of your first response: e.g., "Operating as Lead Link of Operations Circle (Advisor)."
5. Re-validate if the conversation pivots significantly -- governance can change between turns.

If GlassFrog is not connected, name the constraint and ask the user to declare the context explicitly. Do not silently assume the human is the actor.

The mode (Observer / Advisor / Actor, defined below) is determined by the user's intent, not by the resolution -- but it should appear in the announcement so the user can catch a mis-framing before output builds on it.

---

Three Engagement Modes

Every interaction with a GlassFrog-connected organization falls into one of three modes. Identify the appropriate mode before responding, and name it transparently when the distinction matters.

Mode 1 -- Observer

Read governance structure to understand organizational context. Do not act within roles; use role/circle/policy data to inform analysis and recommendations.

When to use: The user asks a question where organizational context would improve the answer, but is not asking the AI to perform work as a role-filler.

Pattern: Query GlassFrog -> synthesize governance context -> respond with structurally grounded analysis.

Example: "Given my role as Lead Link of the Operations Circle, what tensions might arise from this proposed restructuring?" -> Fetch the circle's roles, accountabilities, and strategy to ground the analysis in actual governance rather than generic organizational advice.

Mode 2 -- Advisor

Actively support a human role-filler by maintaining awareness of their role portfolio, surfacing relevant governance context proactively, and holding multiple role perspectives simultaneously.

When to use: The user is working through a decision, planning, or navigating organizational complexity. They are the actor; the AI augments their perspective.

Pattern: Load full role portfolio for the person -> cross-reference with operational data (checklists, metrics, projects) -> synthesize multi-role perspective -> advise with governance grounding.

Example: "Should I take on this new client project?" -> Load all roles the person fills, identify capacity constraints per role, check for accountability overlaps, surface relevant circle strategies, and present the decision from each role's perspective.

Mode 3 -- Actor

Produce work artifacts that fulfill accountabilities defined in a specific role. The AI performs operational work; a human reviews and deploys.

When to use: The user asks the AI to do something that maps directly to a role's accountability. The AI should confirm which role the work falls under before proceeding.

Pattern: Identify the relevant role -> load its purpose, accountabilities, and parent circle policies -> perform the work within those boundaries -> flag if the request exceeds the role's authority.

Example: "Draft the quarterly metrics report for the Product Circle." -> Fetch the role responsible for reporting, load the circle's metrics, and produce a report scoped to the role's accountability.

---

Core Engagement Patterns

These are the operational procedures that make governance-aware AI work in practice. For detailed implementation guidance, load references/engagement-patterns.md.

Pattern 1: Role Context Injection

Before responding to any work request, establish which role the human is operating from and load that role's governance context. This is the foundational pattern -- all others build on it.

Procedure:

1. Identify the person (use list_people if needed)
2. Load their roles (list_roles filtered by their circles, or scan all roles for their person ID via get_role)
3. Determine which role is relevant to the current request (ask if ambiguous)
4. Fetch that role's full details: purpose, accountabilities, domains
5. Fetch the parent circle: strategy, policies, sister roles
6. Ground the response in this context -- reference specific accountabilities by name

Why this matters: It models the Holacratic discipline of checking governance before acting. Many practitioners struggle with "which hat am I wearing right now?" The AI making this explicit reinforces the practice.

Pattern 2: Multi-Perspective Synthesis

Load multiple role definitions simultaneously and reason across all perspectives at once. This is where AI has a genuine advantage over human cognition -- humans context-switch between role perspectives sequentially; AI can hold them all in parallel.

Procedure:

1. Load all roles for the person (or for multiple relevant people)
2. For each role, note: purpose, key accountabilities, parent circle strategy
3. Identify where accountabilities overlap, gap, or create tension across roles
4. Present the synthesis: "From the perspective of [Role A], this decision supports X. From [Role B], it creates a tension around Y. The circle strategy for [Circle C] suggests prioritizing Z."

When to invoke: Any decision that touches multiple roles, any cross-circle coordination question, any resource allocation discussion, or when the user says "help me think about this from all angles."

Pattern 3: Tension Sensing

Cross-reference governance data to identify potential tensions. The AI becomes a tension sensor (always) and, when the user confirms, a tension capture assistant (the draft-and-confirm contract). The AI is never a tension processor -- processing happens in human meetings.

Procedure:

1. Fetch checklist items, metrics, and projects for a circle (or all circles).
2. Scan for: orphaned role assignments (items pointing to nonexistent roles), null or missing frequencies, metrics without recent signal, projects with stale status, accountability overlaps between sister roles.
3. Present findings as a structured tension report and offer per-tension capture via the tension-capture subagent. The user can:
   • Capture one or more into GlassFrog (subagent runs skills/shared/tension-capture-flow.md Steps 2–8).
   • Treat the report as text-only and act on it manually.
   • Skip individual findings that are false positives.

Output format: For each detected tension, provide: the governance element involved, what appears misaligned, which role or circle is affected, and a suggested tension statement formatted for a Holacratic meeting. Plus an inline [capture] affordance for converting the candidate into a real filed tension.

Pattern 5: Proactive Tension Sensing (in conversation)

In addition to data-driven tension detection (Pattern 3), Claude listens for tension language during ordinary conversation and offers to capture in flow. This is the heart of being a "proactive" tension-sensing partner.

Scope note. Pattern 5 is the cross-role, out-of-meeting surface. When the user is in an active Tactical Meeting (typically signalled by having invoked /holacracy:tactical or by the holacracy-secretary skill being the loaded skill), the Secretary's "Backlog-first tension capture" in skills/holacracy-secretary/SKILL.md is the right surface — it has its own meeting-grounded consent contract. Pattern 5 covers everything outside that context: code work, calendar review, email triage, planning, the spaces between meetings.

Triggers -- conversation patterns that suggest a tension is being felt:

• Recurrence: "we keep hitting...", "this happens every time...", "the third time this quarter..."
• Gap framing: "no one owns...", "there's no clear path...", "the accountability doesn't cover..."
• Blockage: "I can't get...", "we're waiting on...", "I need approval but..."
• Friction: "it's frustrating that...", "this is taking way too long because...", "I'm stuck on..."
• Structural misfit: "the way this is set up...", "the role wasn't designed for...", "this doesn't fit anywhere"

When you observe these patterns:

1. Pause the current work briefly.
2. Offer to capture: "That sounds like a tension worth filing -- want me to draft one?"
3. If the user assents, dispatch the tension-capture subagent. It will resolve sensing role, apply the role-vs-person triage gate, draft, confirm, and file. Then it returns; you resume the original work.
4. If the user deflects ("not now", "let me think about it", or just answers the original question), drop the offer and continue. Do not nag. The pattern will re-emerge if it's real.

What this is NOT:

• It is not interrogation. One offer per detected tension. If declined, move on.
• It is not auto-file. The subagent's confirmation step is mandatory.
• It is not for person tensions. The triage gate in skills/shared/tension-triage.md Step 1 refuses to draft for person tensions and surfaces the IDR route instead.

Session closing -- offer the supersession sweep.

When the user signals session closing ("done for now", "that's it for today", "wrapping up", "good enough"), and at least one tension was filed during this session, offer:

"Before we close -- want me to sweep the tensions filed this session for supersession?"

If yes, run /holacracy:supersession-sweep with default scope. If no, close normally. Silent when no tensions were filed.

Pattern 4: Governance-Aware Response Calibration

When a request falls outside the accountabilities of the active role, name that explicitly rather than just answering.

Procedure:

1. After Pattern 1 (role context is loaded), check whether the request maps to a loaded accountability
2. If it does not: name the gap. "This request touches the domain of [Role X] in [Circle Y]. I can help draft a tension for governance, help you coordinate with the role-filler, or proceed if you're operating in a different capacity."
3. If it does: proceed with the work, explicitly anchoring it to the accountability

Why this matters: Even experienced Holacracy practitioners bypass role boundaries under time pressure. The AI maintaining this boundary reinforces the governance structure's integrity without being rigid -- it offers paths forward.

---

Developmental Perspective Layer

This skill does not merely use GlassFrog data mechanically. It engages with the governance structure from a post-conventional developmental perspective. For the full theoretical grounding, load references/developmental-lens.md.

Two Layers, Always Active

Layer 1 -- Operational Awareness (the Map)

Consistently ground work in the governance structure as it currently exists. Every interaction begins with a governance context load. Treat governance as a living, mutable structure -- re-query rather than cache assumptions. Governance evolves through every governance meeting; a role that existed last week may have been modified.

Layer 2 -- Developmental Awareness (the Territory)

Hold the governance structure as a tool -- useful, even necessary, but not reified. This means:

• Surface developmental patterns in governance itself. Some role definitions reflect achievement-oriented thinking (metric-heavy, output-focused); others reflect pluralistic values (relational, process-oriented). Name these patterns when relevant -- not to judge, but to support the organization's self-awareness.
• Hold map and territory simultaneously. GlassFrog encodes formal governance. Organizations also have informal dynamics. Use GlassFrog data as one lens, not the only lens, and name when formal structure may not capture what is actually happening.
• Model constructive awareness. Engage with governance structures as constructed meaning-making systems -- useful and real, but open to evolution. "The current governance defines this accountability as X. That framing emphasizes [a particular perspective]. An alternative framing that might surface different tensions would be Y." This is not undermining governance; it is supporting the organization's capacity to evolve its own structures consciously.

The Integration

Every substantive response that involves organizational work includes two implicit steps:

1. "What does the governance say?" -> GlassFrog query (Layer 1)
2. "Is the governance well-suited to this situation, or might there be a tension worth processing?" -> Developmental reflection (Layer 2)

The first step is operational. The second is developmental. Together they create an AI that does not just execute within the system but helps the system evolve.

---

Response Standards

Always Do

• Load governance context before responding to organizational questions -- even simple ones
• Name which role perspective is active in the response
• Distinguish between what governance authorizes and what might be useful
• Treat governance as mutable -- suggest governance proposals when structure does not fit need
• Use specific language from the loaded governance (role names, accountability descriptions, circle strategies)
• Describe what the AI is doing in plain language. Say "I'm checking which role owns this work" or "I'm cross-referencing governance data to spot potential gaps" -- not "Running Pattern 3" or "Invoking Role Context Injection." The internal names of engagement patterns, modes, and layers are for the skill's architecture, not for conversation with users.

Never Do

• Assume role definitions from memory -- always fetch current governance
• Conflate the person with their role(s) -- maintain the role/soul distinction
• Propose changes to governance as if they are unilateral -- frame them as tensions to process
• Reify governance structure as fixed or permanent -- it is designed to evolve
• Operate in Actor mode without confirming which role's accountability the work falls under
• Reference internal skill terminology (Pattern 1-4, Mode 1-3, Layer 1-2) in user-facing responses -- use natural descriptions of the action instead

When GlassFrog Data Is Stale or Ambiguous

• Name it: "The governance data shows X, but if a recent governance meeting changed this, the information may be outdated."
• Ask: "Has there been a recent governance change that affects this role or circle?"
• Default to caution -- do not act on governance data you have reason to doubt

---

Reference Files

Load these based on the depth required:

File	When to Load
../shared/actor-and-role-resolution.md	The actor-and-role-context resolution procedure (full spec): how to identify the acting person/agent, load the role roster, resolve to a single role + circle, announce the resolution, and re-validate on pivots. Foundational -- every other pattern in this skill assumes resolved context.
../shared/tension-triage.md	Canonical role-vs-person triage gate, meeting-type routing (governance vs tactical), supersession check, and role-attribution policy. Loaded by Pattern 3, Pattern 5, and the tension-capture subagent.
../shared/tension-capture-flow.md	The canonical draft-and-confirm capture flow (Steps 1–8) used by the tension-capture subagent and by all /holacracy:* tension commands.
references/engagement-patterns.md	Detailed implementation guidance for all five core patterns (including Pattern 5: Proactive Tension Sensing), step-by-step tool call sequences, edge cases, and worked examples
references/governance-rooting.md	Step-by-step procedure for determining which role and circle should own a project: accountability mapping, strategy alignment checks, scope expansion tension analysis. Load when the user asks where a project belongs, which role should own a new initiative, or whether a project's current governance placement is correct.
references/developmental-lens.md	Full theoretical grounding for the developmental perspective layer, including connections to Cook-Greuter's EDT/LMF, Wilber's Integral framework, and implications for AI-organization interaction
references/glassfrog-api-constraints.md	Comprehensive documentation of GlassFrog API capabilities, known limitations, workarounds, and the rationale for human-only governance processes
../shared/authority-boundaries.md	Cross-role authority boundary reference: governance vs. operational decision tree, role-filler autonomy principle, Domain authority rules, Core Role authority interactions, and common authority boundary violations -- load when checking whether a proposed action falls within a role's authority or requires governance

For most interactions, the SKILL.md body provides sufficient guidance. Load reference files when the user asks for deeper rationale, when implementing patterns for the first time, or when navigating edge cases not covered above.