What exists today vs what's needed for multi-company business operations
H·AI·K·U is a Claude tool, not a platform. There is no server, no daemon, no always-on process. Cross-studio coordination, triggers, and knowledge sharing flow through providers — the company's existing tools (CRM, ticketing, wiki, comms). Claude mediates the translation. Scheduled tasks and remote triggers handle polling when no human session is active.
What H·AI·K·U has today — the single-project, single-agent foundation.
Business processes chain across studios. Providers + scheduled tasks solve this without requiring an always-on server.
A sales deal closes. Customer success should automatically begin onboarding. But today, someone has to manually create the CS intent.
Product strategy prioritizes a feature. Software studio should receive the roadmap item as an intent seed. No automated handoff exists.
Incident postmortem produces action items. These should automatically create compliance or software intents for prevention work.
H·AI·K·U is a CLI tool, not a server. Triggers don't need an always-on daemon — they use three mechanisms:
1. Provider polling (scheduled tasks): A /schedule task runs periodically, polling the CRM/ticketing provider for events. When a Salesforce deal closes, the next poll picks it up and suggests creating a CS onboarding intent.
# Scheduled trigger: runs every 30 minutes via Claude Code /schedule
/haiku:triggers --poll crm
→ Checks CRM for deal stage changes since last poll
→ "Deal Acme Corp closed. Create CS onboarding intent?"
→ Seeds intent with deal context distilled from CRM2. Session-start discovery: When a user opens Claude Code, the harness checks all configured providers for events affecting active intents. Pull-based, not push.
3. Studio-level trigger declarations: Studios declare what downstream intents should be suggested when work completes. These are suggestions surfaced during polling, not automatic spawns.
# sales/STUDIO.md
triggers:
on-complete:
- studio: customer-success
template: new-customer-onboarding
condition: "outcome == won"
source: crm # provider to pull context fromRepeatable processes shouldn't require fresh elaboration every time.
Define the lifecycle: which stages, which hats, which gates.
Pre-filled intents with standard units, criteria, and references. Instantiate with parameters.
Add templates/ to the studio directory. Each template is a pre-filled intent with parameterized fields.
# customer-success/templates/new-customer-onboarding.md
---
name: new-customer-onboarding
studio: customer-success
parameters:
- name: company
required: true
- name: deal-context
required: false
units:
- name: "technical-setup"
stage: onboarding
criteria:
- "{{ company }} environment provisioned and accessible"
- "SSO/auth configured and tested"
- name: "kickoff-meeting"
stage: onboarding
criteria:
- "Kickoff scheduled with {{ company }} stakeholders"
- "Success milestones agreed and documented"
---Templates are instantiated via /haiku:start --template new-customer-onboarding --company "Acme Corp". Parameters fill in the template. Triggers can also instantiate templates automatically.
Departments share context through providers. The knowledge provider is the cross-studio data bus — Claude writes to it in one studio and reads from it in another.
Studios don't share filesystems. They share providers. Claude translates in both directions.
# Studio A (product-strategy) completes roadmap stage:
→ Claude distills roadmap item into knowledge provider format
→ Writes to Confluence/Notion in the team's standard brief template
→ NOT markdown frontmatter — the provider's native format
# Studio B (software) starts inception stage:
→ Claude reads knowledge provider for relevant context
→ Distills Confluence brief into H·AI·K·U intent context + criteria
→ The provider's data model doesn't need to match H·AI·K·U'sThe key insight: Claude is the universal adapter. Salesforce doesn't store frontmatter. Confluence doesn't understand bolts. Claude reads the provider's native data model, understands the semantic meaning, and produces H·AI·K·U artifacts — and vice versa. The translation is in Claude's context, not in a rigid schema mapping.
Ownership, approval, and handoffs are provider concerns — the ticketing system handles role assignment, the CRM handles deal ownership, the comms provider handles notifications. H·AI·K·U pushes state to these tools rather than reinventing people management.
The ticketing provider assigns owners. When H·AI·K·U creates a ticket for a stage's work, the assignee IS the owner. CRM deal owners map to sales stage owners.
The ticketing provider's workflow engine handles approval chains. Jira has approval workflows. Linear has review cycles. H·AI·K·U's external gate pushes to the provider and blocks until the provider says it's approved.
The knowledge provider is the handoff mechanism. Sales pushes deal context to Confluence; Customer Success reads it. Claude translates in both directions.
Scheduled tasks poll providers continuously. The await gate records what it's waiting for; the next poll checks the provider (CRM deal stage changed? Comms thread got a reply?) and advances the gate.
H·AI·K·U doesn't need its own role system. The company's existing tools already manage people:
# Ownership: ticketing provider assigns owners
H·AI·K·U creates stage ticket → assigns to team via provider config
Ticketing system handles: who, notifications, escalation
# Approval: provider workflow engines
external gate → creates PR/ticket → provider's approval workflow runs
H·AI·K·U polls provider → approved? → advance gate
# Handoff: knowledge provider
Sales intent completes → pushes handoff context to Confluence
CS intent starts → reads handoff context from Confluence
Claude translates between the two studios' data models
# Event gates: scheduled task polling
await gate → records what it's waiting for
Scheduled task polls CRM/comms every N minutes
Event detected → gate advances on next session or pollRemaining gap: A gate-protocol: schema in STAGE.md could formalize timeout and escalation behavior. But the actual execution of approvals and ownership lives in the provider, not in H·AI·K·U.
The ticketing provider IS the portfolio dashboard. CRM pipeline views show deal progress. Jira boards show engineering work. The provider already aggregates across teams.
Intent epics in the ticketing provider = portfolio items. The provider's board, backlog, and reporting views are the dashboard. H·AI·K·U keeps them in sync via outbound translation.
The ticketing provider tracks velocity, cycle time, and throughput. The CRM tracks pipeline conversion. H·AI·K·U's reflection dimensions produce domain-specific analysis. Providers aggregate; H·AI·K·U analyzes.
The /browse feature is a hosted SPA that renders H·AI·K·U workspaces from any source:
# Local — drag and drop a project folder
/browse → reads .haiku/ via File System Access API
# Remote — connect to any Git provider
/browse/git?repo=github.com/org/repo → GitHub REST API
/browse/git?repo=gitlab.com/group/project → GitLab REST API
# Auth — SPA OAuth for private repos
/auth/github/callback → code exchange via GCP Cloud Function
/auth/gitlab/callback → code exchange via GCP Cloud Function
# Views: Portfolio → Intent → Stage → Unit
# Same components for local and remote — only the data source differsTicketing provider boards remain the primary operational dashboard. /browse adds artifact-level visibility — dive into intent specs, unit criteria, stage outputs — directly from the browser.
With the foundation complete, these gaps emerge when running H·AI·K·U across departments at scale.
This is primarily a software concern. Git already handles merge conflicts at PR time. The improvement is earlier awareness — during elaboration, not at merge.
During elaboration (step 4.1), the software studio's inception stage checks for other active haiku/* branches and their recent file changes. If overlap is detected, it surfaces a note — not a blocker. Git handles the actual conflicts.
# During elaboration, a quick check:
git branch -r --list 'origin/haiku/*' | while read branch; do
git diff --name-only main...$branch
done
# → "Note: haiku/auth-refactor also modifies src/auth/ — be aware"
# Not a blocker. Not a trigger. Just awareness during planning.No footprint schema, no polling infrastructure, no cross-repo scanning. Git is already the conflict resolution tool. This just moves awareness earlier.
Knowledge artifacts become stale as the product evolves. Detection belongs at the point of use — during elaboration, when a stage loads its inputs — not on a polling schedule.
Stage outputs declare freshness and code dependencies in their frontmatter. When a downstream stage loads the input during elaboration, Claude checks the metadata and surfaces staleness.
# Stage output metadata (written during output persistence, step 4.4)
---
name: behavioral-spec
stage: product
created: 2026-03-15
freshness: 90d # advisory: consider stale after 90 days
last_validated: 2026-03-15
depends_on_code: # files this artifact describes
- src/api/routes/*.ts
- src/services/auth.ts
---
# Decay check (during elaboration, step 4.1 — when loading inputs):
# Claude reads the input artifact, checks the metadata:
1. freshness: created + 90d < now? → "This spec is 120 days old"
2. code drift: git log --since={last_validated} -- {depends_on_code}
→ "47 commits to the described files since this spec was written"
3. Claude decides: surface as a note, trigger stage-scoped refinement,
or proceed if the changes are irrelevant to this stage's workNo trigger, no polling. The check happens naturally when the artifact is consumed. Code-drift is more meaningful than time — a spec describing unchanged code is still fresh regardless of age.
A product launch needs marketing AND software stages running in parallel with sync points. A compliance remediation might require both software development AND documentation. Today, these are separate intents with manual coordination.
An intent can declare multiple studios with sync points. Each studio's stages run independently, but specified stages must sync before either can advance.
# intent.md for a product launch
---
title: Launch Feature X
composite:
- studio: software
stages: [inception, design, development]
- studio: marketing
stages: [research, strategy, content, launch]
sync:
- wait: [software:development, marketing:content]
then: [marketing:launch]
reason: "Can't launch marketing until the feature is built"
---
# Execution:
# software:inception and marketing:research run in parallel
# software:design and marketing:strategy run in parallel
# software:development and marketing:content run in parallel
# marketing:launch WAITS for both software:development + marketing:content
# → sync point enforced by the orchestratorComposite intents are coordinated locally. Each studio's stages run their own elaborate→execute→review→gate cycle. Sync points are just await gates that check the other studio's stage completion status.
Already covered by /haiku:operate. Each studio defines operation templates (health-check, monitoring, etc.) that run after delivery. The operations stage in the software studio includes health checks, dependency audits, and backup verification — all studio-prescribed.
Not a separate mechanism. The /haiku:operate skill reads operation templates from studios/{studio}/operations/ and instantiates them for each intent. The software studio already ships with health-check.md, dependency-audit.md, backup-verification.md, and secret-rotation.md.
Implemented. /haiku:capacity reads timestamps from committed frontmatter — intent, stage, and unit artifacts all have started_at and completed_at. No OTEL query needed (write-only endpoint). No iteration.json (deprecated). Git log provides session count estimates.
Not H·AI·K·U's concern. Providers enforce their own access control — git repos have permissions, ticketing has team visibility, CRM has deal ownership. /browse inherits git provider ACLs via OAuth. No additional layer needed.
Redundant. Studios ship as part of the plugin, which is already versioned (plugin.json, auto-bumped by CI). You can't pin studio A to v1 while studio B runs v2 — they're all in the same plugin release. Intent records the plugin version it was created with (plugin_version in frontmatter) for reference, but there's no separate studio version to manage.
Wave 1 makes H·AI·K·U work across companies. Wave 2 makes it work at scale.
H·AI·K·U is a Claude tool, not a platform. Providers are the infrastructure. Claude is the universal adapter.