coulomb/rein-aharness
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
rein-aharness/docs/adr/ADR-001-agent-harness-architecture.md
tegwick cfc1b75157 Harness foundation: INTENT, ADR-001, architecture, prototype adoption 
- INTENT.md: three-layer model (blueprint/instance/harness), single
  shared runtime, never-become boundaries
- ADR-001 (accepted): DEC-2026-002 resolution — one harness repo for
  all projects; instances are declarative state in consuming repos
- docs/architecture.md: components, contracts (manifest, tool
  profiles, completion events, credential lanes), deployment shape
- agent_harness/: executor-worker prototype adopted and renamed
  (6/6 tests green); HARNESS-WP-0001 initial workplan (7 tasks)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-17 23:35:27 +02:00

2.5 KiB
Raw Permalink Blame History

id title status date
ADR-001 Single shared agent harness; instances are declarative state in consuming repos accepted 2026-07-17

ADR-001 — Single shared agent harness

Status

Accepted (DEC-2026-002, binky-control DecisionQueue, resolved by Bernd 2026-07-17; hub decision 63620255-59d0-4109-bdee-4d0644c450e5).

Context

Unattended agentic work needs blueprints (kaizen-agentic), compute (llm-connect), scheduling (activity-core), credentials, policy, memory, and reporting — a complex, rapidly evolving combination. The candidate homes for the execution runtime all had disqualifying boundaries in their ratified INTENT files: activity-core "does not execute the work"; kaizen-agentic does no scheduling and no LLM invocation; llm-connect is an interface layer. Per-project executor repos would multiply glue code and upgrades linearly with agent count. The concrete trigger: binky- control's operating rhythm depended on a workstation cron bridge (BINKY-WP-0004).

Decision

  1. One new repo — agent-harness — is the single shared agent runtime for all projects. No further runtime repos per agent or per project.
  2. Agent instances live in consuming repos as declarative state only (manifest + .kaizen/ memory/metrics): blueprint reference, cadence, lane, named tool profile, budget, pinned harness major. No code, no credentials, no tool enumerations.
  3. Blueprints stay in kaizen-agentic; scheduling stays in activity-core; provider abstraction stays in llm-connect. The harness consumes all three and is the only credential holder and policy enforcement point for agent sessions.
  4. The 2026-07-17 executor-worker prototype is adopted as the harness seed (agent_harness/ package). binky-control is tenant #1.

Details: docs/architecture.md.

Consequences

  • Adding an agent to any project = editing that project's manifest; onboarding a project = committing one manifest.
  • Base-technology evolution (adapters, tool policies, credential mechanics) lands once, here — instances upgrade by version bump.
  • The harness becomes a critical shared service: it needs its own versioning discipline, conformance tests, and kaizen measurement.
  • BINKY-WP-0004-T06 (cron-bridge cutover) now gates on this repo's Railiance deployment instead of a binky-specific worker.
  • Repo-boundary discipline continues: any pressure to add scheduling, blueprint authoring, or tenant-specific logic here is a signal to extend the neighbor repo or the instance model instead.