tegwick
8e700c07de
Repo-identity rename only (directory, git remote, pyproject name, self-referencing docs). CLI/package/deploy rename tracked separately in REIN-A-WP-0002-T02 since it touches a live Railiance deployment. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
78 lines
3.9 KiB
Markdown
78 lines
3.9 KiB
Markdown
# INTENT
|
|
|
|
> This file explains why agent-harness (repo renamed `rein-aharness`, see
|
|
> glas-harness ADR-001) exists — the problem it solves, the principle that
|
|
> governs its boundaries, and what it must never become. Established by
|
|
> DEC-2026-002 (binky-control DecisionQueue, resolved 2026-07-17) and
|
|
> ADR-001 in this repo.
|
|
>
|
|
> **Naming note (post-rename):** this repo is one of possibly several
|
|
> **reins** — concrete harness implementations for different operating
|
|
> circumstances, analogous to how "rails" name different workload
|
|
> operations models. glas-harness is the meta-framework that routes
|
|
> between reins; `rein-aharness` is the Claude-Code-CLI-based rein for
|
|
> governed, unattended/scheduled tenant work. See
|
|
> `../glas-harness/docs/adr/ADR-001-rein-harness-family.md`.
|
|
|
|
## Why it exists
|
|
|
|
Agentic work in the ecosystem requires combining many rapidly evolving
|
|
ingredients: agent blueprints (kaizen-agentic), LLM compute (llm-connect),
|
|
scheduling (activity-core), credentials (OpenBao/ops-warden), policy gates
|
|
(net-kingdom/flex-auth), memory (phase-memory, `.kaizen/` state), and
|
|
reporting (Custodian State Hub). Without a shared runtime, every project
|
|
that wants unattended agents must re-wire all of this — and every base-
|
|
technology shift multiplies into N project upgrades. The first concrete
|
|
casualty: binky-control's daily rhythm depended on a workstation cron
|
|
bridge because no workstation-independent runtime existed.
|
|
|
|
agent-harness exists so that **any project can run governed, unattended
|
|
agent instances by committing a small declarative manifest — while all the
|
|
fast-evolving wiring lives, evolves, and is enforced in exactly one
|
|
place.**
|
|
|
|
## The governing principle: three layers
|
|
|
|
1. **Blueprint (class)** — owned by kaizen-agentic. Versioned, reusable,
|
|
centrally improved agent definitions.
|
|
2. **Instance** — owned by the consuming repo. Declarative state only:
|
|
which blueprints run, cadence, autonomy lane, named tool profile,
|
|
budget, plus `.kaizen/` memory and metrics. Never code, never
|
|
credentials, never tool wiring.
|
|
3. **Harness (runtime)** — this repo. The single shared, multi-tenant
|
|
runtime: consumes tasks emitted by activity-core, loads the blueprint
|
|
(ADR-005 `schedule prepare`), binds instance state, acquires
|
|
credentials, runs the bounded agentic session via llm-connect,
|
|
verifies the local commit, reports to the State Hub and to the
|
|
instance's kaizen metrics.
|
|
|
|
The harness is the **only credential holder and the only policy
|
|
enforcement point** for agent sessions. Instances declare policy; the
|
|
harness enforces it. Instances pin a harness major version; upgrades
|
|
happen centrally.
|
|
|
|
## Strategic role
|
|
|
|
This is the "federated execution" half of the hub-and-spoke AgentOps
|
|
model (agentic-resources intent): central standards and runtime, per-repo
|
|
instances. It closes the gap the other repos deliberately leave open —
|
|
activity-core answers when/what/where and *does not execute*;
|
|
kaizen-agentic declares and prepares and *does not invoke LLMs*;
|
|
llm-connect abstracts providers and *does not orchestrate*.
|
|
|
|
## What it must never become
|
|
|
|
- **Not a scheduler.** Triggering and task emission stay in
|
|
activity-core. The harness only consumes.
|
|
- **Not a blueprint author.** Agent definitions, measurement conventions,
|
|
and improvement loops stay in kaizen-agentic.
|
|
- **Not a per-project logic container.** Anything specific to one tenant
|
|
belongs in that tenant's manifest or blueprint — the harness stays
|
|
generic or the instance model has failed.
|
|
- **Not an LLM abstraction.** Provider handling stays in llm-connect.
|
|
- **Not a state store.** Run history, task lifecycle, and decisions live
|
|
in the State Hub; agent memory lives with the instance (and later
|
|
phase-memory profiles).
|
|
- **Not autonomous beyond its grant.** Sessions run under named tool
|
|
profiles with hard allow-lists; the harness never pushes beyond the
|
|
target repo grant and never widens its own permissions.
|