Model goal-driven agent workforce governance
All checks were successful
ci / test (push) Successful in 3m26s
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s

This commit is contained in:
tegwick 2026-08-20 13:03:26 +02:00
parent d1dece7409
commit 6ed5708c21
5 changed files with 373 additions and 51 deletions

View file

@ -2,7 +2,7 @@
# Custodian Brief — kaizen-agentic
**Domain:** infotech
**Last synced:** 2026-08-20 10:06 UTC
**Last synced:** 2026-08-20 11:03 UTC
**State Hub:** http://127.0.0.1:8000 *(adjust if running on a remote machine)*
## Active Workstreams

View file

@ -52,8 +52,9 @@ boundary in `INTENT.md`, not an unfinished runtime hidden in this repository.
packages, staffed-role lifecycle, bound agent definitions, ramp-up/down,
client-custodied memory, engagement metrics, and reference pilot artifacts
- **Interoperability contracts and reference patterns** for activity-core,
rein-aharness, role-engine, llm-connect, State Hub, artifact-store, Helix
Forge, and Custodian discovery
rein-aharness, role-engine, agentic-resources, human-resources, fin-hub,
resource-control, llm-connect, State Hub, artifact-store, Helix Forge, and
Custodian discovery
- **ADRs, workplans, tutorials, and integration handoffs** that make these
conventions human-readable and machine-consumable
@ -67,6 +68,8 @@ boundary in `INTENT.md`, not an unfinished runtime hidden in this repository.
- Holding credentials or granting authentication, authorization, decision
rights, or tool permissions
- Live assignment of a person or agent to an organizational role
- Setting organizational goals, granting leadership authority, allocating the
agent workforce, or owning financial/resource budgets
- Owning the complete organizational role catalog; role-engine is the current
definition source, while this repository may consume roles and package
execution-oriented reference Roles
@ -89,6 +92,8 @@ boundary in `INTENT.md`, not an unfinished runtime hidden in this repository.
- Declaring a repo-local agent instance and preparing it for scheduled execution
- Designing a staffed digital Role engagement or mapping an organizational role
to an executable agent blueprint
- Translating leadership-owned goals and budget-constrained assignments into
measurable blueprint, protocol, schedule, and evidence contracts
- Integrating Kaizen work with activity-core, rein-aharness, State Hub, Helix
Forge, or artifact-store
- Understanding the KaizenAgentic product and agency operating model
@ -101,6 +106,11 @@ boundary in `INTENT.md`, not an unfinished runtime hidden in this repository.
- The need is purely schedule/runtime operation; use activity-core and the
selected rein/harness
- The need is organizational role definition only; use role-engine
- The need is agent inventory, assignment, capacity planning, portfolio review,
or retirement; agentic-resources is the intended owner once its boundary is
ratified and implemented
- The need is authoritative budget, burn, runway, resource capacity, or
procurement evidence; use fin-hub and resource-control
- The need is identity, credentials, or authorization; use the owning identity,
OpenBao/credential-routing, and policy systems
- The need is repository capability profiling or SCOPE generation at scale; use
@ -124,8 +134,9 @@ boundary in `INTENT.md`, not an unfinished runtime hidden in this repository.
standardized
- **Repository health:** Forgejo CI, release checks, agent validation, and
metadata/workplan conventions are normalized through KAIZEN-WP-0011
- **Open maturity gap:** a canonical role-definition → assignment → agent-instance
contract and an end-to-end role-based pilot remain to be implemented
- **Open maturity gap:** canonical goal/leadership/resource-envelope → role →
assignment → agent-instance contracts and an end-to-end role-based pilot
remain to be implemented
---
@ -133,9 +144,14 @@ boundary in `INTENT.md`, not an unfinished runtime hidden in this repository.
| Concern | Owning system | KaizenAgentic relationship |
|---|---|---|
| Organizational goals and leadership mandates | Accountable organization/engagement control source (`binky-control` for Binky) | Consume goal, outcome, decision-right, and escalation references; never invent strategic authority |
| Organizational role definitions | `role-engine` | Consume stable role references and translate duties/evidence into blueprint inputs |
| Agent workforce inventory, assignment, capacity, and portfolio review | `agentic-resources` (recommended boundary; not yet implemented) | Provide blueprint/metric contracts and receive assignment/performance references |
| Human workforce planning and mixed-team boundaries | `human-resources` | Align compatible vocabulary without sharing human-sensitive records or treating people as compute |
| Agent blueprints and improvement | `kaizen-agentic` | Own |
| Repo-local agent instance | Consuming repository | Define through `.kaizen/` contracts owned jointly with runtime extensions |
| Monetary budgets, commitments, burn, runway, and AI-plan booked cost | `fin-hub` | Consume provenance-bearing constraints; publish goal/assignment/duty attribution evidence |
| Resource demand, capacity, allocation, utilization, and technical economics | `resource-control` | Consume capacity/cost evidence; do not duplicate resource or procurement authority |
| Scheduling and claimable work | `activity-core` | Supply manifests, definitions, prepare commands, and event contracts |
| Governed unattended execution | `rein-aharness` (selected rein) | Supply blueprint/orientation bundle; receive metrics and improvement evidence |
| Model/provider abstraction | `llm-connect` | Runtime dependency outside this repository |
@ -144,8 +160,10 @@ boundary in `INTENT.md`, not an unfinished runtime hidden in this repository.
The workspace currently has `role-engine`, not a component named
`role-manager`. Role-engine explicitly excludes live assignment and execution.
An assignment/binding contract therefore needs an explicit owner before roles
can be automated at scale.
Agentic-resources is the best-fit existing assignment/workforce owner, but its
current implemented scope is session improvement and its root SCOPE is stale;
that responsibility needs an explicit boundary decision before roles can be
automated at scale.
---
@ -159,7 +177,12 @@ can be automated at scale.
containing blueprint/protocol/ramp assets; currently not the canonical
organization-wide role catalog
- **Assignment / binding**: a record that selects who or what fills a role in a
specific context; ownership is not yet standardized
specific goal/context under a leadership mandate and resource envelope;
agentic-resources is the recommended owner
- **Leadership mandate**: explicit delegation of goal decomposition, decision
rights, review, and escalation; not implied by an agent or role name
- **Resource envelope**: provenance-bearing financial, token, time, capacity,
and attention constraints delegated to an assignment
- **Instance**: consumer-owned declaration binding a blueprint to target,
cadence, policy lane, tool profile, budget, memory, and metrics
- **Engagement**: a client-scoped lifecycle and custody boundary for staffed work

View file

@ -20,6 +20,7 @@
| workplan | KAIZEN-WP-0010 | finished | — | workplans/KAIZEN-WP-0010-forgejo-pypi-migration.md |
| workplan | KAIZEN-WP-0011 | finished | — | workplans/KAIZEN-WP-0011-repository-health-normalization.md |
| workplan | KAIZEN-WP-0012 | finished | — | workplans/KAIZEN-WP-0012-scope-intent-role-automation-assessment.md |
| workplan | KAIZEN-WP-0013 | finished | — | workplans/KAIZEN-WP-0013-agent-workforce-goal-budget-governance.md |
| task | T01 | done | — | workplans/KAIZEN-WP-0003-measurement-loop.md |
| task | T02 | done | — | workplans/KAIZEN-WP-0003-measurement-loop.md |
| task | T03 | done | — | workplans/KAIZEN-WP-0003-measurement-loop.md |
@ -138,3 +139,7 @@
| task | KAIZEN-WP-0012-T02 | done | — | workplans/KAIZEN-WP-0012-scope-intent-role-automation-assessment.md |
| task | KAIZEN-WP-0012-T03 | done | — | workplans/KAIZEN-WP-0012-scope-intent-role-automation-assessment.md |
| task | KAIZEN-WP-0012-T04 | done | — | workplans/KAIZEN-WP-0012-scope-intent-role-automation-assessment.md |
| task | KAIZEN-WP-0013-T01 | done | — | workplans/KAIZEN-WP-0013-agent-workforce-goal-budget-governance.md |
| task | KAIZEN-WP-0013-T02 | done | — | workplans/KAIZEN-WP-0013-agent-workforce-goal-budget-governance.md |
| task | KAIZEN-WP-0013-T03 | done | — | workplans/KAIZEN-WP-0013-agent-workforce-goal-budget-governance.md |
| task | KAIZEN-WP-0013-T04 | done | — | workplans/KAIZEN-WP-0013-agent-workforce-goal-budget-governance.md |

View file

@ -30,12 +30,13 @@ now exist elsewhere:
evidence.
The missing link is a governed, machine-readable chain from a role definition
to a specific agent assignment and executable instance. The runtime path itself
is no longer hypothetical: activity-core's queue and rein-aharness's generic
`agent-session` approach are implemented. However, the current queue payload
and harness intake do not carry an explicit role, assignment, or arbitrary
agent-instance reference. Rein-aharness currently infers the agent from a small
fixed definition/label map and otherwise defaults to `coach`.
through an authorized goal and constrained workforce allocation to a specific
agent assignment and executable instance. The runtime path itself is no longer
hypothetical: activity-core's queue and rein-aharness's generic `agent-session`
approach are implemented. However, the current queue payload and harness intake
do not carry an explicit goal, leader, role, assignment, budget envelope, or
arbitrary agent-instance reference. Rein-aharness currently infers the agent
from a small fixed definition/label map and otherwise defaults to `coach`.
## Naming and ownership finding
@ -51,11 +52,55 @@ This matters because role-engine's `INTENT.md` explicitly says:
- machinery should be added only for demonstrated consumer requirements.
Therefore “roles as defined by role-manager” is treated here as “roles defined
by role-engine.” A separate **assignment/binding owner** is still required. It
could be a deliberately introduced role-manager service, a consumer-owned
assignment manifest indexed by State Hub, or an extension of an existing
system—but that ownership decision should be explicit rather than silently
changing role-engine's purpose.
by role-engine.” `agentic-resources` is the best-fit existing repository to
become the **agent workforce and assignment manager**, subject to an explicit
INTENT/SCOPE decision there. That preserves role-engine's catalog boundary and
avoids introducing a role-manager service before a separate runtime service is
actually needed. Consumer-owned assignment manifests can remain the durable
source while agentic-resources indexes, plans, and governs the portfolio.
## Agentic-resources and human-resources finding
`agentic-resources` is **not intent-only**, although its root `SCOPE.md` is a
stale generated placeholder. Its finished AGENTIC-WP-0002 through WP-0011 work
implements a substantial Helix Forge loop:
- capture and normalize Claude, Codex, and Grok coding sessions;
- retain raw/digested memory within storage budgets;
- detect cost, failure, success, and infrastructure-friction signals;
- curate evidence-backed solution patterns with human approval;
- distribute approved patterns into agent environments;
- measure before/after effectiveness and fleet trends;
- publish weekly retrospectives and correlate with Kaizen project metrics.
That is already an **agent performance and development** subsystem. It is a
natural foundation for agent inventory, selection, assignment, capacity
planning, performance review, development, reallocation, and retirement. It
does not currently implement those workforce-management records, nor does its
current session-memory code understand organizational goals or financial
budget envelopes.
`human-resources` is the useful sibling model, but is much earlier: its current
implementation is a draft workflow registry and assessment loop covering
current-state inventory, automation potential, human-touch boundaries, and
readiness. Its INTENT explicitly includes human goal-setting, feedback,
coaching, compensation, workforce planning, and development. The two resource
systems should share vocabulary where useful—goal assignment, accountability,
capacity, performance evidence, development plan, lifecycle—without combining
human-sensitive records with agent telemetry or pretending humans and agents
have identical authority and welfare concerns.
Recommended boundary for agentic-resources:
- **Own:** agent workforce inventory, fit/selection evidence, assignments,
capacity allocations, performance/development plans, portfolio reviews, and
rebalance/retirement recommendations.
- **Consume:** leadership goals and mandates, role-engine definitions, Kaizen
blueprints/metrics, fin-hub constraints, resource-control evidence, State Hub
work/outcomes, and runtime status.
- **Do not own:** company strategy, the meaning of organizational roles,
financial truth or spending authority, resource procurement, credentials,
scheduling, or execution.
## Assessment against INTENT.md
@ -130,21 +175,109 @@ Important existing controls include:
This means the next work is integration and governance, not building another
scheduler or agent runtime.
## Goal, leadership, and budget governance spine
Role automation needs a control hierarchy above the execution backbone:
```text
organizational intent
leadership-owned goals and outcome measures
financial/resource/attention envelopes
agentic-resources workforce plan and RoleAssignment
Kaizen blueprint + consumer-owned AgentInstance
activity-core scheduled duty → rein-aharness bounded run
outcome, cost, evidence, escalation
leadership review + workforce rebalance + blueprint improvement
```
There is no single generic goal/leadership repository in the current
workspace. Goal authority is contextual. For Binky Hedgehog GmbH,
`binky-control` is the ratified company brain: it owns company intent, success
milestones, autonomy lanes, decision queues, and the founder-attention budget.
Other organizations or clients need an equivalent accountable control source.
Agentic-resources may translate a goal into workforce allocation, but it must
not invent or silently reprioritize strategic goals.
Leadership is an accountable relationship, not a prompt adjective. A
`LeadershipMandate` should identify:
- the organization/engagement and accountable leader or leadership agent;
- the goal(s) the leader may decompose and the outcomes it must preserve;
- decision rights, delegation depth, and prohibited commitments;
- who may approve, pause, reallocate, or terminate work;
- reporting/review cadence and the escalation chain;
- conflict-resolution order when goals or constraints compete;
- the time/attention budget expected from human reviewers.
An agent may lead other agents only inside this mandate. Role wording alone
must never create authority, and a leadership agent cannot widen its own budget
or tool grants.
### Budget layers and enforcement
“Budget” must not collapse into one token integer:
| Constraint | Authority/source | Allocation/control | Hard enforcement |
|---|---|---|---|
| Monetary budget, commitments, burn, runway | `fin-hub` | Leadership plus agentic-resources consume bounded constraint signals | Financial/approval systems; no autonomous spend outside an approved envelope |
| Infrastructure/model capacity and technical economics | `resource-control` | Agentic-resources uses forecasts, allocations, and optimization evidence | Platform/provider quotas and owning operators |
| AI-plan entitlement and booked effectiveness | `fin-hub`, joined to State Hub token evidence | Portfolio review and model/profile selection | Provider entitlement plus runtime policy |
| Per-run tokens and wall time | Delegated `ResourceEnvelope` | Agent instance/duty allocation | rein-aharness / llm-connect budget tracker and timeout |
| Concurrent agents and duty capacity | Agentic-resources workforce plan | Assignment allocator | activity-core eligibility plus harness worker/profile limits |
| Human attention and decision load | Organization leadership source; Binky example in `binky-control` | Decision batching and escalation policy | Approval queues and office-hour/autonomy lanes |
Fin-hub already exposes provenance-bearing budget-ceiling, commitment,
burn-pressure, and runway-pressure signals and owns booked AI-plan cost and
entitlements. Resource-control explicitly defers budget authority to fin-hub
and owns resource demand, capacity, utilization, allocation, and technical cost
evidence. Agentic-resources should consume both and allocate agent capacity
within them; it should not create a parallel money ledger or procurement
authority.
The shared `ResourceEnvelope` should support:
- stable ID, authority/source reference, period, scope, and currency/unit;
- hard ceiling, soft target, warning thresholds, and reserve;
- financial, token, wall-time, concurrency, and human-attention dimensions;
- amount allocated, committed, consumed, forecast, and remaining, with unknown
distinct from zero;
- allowed reallocation authority and approval threshold;
- cost-attribution key and goal/assignment/duty correlation;
- exhaustion behavior: refuse, degrade, defer, or prepare an approval package;
- evidence timestamps and supersession/version links.
Activity-core should schedule only eligible allocations, while rein-aharness
enforces the per-run slice. Agentic-resources controls the period/portfolio
allocation and proposes rebalancing. Leadership decides goal priority and any
material budget or authority change.
## The missing role-to-run contract
Four distinct records must remain separate:
The following records must remain distinct even when one manifest references
several of them:
| Record | Question answered | Recommended owner |
|---|---|---|
| `RoleDefinition` | What outcomes, duties, authority, interfaces, and evidence define the role? | role-engine |
| `AgentBlueprint` / executable Role package | How can an agent perform a safe subset of those duties? | kaizen-agentic |
| `RoleAssignment` | Which agent instance fills which role, for whom, on what targets and dates? | Explicit new owner or consumer-owned manifest indexed centrally |
| `StrategicGoal` | What outcome matters, why, by when, and how will success be judged? | Accountable organization/engagement leadership source |
| `LeadershipMandate` | Who may decompose the goal, direct work, decide, and escalate? | Accountable organization/engagement leadership source |
| `ResourceEnvelope` | Which financial, token, time, capacity, and attention constraints apply? | Fin-hub/resource-control/leadership facts composed into a delegated envelope |
| `RoleAssignment` | Which agent instance fills which role, for which goals, within which mandate and envelope? | Recommended: agentic-resources, with consumer-owned manifest as source |
| `AgentInstance` | Which blueprint, cadence, lane, profile, budget, memory, and runtime pin apply? | Consuming repository, validated by kaizen-agentic and the selected rein |
The first implementation should define a versioned `RoleAssignment` contract
with at least:
- stable assignment ID and lifecycle state;
- `goal_refs`, accountable outcome owner, and leadership-mandate reference;
- `role_ref` containing role ID plus immutable revision/version;
- `blueprint_ref` containing agent name plus package/version or content digest;
- client/tenant and one or more target references;
@ -152,6 +285,7 @@ with at least:
- expected outputs and evidence for each duty;
- cadence/event trigger references and timezone;
- autonomy lane, named tool profile, token/time budget, and harness-major pin;
- resource-envelope references plus duty-level allocation and exhaustion policy;
- credential-route **references**, never secret values;
- approval and escalation rules derived from role decision rights;
- memory/metrics custody location and retention classification;
@ -159,6 +293,42 @@ with at least:
## Required changes by repository
### Organization leadership/control source
1. Publish stable goal and leadership-mandate records with accountable owners,
outcomes, measures, priority, horizon, decision rights, and escalation.
2. Delegate bounded financial, capacity, token, time, and attention envelopes;
do not express “use judgment” as unlimited authority.
3. Resolve cross-goal priority and approve material reallocation, spending,
external commitments, or expansion of autonomy.
4. For the Binky company context, reuse `binky-control` intent, milestones,
autonomy lanes, decision packages, and founder-attention policy instead of
creating parallel company governance in an agent repository.
### agentic-resources
1. Deliberately refine INTENT/SCOPE from the implemented Helix Forge
session-improvement subsystem into an agent-workforce control boundary.
2. Define agent inventory, `RoleAssignment`, capacity allocation,
performance/development plan, portfolio review, and retirement contracts.
3. Match roles and blueprints to delegated goals using evidence; record why an
assignment is suitable and which role duties remain unstaffed.
4. Consume fin-hub constraint signals and resource-control evidence to allocate
period budgets without copying financial or resource ledgers.
5. Aggregate run outcomes/costs by goal, role, assignment, and duty; recommend
continue, coach/refine, reallocate, pause, or retire.
6. Require leadership approval for goal reprioritization, material envelope
changes, and authority expansion.
### human-resources
1. Reuse compatible goal, accountability, capacity, review, and development
vocabulary where it helps human/agent collaboration.
2. Keep human-sensitive records, compensation, welfare, employment, and
relational judgment separate from agent telemetry and automated scoring.
3. Represent mixed human-agent teams and handoffs without treating people as
interchangeable compute resources.
### role-engine
1. Add stable revision metadata or a small machine-readable companion format
@ -176,14 +346,15 @@ with at least:
former should be a derived execution package, not a competing organizational
role source.
3. Add a compiler/scaffolder that consumes a pinned role definition plus an
assignment and produces:
assignment, goal, mandate, and resource-envelope references and produces:
- a bound agent blueprint;
- protocols and success metrics;
- `.kaizen/schedule.yml` base/runtime fields;
- activity-core definition/rule fragments;
- validation evidence showing which role duties are covered or excluded.
4. Add schema validation for blueprint version, role revision, idempotency,
expected output, evidence, and escalation metadata.
expected output, evidence, goal traceability, budget/refusal behavior, and
escalation metadata.
5. Close the improvement promotion loop: evidence → proposed blueprint change →
tests/evaluation → human approval → versioned canary → rollback or promote.
@ -192,8 +363,9 @@ with at least:
1. Keep schedule and queue ownership.
2. Extend the task/`ops_run` contract with structured execution metadata instead
of encoding it only in labels or prose. Minimum useful fields are
`goal_refs`, `leadership_mandate_ref`, `resource_envelope_ref`,
`assignment_id`, `role_id`, `duty_id`, `agent_instance`, `blueprint_ref`,
`expected_output`, and a correlation/run key.
`expected_output`, allocated run budget, and a correlation/run key.
3. Emit `labels: [automated, agent-session]` and
`approach_hint: agent-session` for governed agent sessions.
4. Resolve only active, enabled assignments and generate a unique run for each
@ -206,25 +378,37 @@ with at least:
2. Replace fixed label-to-agent inference for role sessions with an explicit
validated `agent_instance`/blueprint reference from the run contract.
3. Verify the run's assignment is active and its role/blueprint/runtime versions
match the repo manifest.
match the repo manifest; refuse expired mandates or envelopes.
4. Enforce duty-level tool profile, target allow-list, budget, timeout,
concurrency, and escalation policy.
5. Return compact structured evidence: outcome, artifact path, commit, target,
blueprint/role/assignment revisions, metrics, and refusal/escalation reason.
goal/blueprint/role/assignment revisions, allocated/consumed budget,
metrics, and refusal/escalation reason.
6. Separate deterministic connectors from the LLM session. For example,
Telegram collection or publishing should be bounded adapters; the model
should receive prepared data and should not gain arbitrary network access.
### State Hub and policy/identity systems
1. Index assignments and correlation IDs without becoming the role source or
runtime.
2. Connect `activity_run → ops_run → harness execution → artifact/commit →
kaizen metrics` for review and audit.
1. Index goals, mandates, envelopes, assignments, and correlation IDs without
becoming their authoritative source or the runtime.
2. Connect `goal → assignment → activity_run → ops_run → harness execution →
artifact/commit → kaizen metrics → workforce review` for audit.
3. Represent human-needed/refused/escalated outcomes explicitly.
4. Route credential needs through the catalog/OpenBao path and enforce technical
authorization independently of role wording.
### fin-hub and resource-control
1. Fin-hub remains authoritative for monetary budgets, commitments, burn,
runway, AI-plan booked cost, entitlement, and viability signals.
2. Resource-control remains authoritative for resource identity, demand,
capacity, utilization, allocation evidence, and technical economics.
3. Expose provenance-bearing constraints with stable period/scope keys so
agentic-resources can allocate without guessing or treating unknown as zero.
4. Accept goal/assignment/duty attribution on usage and outcome evidence while
keeping allocation evidence distinct from booked spend.
## Proposed instance shape
This is a **target contract**, not the current kaizen schedule schema:
@ -235,6 +419,10 @@ timezone: Europe/Berlin
harness: 0
assignments:
community-manager-coulomb:
goal_refs:
- binky-control:goal:coulomb-community-health
leadership_mandate_ref: binky-control:mandate:community-operations
accountable_outcome_owner: founder
role_ref:
repository: role-engine
id: community-manager
@ -243,15 +431,22 @@ assignments:
name: community-manager
package_version: "<kaizen-agentic-version>"
target: coulomb-society-operations
resource_envelopes:
financial: fin-hub:budget:coulomb-community:2026-Q3
capacity: agentic-resources:envelope:community-ops:2026-W34
attention: binky-control:attention:founder:2026-W34
duties:
weekly-community-health:
goal_ref: binky-control:goal:coulomb-community-health
cadence: weekly
cron: "0 9 * * 1"
enabled: true
expected_output: reports/community-health/YYYY-MM-DD.md
lane: green
tool_profile: community-observe-report
budget: 40000
run_budget_tokens: 40000
run_timeout_seconds: 900
exhaustion: defer-and-report
approval: none
publication-draft:
cadence: weekly
@ -259,6 +454,7 @@ assignments:
expected_output: outbox/community-update-YYYY-MM-DD.md
lane: green
tool_profile: community-draft-only
run_budget_tokens: 30000
approval: human-before-publish
```
@ -283,18 +479,24 @@ Pilot sequence:
1. Pin the role-engine revision and identify which Community Manager success
criteria the brief measures.
2. Create a Kaizen blueprint/protocol and tests for evidence quality,
2. Record the leadership-owned goal, accountable outcome owner, review cadence,
and bounded financial/capacity/attention envelopes.
3. Have agentic-resources create the assignment and allocate a weekly duty/run
budget without copying the authoritative budget ledger.
4. Create a Kaizen blueprint/protocol and tests for evidence quality,
provenance, privacy handling, and “insufficient evidence” refusal.
3. Create a consumer-owned assignment and strict read/report-only instance.
4. Have a deterministic adapter place a sanitized activity snapshot in the
5. Create a consumer-owned assignment and strict read/report-only instance.
6. Have a deterministic adapter place a sanitized activity snapshot in the
target repo or artifact input; do not expose general Telegram credentials to
the model session.
5. Register an activity-core weekly definition that emits an `agent-session`
7. Register an activity-core weekly definition that emits an `agent-session`
run with explicit assignment and duty identity.
6. Run through rein-aharness, producing only a local report commit.
7. Require human review and measure correctness, provenance, usefulness,
8. Run through rein-aharness, producing only a local report commit.
9. Require human review and measure correctness, provenance, usefulness,
false assertions, runtime, tokens, and escalation quality.
8. Complete five clean scheduled/forced cycles before removing any manual
10. Review goal progress and envelope burn through agentic-resources; reallocate
or pause if marginal value is poor or leadership priorities change.
11. Complete five clean scheduled/forced cycles before removing any manual
fallback or considering a write-capable duty.
Only after the observation/reporting pilot is stable should the system add
@ -310,6 +512,10 @@ For this system, fully automated should mean:
- work is emitted once, claimed safely, and retried within policy;
- the exact role, duty, blueprint, target, runtime, and policy versions are
known before execution;
- the run traces to a leadership-owned goal, accountable owner, active mandate,
and unexpired resource envelope;
- portfolio and per-run financial/token/time/attention constraints are checked,
with unknown never treated as unlimited or zero;
- the agent receives bounded context and tools;
- success is verified against an explicit output/evidence contract;
- results and costs are correlated and reviewable;
@ -322,19 +528,26 @@ while only its safe, explicitly assigned duties are automated.
## Recommended implementation order
1. **Ownership decision:** confirm role-engine as definition source and choose
the assignment/binding owner and canonical name.
2. **Contracts:** role revision metadata, RoleAssignment v1, role-to-blueprint
coverage, and structured `ops_run` execution context.
3. **Adapters and validation:** kaizen compiler/scaffolder plus explicit
role-agent intake in rein-aharness.
4. **Read-only pilot:** Community Manager weekly health brief, human-reviewed,
five clean cycles.
5. **Production controls:** dashboards, alerts, retry/dead-letter policy,
1. **Ownership decisions:** confirm role-engine as definition source,
agentic-resources as agent-workforce/assignment owner, and the contextual
leadership source for goals and mandates.
2. **Governance contracts:** StrategicGoal, LeadershipMandate,
ResourceEnvelope, RoleAssignment, role-to-blueprint coverage, and structured
`ops_run` execution context.
3. **Constraint integration:** consume fin-hub budget/viability signals,
resource-control capacity evidence, and organization attention/autonomy
policy without duplicating their authority.
4. **Adapters and validation:** Kaizen compiler/scaffolder, agentic-resources
allocator, and explicit role-agent intake in rein-aharness.
5. **Read-only pilot:** Community Manager weekly health brief, human-reviewed,
goal- and budget-correlated, for five clean cycles.
6. **Production controls:** dashboards, alerts, retry/dead-letter policy,
pause/rollback, version canary, secret-route/policy audit.
6. **Improvement closure:** use measured pilot evidence to version and canary a
blueprint refinement without rewriting the source role contract.
7. **Improvement closure:** use measured pilot evidence to rebalance the agent
portfolio and version/canary a blueprint refinement without rewriting the
leadership goal or source role contract.
This route reuses the platform that is already live, preserves each
repository's stated intent, and concentrates new work on the one genuinely
missing capability: governed role assignment and binding.
repository's stated intent, and concentrates new work on the genuinely missing
capability: goal-directed, leadership-accountable, budget-constrained agent
workforce allocation.

View file

@ -0,0 +1,81 @@
---
id: KAIZEN-WP-0013
type: workplan
title: "Agent workforce, goal, leadership, and budget governance"
domain: agents
repo: kaizen-agentic
status: finished
owner: codex
topic_slug: custodian
created: "2026-08-20"
updated: "2026-08-20"
---
# KAIZEN-WP-0013 — Agent workforce, goal, leadership, and budget governance
## Assess sibling resource-management repositories
```task
id: KAIZEN-WP-0013-T01
status: done
priority: high
```
Review agentic-resources and human-resources intent, scope, workplans, and
implementation evidence, plus authoritative budget and resource-control
boundaries.
**Result:** agentic-resources is not intent-only: it implements a tested
multi-agent session capture, pattern curation/distribution, measurement, and
retrospective loop. Its root SCOPE is stale and it does not yet implement agent
assignments, goal allocation, or portfolio budgets. Human-resources remains a
planning/workflow-registry scaffold. Fin-hub owns budgets and viability signals;
resource-control owns technical resource and cost evidence.
## Define goals, leadership, and constrained allocation model
```task
id: KAIZEN-WP-0013-T02
status: done
priority: high
```
Extend the role-agent readiness architecture with explicit organizational
goals, leadership/accountability, agent-workforce allocation, and layered
financial, resource, token, time, and attention constraints.
**Result:** the assessment now defines a leadership-to-workforce control spine,
StrategicGoal, LeadershipMandate, ResourceEnvelope, RoleAssignment, and
AgentInstance separation, layered constraint authority/enforcement, and a
goal/budget-correlated pilot path.
## Reconcile KaizenAgentic ecosystem scope
```task
id: KAIZEN-WP-0013-T03
status: done
priority: medium
```
Update SCOPE ownership mappings so agentic-resources, human-resources, fin-hub,
resource-control, and organization-specific leadership sources are represented
without moving their responsibilities into kaizen-agentic.
**Result:** SCOPE now maps organization leadership, role-engine,
agentic-resources, human-resources, fin-hub, resource-control, activity-core,
and rein-aharness to distinct ownership concerns.
## Validate and close out
```task
id: KAIZEN-WP-0013-T04
status: done
priority: medium
```
Run repository checks, synchronize generated work records and State Hub, record
the findings, and close the workplan.
**Result:** full pytest, `make release-check`, `make agents-validate`, and
`git diff --check` pass. State Hub consistency and production UUID registration
are handled through the normal closeout path.