kaizen-agentic/docs/assessments/2026-08-20-intent-role-automation-readiness.md

INTENT Alignment and Role-Agent Automation Readiness

Date: 2026-08-20

Workplan: KAIZEN-WP-0012

Execution-boundary update, 2026-08-21: This assessment captured the then-live activity-core → rein-aharness intake path. GLAS-WP-0004 subsequently proved contract 1.0 across two rein/model constellations. Kaizen blueprints and agent instances should now hand a versioned harness_profile_ref to glas-harness rather than encode a concrete rein, provider, model, or sandbox. Scheduling remains with activity-core and task/blueprint intake remains caller- or rein-local; the assessment's ownership and budget findings remain valid.

Assessment: materially aligned, operationally useful, not yet at the full INTENT.md maturity target

Executive assessment

KaizenAgentic has grown beyond the prompt library described by the previous SCOPE.md. It now provides most of the blueprint and improvement-contract layer required by INTENT.md: versioned agent definitions, project memory, protocols, execution metrics, feedback, optimizer recommendations, schedule manifests, preparation bundles, engagement conventions, and a pilot Role package.

The strategic boundary remains sound. KaizenAgentic should not absorb runtime, scheduling, credentials, authorization, or durable task lifecycle. Those pieces now exist elsewhere:

• role-engine defines organizational roles;
• activity-core schedules activity and emits durable claimable ops_run work;
• rein-aharness claims work and runs governed agent sessions;
• llm-connect supplies provider-neutral model execution;
• identity, OpenBao/credential routing, and policy systems control access;
• State Hub and repo-local .kaizen/ state retain coordination and improvement evidence.

The missing link is a governed, machine-readable chain from a role definition 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

No repository, service, or contract named role-manager was found in the workspace on 2026-08-20. The current role-definition repository is role-engine; its INTENT.md is still marked Draft.

This matters because role-engine's INTENT.md explicitly says:

• roles are not identities;
• role definitions do not grant permissions;
• live assignment, scheduling, and workflow execution are out of scope;
• 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.” 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

INTENT commitment	Current evidence	Assessment
Canonical mission and operating model	INTENT.md, wiki, ADRs, agency and engagement documents	Strong
KaizenAgent definition template	Template exists; authoring/docs CLI and 20 packaged definitions exist	Partial: the reference fleet still uses less structure than the full template
Meta-optimizer concept	OptimizationLoop, metrics summaries, metrics optimize, feedback and correlation	Strong foundation; refinement approval/version rollout is not closed-loop
Measurable behavior	Execution JSONL, summaries, engagement metrics, event and artifact publication	Implemented, but coverage depends on callers recording closeout evidence
Idempotent behavior	Idempotency keys exist in engagement closeout and downstream ops_run; validation is repeatable	Partial: generic blueprint definitions do not yet declare convergence/idempotency semantics uniformly
Codebase improvement guidance	Specialized agents, protocols, templates, tutorials, integration patterns	Useful reference implementation; machine-checkable guidance model remains incomplete
Relationship among prompts, experiments, mantras, agents, capabilities	Conceptual material and capability metadata exist	Partial: relationships are documented more than schema-validated
Product, pricing, revenue, and brand framing	Agency model, Role packages, Kai pilot settlement, wiki framing	Present at pilot level; not yet a repeatable commercial operating system
Versioned, testable, reversible units	Package releases, Git history, tests, Role version, ADRs	Strong for code and packages; blueprint compatibility/pinning needs a formal contract
Define → deploy → measure → refine → commercialize	Define/deploy/measure are operational; refine and commercialize have working pieces	Maturity target not yet complete

Design-principle fit

• Continuous improvement: directly represented in metrics, feedback, memory, optimization, and engagement closeout.
• Measurable by default: supported by tooling, but not yet mandatory in every agent definition or automated run result.
• Idempotent operations: present in selected workflows, not expressed as a required blueprint field or verified per duty.
• Evidence over intuition: strong conventions and event/artifact paths exist; optimizer recommendations still require a clearer promotion gate.
• Separation of concerns: strong and increasingly proven by the activity-core / rein-aharness split.
• Composable capabilities: agents, protocols, memory, schedules, Roles, and integrations are composable, though their shared schema is fragmented.
• Human-readable and machine-executable: human-readable coverage is strong; role-engine roles are not yet machine-readable enough for safe compilation.
• Rollback-ready evolution: Git/package rollback exists; assignment, blueprint pinning, and canary policy need standardization.
• Compounding value: evidence can accumulate, but automatic evidence → approved blueprint revision → controlled rollout is not closed.

What already works end to end

The ecosystem has the following proven backbone:

activity-core Temporal schedule/event
        │
        ▼
rule action → durable ops_run (idempotent, lease/claim/retry)
        │
        ▼
rein-aharness claim-loop → approach selection
        │
        ▼  labels/approach_hint = agent-session
repo instance policy → kaizen-agentic schedule prepare
        │
        ▼
bounded LLM session → local commit verification
        │
        ▼
ops_run result + State Hub progress + .kaizen metrics

Important existing controls include:

• unique per-fire ops_run idempotency keys;
• atomic claim with lease, heartbeat API, retry, and terminal failure;
• target-repository mapping on the harness host;
• named tool profiles, autonomy lanes, token budgets, and harness-major pins;
• offline blueprint/memory/metrics preparation;
• local commit verification and no-push runtime policy;
• completion metadata and artifact links in activity-core;
• per-agent metrics and State Hub progress reporting.

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:

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

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
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;
• duty selection: only the role duties delegated to this agent;
• 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;
• start/end dates, pause/disable switch, owner, and rollback revision.

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 after agreeing the consumer need.
2. Structure at least duties, cadence suggestions, decision rights, escalations, interfaces, and success evidence.
3. Preserve the human-readable role contract as authoritative.
4. Do not add assignment, credentials, or scheduling merely to make the catalog look executable.

kaizen-agentic

1. Define a role_ref and duty-coverage mapping for executable Role packages.
2. Reconcile the local roles/<id>/ROLE.yaml concept with role-engine: the 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, 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, 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.

activity-core

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, 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 (assignment, duty, target, scheduled fire).
5. Keep prompts, credentials, and raw model output out of ops_run records.

rein-aharness

1. Keep runtime, credentials, policy enforcement, and claim execution ownership.
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; 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, 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 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:

version: "2"
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
      revision: "<immutable-git-revision>"
    blueprint_ref:
      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
        run_budget_tokens: 40000
        run_timeout_seconds: 900
        exhaustion: defer-and-report
        approval: none
      publication-draft:
        cadence: weekly
        enabled: false
        expected_output: outbox/community-update-YYYY-MM-DD.md
        lane: green
        tool_profile: community-draft-only
        run_budget_tokens: 30000
        approval: human-before-publish

The assignment compiler could initially render this into the current v1 .kaizen/schedule.yml plus an activity-core definition. Moving the base schedule schema to v2 should happen only after kaizen-agentic, activity-core, and rein-aharness agree the fields and compatibility path.

Recommended first pilot

Use role-engine's only current role, community-manager, but automate a narrow, low-risk duty rather than claiming the entire role is autonomous.

Pilot duty: produce a weekly community-health brief from an approved, read-only snapshot of community activity.

Why this duty: it exercises role revision, assignment, scheduled intake, blueprint preparation, evidence metrics, and escalation without granting publishing, moderation, sanctions, membership, or direct messaging authority.

Pilot sequence:

1. Pin the role-engine revision and identify which Community Manager success criteria the brief measures.
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.
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.
7. Register an activity-core weekly definition that emits an agent-session run with explicit assignment and duty identity.
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.
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 drafting to a human-reviewed outbox. Automatic publishing or moderation should remain separate, more privileged duties with explicit policy and approval.

Operational definition of “fully automated”

For this system, fully automated should mean:

• the schedule/event fires without a person;
• an eligible assignment resolves deterministically;
• 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;
• refusal, escalation, pause, rollback, and lease recovery work without manual database repair.

It should not mean that every responsibility in a human role is delegated or that role wording grants technical authority. A role can be fully scheduled while only its safe, explicitly assigned duties are automated.

Recommended implementation order

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.
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 genuinely missing capability: goal-directed, leadership-accountable, budget-constrained agent workforce allocation.