// workforce definition / runtime selection / provider-neutral matching

HowlForge ハウルフォージ // 2026

Your AI agents aren’t a pile of tools. They’re a software team. HowlForge defines durable roles, declares available runtimes, ranks eligible workers with reasons, and validates handoff evidence so another worker can safely resume.

AXIOM // ROLES ARE DURABLE. MODELS ARE REPLACEABLE. SESSIONS ARE DISPOSABLE. An architect is a role. Claude Opus is a runtime. The two are never equated, because the day the model changes, the role has to survive it.

[ GITHUB ] [ DOCUMENTATION ] [ EXPLORE THE HOWL ECOSYSTEM ]

BOUNDARY // SELECT AND EXPLAIN — NEVER LAUNCH GO LIBRARY + CLI

01 // Roles

What work exists, and what capabilities does it require?

02 // Runtimes

Which providers, models, and clients are declared — and available now?

03 // Match

Who is eligible, in what order, and why?

04 // Handoff

If a worker disappears, what evidence must exist to resume safely?

SECTION // 01 What Forge solves

HFRG-MOD-PROBLEM

Developers increasingly have multiple AI coding agents available, but those agents usually operate independently — without shared roles, ownership, handoffs, or an inspectable reason for why one worker was chosen over another.

Without structure

A role becomes a synonym for whichever model is configured
When a session ends, the role effectively ends with it
Handoffs are informal or missing
Routing decisions cannot be explained after the fact
Provider churn breaks institutional memory

With HowlForge

Roles declare responsibilities and capability floors
Runtimes declare aptitude separately from authority
Matching is deterministic and rejection-staged
Handoff and resume contracts are validated
Verification requirements are recorded — not executed here

What HowlForge is not
Concern	Owner
Launching workers, retries, scheduling	HowlPlane
Moving and storing checkpoints	HowlRelay
What a worker may do (authority)	HowlFrame
Running verification	HowlProof
Semantic “should we?” judgments	HowlInstinct

SECTION // 02 The Pack — shipped example roles

HFRG-MOD-PACK

Roles are data, not code. The repository ships an example pack under config/roles/. Real organizations may branch, add, or replace roles — the graph below is representative, not a fixed hierarchy.

[PACK // EXAMPLE ROLE GRAPH] config/roles/

                         ┌─────────────┐
                         │   product   │  scope & acceptance
                         └──────┬──────┘
                                ▼
                         ┌─────────────┐
                         │   foreman   │  decompose · delegate · recover
                         └──────┬──────┘
            ┌───────────┬───────┼───────┬───────────┐
            ▼           ▼       ▼       ▼           ▼
      ┌──────────┐ ┌────────┐ ┌────┐ ┌────────┐ ┌──────────┐
      │architect │ │implement│ │ qa │ │devops  │ │ security │
      └────┬─────┘ └────┬───┘ └─┬──┘ └───┬────┘ └────┬─────┘
           │            │       │        │           │
           ▼            ▼       ▼        ▼           ▼
      ┌──────────┐ ┌────────┐ ┌────┐ ┌────────┐ ┌──────────┐
      │researcher│ │reviewer│ │sre │ │auditor │ │ (custom) │
      └──────────┘ └────────┘ └────┘ └────────┘ └──────────┘

Textual equivalent: product → foreman → {architect, implementer, qa, devops, security,
researcher, reviewer, sre, auditor} with branching ownership rather than a single line.

product

Defines scope, requirements and acceptance criteria.

foreman

Coordinates complex work and delegates to specialists.

architect

Designs system structure and evaluates trade-offs.

implementer

Writes and modifies code against a defined specification.

Exercises behavior to find defects the implementer did not.

reviewer

Independently falsifies a change rather than confirming it.

devops

Builds and maintains packaging and deployment paths.

sre

Protects reliability, diagnoses incidents, reduces recurrence.

security

Assesses changes for security defects and unsafe authority use.

researcher

Gathers evidence to ground decisions.

auditor

Independently audits evidence and authority decisions after the fact.

SECTION // 03 How it works

HFRG-MOD-FLOW

HowlForge answers workforce questions inside a larger engineering loop owned by sibling components. Matching itself is a deterministic filter then rank — never an execution step.

01 // IDEAWork enters via Board / Product / Dream / Create.

02 // JUDGEHowlInstinct may answer bounded “should we?” questions.

03 // ROLEHowlForge resolves which role owns the work.

04 // MATCHEligible runtimes ranked with rejection stages and reasons.

05 // BUILDHowlPlane launches; Forge does not.

06 // REVIEW / TESTReviewer and QA roles; verification recorded as a requirement.

07 // SECURE / RELEASEHowlFrame authority + HowlChangeOps gates.

08 // OBSERVESRE / Board / Relay continuity; rematch on session loss.

↺ Feedback returns as new work — roles survive, sessions do not

Matching pipeline (as implemented)

[MATCH // HARD FILTER THEN RANK] DETERMINISTIC

Phase 1 — hard filter (first reject wins):
  request_excluded → role_excluded → disabled → capability → requirement → availability

Phase 2 — rank key (total order):
  prefer-hint → declared preference → availability rank → capability surplus → runtime id

Every rejection carries a machine-readable stage code and a human sentence.
Each candidate records decided_by naming the first term that placed it.

SECTION // 04 Provider independence

HFRG-MOD-PROVIDERS

HowlForge organizes capabilities rather than binding the system to one model vendor. Roles prefer selectors (provider + model), not runtime ids, so a new client for the same model becomes a candidate without editing the role.

Claude / Claude Code

Anthropic models via declared runtimes.

Codex

OpenAI models through Codex CLI clients.

Cursor

Same models through Cursor agent runtimes.

Grok / Grok Bot

xAI runtimes as first-class peers.

AGY / Antigravity

Gemini-family clients in the example pack.

Local / Ollama

Locality-aware runtimes without special-casing the matcher.

Capability levels in the example config are operator expectations, not benchmark results. Aptitude (HowlForge) and authority (HowlFrame) are separate vocabularies and must never be conflated.

SECTION // 05 How Forge connects to Howl

HFRG-MOD-ECOSYSTEM

Conceptual placement inside the broader Howl stack. This is a responsibility map, not a claim that every edge is already wired in production.

[ECOSYSTEM // RESPONSIBILITY FLOW] CONCEPTUAL

HUMAN OWNER
    │
    ▼
HowlDream / HowlCreate     ideas & exploration
    │
    ▼
HowlInstinct               “Should we do this, and why?”
    │
    ▼
HowlForge                  “Who should do it, and with what runtime?”
    │
    ▼
HowlPlane                  “How do we coordinate and launch it?”
    │
    ├──────────────┬────────────────┐
    ▼              ▼                ▼
HowlFrame      HowlRelay      HowlChangeOps
authority      handoffs       governed change
    │
    ▼
HowlProof                  independent assurance

Organization layer: HowlFutureWorks · Work surface: HowlBoard
Related: HowlWriter · HowlNotes · Howl Hub

Documented integration contracts: docs/INTEGRATION.md. HowlForge never launches a worker — HowlPlane does.

SECTION // 06 Philosophy

HFRG-MOD-PHILOSOPHY

Specialized agents beat undifferentiated swarms

Explicit roles with ownership beat interchangeable chatbots competing for the same undifferentiated task.

Inspectable decisions

Matching rejects with stages and reasons. Ranking records decided_by. Preference hints never change eligibility.

Provider independence

Roles survive model and client churn. Selectors match on provider/model wildcards.

Humans remain in control

Forge reports what a worker can do (aptitude). It never grants what a worker may do (authority).

Evidence over vibes

Handoff bundles validate shape and resume safety; verification requirements are explicit.

Recoverable failures

When a session dies, rematch and resume against validated checkpoints — do not reinvent the role.

SECTION // 07 Quick start

HFRG-MOD-START

[QUICKSTART // GO LIBRARY + CLI]

git clone https://github.com/howlcipher/howlforge
cd howlforge
make build

./build/howlforge --config config validate
./build/howlforge --config config roles
./build/howlforge --config config match foreman

The shipped config/ tree is marked as an example throughout and is meant to be replaced. Further reading: CLI · Handoff · Architecture.

SECTION // 08 Status & repository

HFRG-MOD-STATUS

Early library and CLI — not a claim of production readiness.

Repository: github.com/howlcipher/howlforge
Language: Go library + CLI; starts only git for resume safety checks
A runtime definition can never cause anything to be executed
Sibling integrations are contracts and adoption paths — not silently claimed as live wiring
No benchmarks, release maturity claims, or invented production deployments appear on this page