---
id: ADR-001
title: Single shared agent harness; instances are declarative state in consuming repos
status: accepted
date: "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](../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.