From 6075ecfaba2e645b864d07bd9dc25d15735126d9 Mon Sep 17 00:00:00 2001 From: Claude Date: Sun, 30 Aug 2026 22:49:41 +0000 Subject: [PATCH] docs: hand off Lousy Agents research into Agent OS (docs only) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Split the two decision-record docs out of the draft experiment branch (PR #83) so the settled research lands on main while the paid experiment harness stays behind issue #85's do-not-merge guardrail. Review fixes applied in place: - lousy-agents-handoff.md: reword the redgate suggested-skills line to the merged #82 boundary — compose redgate around the applicable specialist; it reinforces execution, it does not own the domain procedure. - automation-curation-lens.md: sync the Redgate framing to #82's merged vocabulary (working harness/protocol layer, verification/gating envelope, specialist-first). - automation-curation-lens.md: add the missing multiplicity legend for the relationship diagram (unresolved Copilot review finding on Adapter+). - automation-curation-lens.md: pin the DESIGN_EVIDENCE.md link to the experiment branch commit, since the harness does not land with this docs-only change. - verified no stale .Agent tokens remain in either doc. Part of #83; relates to #84 #85. Co-Authored-By: Claude Fable 5 Claude-Session: https://claude.ai/code/session_01NsPQTo67oovz8ogirsH6uL --- .../agent-os/automation-curation-lens.md | 458 ++++++++++++++++++ .../research/agent-os/lousy-agents-handoff.md | 95 ++++ 2 files changed, 553 insertions(+) create mode 100644 docs/research/agent-os/automation-curation-lens.md create mode 100644 docs/research/agent-os/lousy-agents-handoff.md diff --git a/docs/research/agent-os/automation-curation-lens.md b/docs/research/agent-os/automation-curation-lens.md new file mode 100644 index 00000000..7aee508f --- /dev/null +++ b/docs/research/agent-os/automation-curation-lens.md @@ -0,0 +1,458 @@ +# Agent OS integration lens: automation curation + +## Decision + +Agent OS is a **design and control plane for agent automations**. It guides the +creation, classification, composition, and ongoing curation of automations and +reusable recipes around workflows. It is not another agent runtime and it is +not a replacement for the working disciplines used while an agent executes a +task. + +Harness-native scheduled tasks, GitHub workflows, Claude Code loops, Codex +jobs, Copilot agents, and future automation surfaces are observed/projected +through adapters. Agent OS gives them stable human-facing identity, +relationships, recipes, and desired evidence contracts. + +**Redgate is deliberately a different layer.** Redgate is a working +harness/protocol layer — a verification/gating envelope composed around the +most-specific applicable specialist, not the universal router: it reinforces +falsifiable criteria, ARM/TRACE/JUDGE, independent verification, scope/attempt +discipline, and classified human gates, while the specialist owns the domain +procedure. An Agent OS Recipe or Automation may recommend or use Redgate as an +execution policy, but Agent OS does not depend on Redgate for its taxonomy, +recipe authoring, interactive curation, or portability. + +## The invariant + +Every independently-running automation has one stable human-facing identity: + +` .: ` + +Rules: + +- The **lane key is the namespace** and stays short and distinct: `Blog`, `Gov`, `Ops`, `Meta`, etc. +- Numbering resets within each lane. +- The first number identifies a workstream inside the lane. +- The second number identifies an independently scheduled/triggered automation slot inside that workstream. +- The display token `.Automation` is an operator-facing convention for that independently-running slot; it is **not** the same semantic object as an Actor compiled by `agent-compiler`. +- Internal subagents do **not** get hierarchy numbers unless they independently run. +- New lanes are earned by distinct recurring work, not created speculatively. +- Stable names stay stable while their meaning remains valid; curation should reduce churn, not produce it. + +Example shape: + +```text +Blog 1.1: Editorial +Blog 1.2: Projects +Blog 1.3: Direction +Gov 1.1: Curator +Ops 1.1: Plugin Sync +Meta 1.1: Curator +Meta 1.2: Skill Sync +``` + +The concrete lane vocabulary is evolvable. The durable thing is the +namespacing rule and the relationship it encodes. + +## Smallest useful automation ontology + +Do not import every physical construct from every harness into the canonical +model. Start with seven semantic concepts: + +1. **Lane** — human-facing domain namespace. +2. **Workstream** — related automations inside a lane. +3. **Automation** — one independently triggered execution contract. +4. **Trigger** — schedule, event, or condition that starts an automation. +5. **Recipe** — reusable workflow blueprint that can be invoked by a human or bound into one or more Automations; a Recipe is not independently scheduled by definition. +6. **Adapter** — projection/reconciliation boundary between Agent OS and a harness-native representation. +7. **Evidence** — run/output/verification material used to judge health and drive future curation. + +Canonical relationships: + +```text +Lane + -> contains Workstream + -> contains Automation + -> triggeredBy Trigger + -> follows Recipe* + -> dependsOn Automation* + -> feeds Automation* + -> projectedVia Adapter+ + -> emits Evidence* +``` + +Multiplicity in this diagram: `*` means zero or more; `+` means one or more — +every Automation is projected via at least one Adapter. + +`dependsOn` is the blocking/ordering relationship. `feeds` is a looser data or +artifact handoff that does not necessarily block execution. Do not infer these +relationships only from clock spacing; schedules are an adapter mechanism, not +the semantic dependency graph. + +Treat **Actor/agent** as an execution participant of an Automation or Recipe in +v1, not a competing top-level identity. `agent-compiler` owns deterministic +Actor composition. Agent OS owns why/when that Actor runs and how the resulting +automation fits the portfolio. + +Likewise, keep these out of the v1 top-level ontology unless evidence forces +promotion: + +- `Policy` is a constraint/property on nodes or relationships. +- `Capability` is a requirement/provision edge used by recipes/adapters. +- `ExecutionPolicy` is a Recipe/Automation property naming optional working disciplines such as Redgate; it does not need a top-level node in v1. +- `Memory` is curated state/evidence, not a universal bucket. +- `Runtime` is adapter/run metadata. +- native `AGENTS.md`, `CLAUDE.md`, Copilot instructions, workflow YAML, hooks, and MCP servers are projections or referenced capabilities, never canonical taxonomy nodes merely because they are files. + +## Recipe versus adjacent concepts + +Keep the distinctions explicit so adapters do not collapse everything into +"agent": + +| Concept | Agent OS meaning | +|---|---| +| **Recipe** | Reusable workflow blueprint: ordered/conditional steps, capabilities, suggested skills, evidence expectations, and optional execution policies. No independent trigger. | +| **Automation** | A deployed/bound execution contract: identity + trigger + one or more recipes + adapter + relationships + expected evidence. | +| **Workflow** | A harness-native execution graph or implementation detail that may project a Recipe/Automation, e.g. GitHub Actions YAML or a Claude/Codex workflow. | +| **Skill** | Reusable behavioral capability/procedure a Recipe may call or recommend. Agent OS does not become the global skill router. | +| **Actor/Agent** | Execution participant. Actor composition and compiled AgentImage identity belong to `agent-compiler`; an Automation may bind one or more Actors independently of its Recipe binding. | + +A Recipe can say, for example, "use `diagnosing-bugs` for diagnosis and use +`redgate` as the execution policy once the build loop begins" without Agent OS +reimplementing either skill. + +Sharing one compiled Actor or AgentImage across two jobs does not make those +jobs one Automation. If they can be triggered, managed, or evidenced +independently, they retain two Automation identities even when they bind the +same Actor and follow the same Recipe. + +## Layer model + +```text +Agent OS Redgate +DESIGN / CONTROL PLANE WORK / HARNESS PLANE +---------------------- -------------------- +automation taxonomy execution discipline +recipe authoring falsifiable criteria +trigger/dependency design ARM / TRACE / JUDGE +adapter projection independent verification +portfolio curation classified human gates +interactive automation design scope / attempts / rollback discipline + + optional composition +Automation / Recipe -----------> executionPolicy: redgate +``` + +Agent OS remains useful when Redgate is not installed. Redgate remains useful +for ordinary project work that has nothing to do with automation design. + +## Lane boundary: `Gov` versus `Meta` + +Keep this distinction hard: + +- **Gov** governs the user's content/workspace/project portfolio: lifecycle, taxonomy of projects, privacy boundaries, archive/delete recommendations, and related knowledge hygiene. +- **Meta** governs the automation system itself: lane taxonomy, job design, overlap, cadence, tool discovery, dependencies, reliability, and synchronization of Agent OS guidance. + +This prevents a workspace curator from silently gaining authority to rewrite +the machinery curating it. + +## Three truths and reconciliation + +Do not create a fake single source of truth for cross-harness automation. +There are three different truths: + +1. **Design truth — Agent OS desired model.** Stable identity, lane/workstream placement, recipes, dependency edges, adapter intent, privacy boundary, and expected evidence. +2. **Existence truth — live harness state.** What jobs, schedules, triggers, permissions, and native artifacts actually exist right now. +3. **Runtime truth — evidence.** What actually ran, mutated, verified, failed, or produced an output. + +Adapters reconcile design truth against existence truth; evidence tests whether +the resulting automation behaves as intended. Drift is a first-class finding, +not something to silently overwrite in either direction. + +Reconciliation should classify differences as: + +- **expected projection difference** — native harness representation differs but semantics match; +- **design drift** — live job changed away from desired Agent OS intent; +- **observed improvement** — live state contains a useful change that should be proposed back into design truth; +- **orphan** — live automation has no Agent OS identity yet; +- **missing projection** — desired automation has no live harness representation; +- **unverified** — projected state exists but runtime evidence is insufficient. + +Mutation remains human-gated unless a narrower policy explicitly authorizes a +class of low-risk reconciliation. + +Every reconciliation response should make its boundary reviewable by showing: + +1. the desired edge or state; +2. the observed live edge or state; +3. the difference classification; +4. the proposed design diff; +5. the proposed live diff, if any; +6. the evidence needed to verify the result; and +7. the approval boundary before either truth is changed. + +An observed difference is not permission to rewrite design truth, and stale +design is not permission to mutate the live harness. + +## Meta loop + +The canonical automation-curation loop is: + +```text +discover -> normalize -> reconcile -> diagnose -> propose diff -> grill -> apply approved diff -> verify -> record evidence +``` + +### Discover + +Inspect the actual automation inventory and currently available +tools/connectors/capabilities. Prefer native read APIs over remembered task +lists. Discovery should also find newly available capabilities that could +remove recurring manual work. + +### Normalize + +Map harness-native jobs into Lane / Workstream / Automation / Trigger / Recipe / +Adapter / Evidence without erasing native escape hatches. + +### Reconcile + +Compare the desired Agent OS model with live harness state and classify drift. +Do not silently make the desired model match whatever happens to exist, and do +not silently force live state to match stale desired intent. + +### Diagnose + +Look for: + +- duplicates and overlapping responsibilities +- repeated full rescans that should share a ledger +- bad sequencing or hidden race conditions +- missing or implicit dependency edges +- fixed schedules that should be condition watches +- noisy notification policies +- stale/completed jobs +- work that is too broad and should split, or too narrow and should merge +- naming/numbering drift +- public/private boundary leaks +- unverified jobs whose effectiveness cannot be demonstrated +- opportunities to convert rediscovery into persistent state + +### Propose diff + +Express changes as explicit operations: create / rename / merge / split / +retire / reschedule / change trigger / change notification policy / change +dependency / change recipe binding / change execution policy. Prefer a small +high-value diff over perpetual reorganization. + +### Grill + +Structural changes remain human-gated. Agent OS supplies the automation-domain +decision tree. Compose the existing `grill-me` interaction model rather than +inventing a second generic interview protocol. + +### Apply + +Only approved operations mutate harness-native automation surfaces. Redgate may +be used while implementing a nontrivial approved change, but it is an optional +working discipline at this phase, not Agent OS's control plane. + +### Verify + +Re-read the resulting inventory and confirm the proposed +relationships/schedules actually exist. Where available, inspect execution +evidence instead of accepting self-reported completion. + +### Record evidence + +Persist enough state that the next curator run can operate on deltas instead of +rediscovering the world. + +## Progressive disclosure: the `agent-os` skill + +The eventual `agent-os` plugin should be deliberately small at the front door. + +### Main skill owns only + +- the lane/workstream/automation taxonomy +- the naming invariant +- the minimal ontology, including blocking `dependsOn` versus non-blocking `feeds` +- Recipe versus Automation and Actor versus Automation distinctions +- sibling capability boundaries +- recipe routing +- the compact authority boundary: Gov governs user content; Meta governs + automation machinery; neither silently gains the other's authority +- the human-gated mutation rule +- the safety invariant that desired design and observed live state stay separate; + reconciliation emits a proposed diff that requires approval +- the safety invariant that Adapter capability starts `unassessed`; after + discovery without enough evidence it is `unverified`; assign a capability + rating only when current evidence supports it + +Deep `Gov`/`Meta` ownership guidance (beyond that compact boundary), the full +curation loop, reconciliation classification and response contract, the +Adapter capability matrix, and interactive portfolio mechanics live as +progressively disclosed recipes/references. + +### Smoke evidence and context placement + +The one-sample [Agent OS context smoke](https://github.com/JRichlen/agent-plugins/blob/e35b7085084ea233df5744cae79387b8b6df0937/experiments/agent-os/DESIGN_EVIDENCE.md) +(the experiment harness lives on PR [#83](https://github.com/JRichlen/agent-plugins/pull/83)'s branch, not in this tree) +supports this placement provisionally. The +[workflow run](https://github.com/JRichlen/agent-plugins/actions/runs/33281138920) +and [raw artifact](https://github.com/JRichlen/agent-plugins/actions/runs/33281138920/artifacts/9723030558) +are the evidence authority. + +| Treatment | Mean lift over baseline | Context bytes | Placement signal | +|---|---:|---:|---| +| taxonomy | `+0.2833` | 1,696 | Useful, but collapsed two jobs in the compiled-participant scenario. | +| recipe-aware | `+0.3333` | 2,963 | Smallest treatment within `0.10` of the best score. | +| full Agent OS | `+0.4000` | 4,738 | Extra gain was concentrated in interactive curation, so route it there. | + +The score gap between recipe-aware and full was only `0.0667`, while full used +1,775 more context bytes. Twelve of 24 outputs hit the token ceiling, and the +live judge was not yet told which ones did. The judge showed strong score +centrality, manual review found hard failures it did not emit, and candidate +and judge were both Nemotron-family models. The result therefore supports +recipe-aware context plus the compact boundaries above; it does not justify a +canonical ontology change or wholesale default injection of the full contract. + +### Recipe set + +Proposed first recipes: + +| Recipe | Purpose | +|---|---| +| `classify-new-automation` | Decide lane/workstream/key, trigger type, dependencies, recipe bindings, and whether the work deserves its own automation at all. | +| `design-automation-recipe` | Turn a recurring workflow into a reusable Recipe before binding it to any schedule/harness. | +| `grill-my-automations` | Interactive choose-your-own-adventure audit of the current automation portfolio. | +| `dedupe-and-consolidate` | Find overlapping jobs, shared ledgers, merge/split opportunities, and better sequencing. | +| `health-audit` | Diagnose stale/noisy/unverified automations and evidence gaps. | +| `reconcile-desired-and-live` | Compare desired and observed state, classify differences, propose separate design/live diffs, and preserve the approval boundary. | +| `tool-scout` | Discover available tools/connectors and propose automations grounded in repeated work or a clear system gap. | +| `bootstrap-portfolio` | First-run inventory and taxonomy normalization without assuming existing structure is correct. | +| `sync-agent-os-skill` | Diff durable taxonomy/design against the public skill and propose a review-gated update only when meaningfully changed. | + +Recipes are not automatically scheduled agents. A scheduled task may follow a +Recipe, but the Recipe itself stays reusable and harness-portable. + +## Interactive management: `grill-my-automations` + +The desired experience is a choose-your-own-adventure book crossed with an +interactive terminal. + +Do **not** emit a wall of open-ended questions. + +Interaction contract: + +1. Infer and show the current portfolio map first. +2. Find the highest-leverage unsettled automation-design branch. +3. Prefer the harness's native structured question/choice primitive when one exists. Discover the primitive available in the current harness; do not invent a canonical tool name. +4. Present compact single-select or multi-select options with a recommended route. +5. Let the answer reveal the next branch. +6. Repeat until the user chooses to stop or the design frontier is empty. +7. End with a proposed Agent OS diff: taxonomy, recipes, dependencies, adapters, and/or automation mutations. + +When no native structured-question primitive exists, fall back to the same +compact option menu in text. Portability is behavioral, not dependent on a +specific UI API. + +`grill-my-automations` should **compose with `grill-me`**, not fork it: + +- Agent OS supplies the automation-domain decision tree and current inventory. +- `grill-me` supplies anchor/path-consent, stakes triage, frontier iteration, recommendations, and termination discipline. +- Agent OS itself decides which automation-design branches are low/high consequence. +- Redgate is not required for the interview. It may become relevant later if an approved design change is implemented through a nontrivial work loop. + +## Lousy Agents mapping + +Use Lousy Agents as prior art at these seams without copying its physical +taxonomy: + +| Lousy Agents idea | Agent OS automation use | +|---|---| +| Doctor | Portfolio-wide automation diagnosis and topology findings. | +| Lint | Deterministic naming/schema/trigger/adapter invariants. | +| Lessons | Candidate durable rules, promoted only after recurrence/evidence. | +| Agent shell telemetry | Independent run/action evidence where adapters can expose it. | +| Harness capability matrix | Honest adapter matrix: what each harness can discover, mutate, schedule, question, observe, and verify. | + +This also sharpens the distinction between **lint** and **curation**: lint +proves local invariants; the curator reasons about portfolio shape and proposes +changes. + +## Existing plugin boundaries + +Do not duplicate sibling plugins: + +- **`agent-compiler`** owns deterministic Actor/behavior composition. Agent OS may bind/request an Actor shape but does not recompile personas itself. +- **`grill-me`** owns generic interactive design-tree interrogation. Agent OS provides the automation-specific tree/recipes. +- **`redgate`** owns a working harness/protocol for verified iterative execution. Agent OS may recommend it as `executionPolicy` or use it while implementing a design, but does not depend on it. +- **`diagnosing-bugs`, `codebase-design`, `orchestrate`, `scope-fence`, etc.** remain specialist working capabilities a Recipe may recommend. Agent OS does not replace their routing logic. +- **`recurrence-detector`** turns repeated failure shapes into candidate invariants; Agent OS decides whether those belong in automation policy/taxonomy. +- **`docs-hygiene`** checks generated/propagated instruction surfaces against current repo reality. +- **`context-handoff`** keeps cross-session/harness continuation pointer-first. +- **`find-before-build`** remains the guard against creating a new automation/recipe/plugin when one already exists. + +## Skill-sync rule + +The public `agent-os` skill is a **projection of settled automation design**, +not the source of truth for a user's live automation inventory. + +Sync flow: + +```text +desired Agent OS model + latest Meta curator decisions + observed adapter state + -> extract durable principles + -> diff agent-os skill/recipes + -> validate + -> review-gated PR +``` + +No meaningful design change means no PR. Never copy private conversation +content, secrets, private project details, or transient task state into the +public skill. + +## Adapter capability matrix + +Before claiming cross-harness support, rate **each capability independently**; +do not give a harness one misleading overall support level. + +Dimensions: + +- discover existing automations +- read schedules/triggers +- read native workflow/config artifacts +- create/update/disable/delete automations +- represent dependency edges natively or by projection +- bind/import Recipes +- inspect recent run evidence +- distinguish self-report from external/runtime evidence +- emit condition watches +- ask structured interactive questions +- preserve human approval gates +- project/import the Agent OS taxonomy +- detect drift and re-read after mutation + +Every cell starts `unassessed`. After discovery but before enough current +evidence exists, it is `unverified`. Only then can it be rated `native`, +`partial`, `prose-only`, or `unsupported`, with a short adapter-specific note +and the evidence that supports the rating. Do not infer a rating from generic +harness reputation, a prose instruction, or the presence of a file. Claude +Code, Codex, GitHub Copilot, GitHub Actions, and scheduled-task systems should +be evaluated capability by capability. + +## Implementation order + +1. Land this automation-curation lens as the receiving-thread decision record. +2. Design the `agent-os` main skill around taxonomy + Recipe design/routing + the two compact safety invariants. +3. Implement `design-automation-recipe` and `grill-my-automations` as the first progressively disclosed workflows. +4. Add the targeted reconciliation recipe/reference and its explicit response contract. +5. Add deterministic cheap checks for the naming invariant, independent Automation identity, dependency relationship vocabulary, progressive-disclosure links, and sibling-plugin boundaries. +6. Add an evidence-backed Adapter capability matrix before promising cross-harness mutation support. +7. Only then wire actual harness mutation adapters/tool schemas. +8. Add optional execution-policy guidance (including Redgate) without making any one harness discipline mandatory. + +The first release should be useful even when it can only **discover, classify, +design recipes, diagnose, reconcile, and propose**. Mutation and execution +policy support can deepen adapter by adapter without changing the canonical +taxonomy. diff --git a/docs/research/agent-os/lousy-agents-handoff.md b/docs/research/agent-os/lousy-agents-handoff.md new file mode 100644 index 00000000..ac300fd7 --- /dev/null +++ b/docs/research/agent-os/lousy-agents-handoff.md @@ -0,0 +1,95 @@ +# Agent OS handoff: zpratt/lousy-agents + +## Live thread + +Research into `zpratt/lousy-agents` should shape Agent OS as prior art, not as a fork target. + +Primary source: https://github.com/zpratt/lousy-agents + +Key seams to inspect in the live source: + +- `docs/doctor.md` and `packages/doctor/` for multi-harness discovery, topology, archetype classification, CI diagnostics, and intent/capability evaluation. +- `docs/lint.md` and `packages/lint/` for construct-level validation. +- `docs/lessons.md` for durable lesson injection/capture. +- `packages/agent-shell/` for independent execution telemetry and command-policy evidence. +- `docs/product/harness-capability-matrix.md` for explicit support depth across harnesses. +- Issue #890, Agentic Configuration Doctor: https://github.com/zpratt/lousy-agents/issues/890 + +The architectural implication to test is: + +> Agent OS should operate one semantic layer above harness configuration. Native constructs such as AGENTS.md, CLAUDE.md, Copilot instructions, skills, agents, hooks, MCP servers, and scheduled tasks should be projections/adapters of a canonical capability graph rather than the canonical ontology itself. + +Candidate semantic concepts to challenge, shrink, or replace: + +- Capability +- Actor +- Behavior +- Knowledge +- Policy +- Workflow +- Trigger +- Tool +- Memory +- Evidence +- Runtime + +Desired bidirectional model: + +1. **Discover** native harness artifacts and reconstruct a canonical graph. +2. **Diagnose** composition, drift, missing preconditions, and ambiguous intent. +3. **Govern** with deterministic lint/doctor/policy checks and evidence-backed findings. +4. **Compile** canonical intent back into Claude Code, Codex, GitHub Copilot, GitHub, and future adapters. +5. **Observe** runtime actions independently of agent self-report. +6. **Learn** from repeated findings and execution outcomes without letting memory become an uncurated dump. + +Do not blindly copy Lousy Agents' physical construct taxonomy. Its strongest reusable ideas are the construct graph, doctor-vs-lint split, explicit intent, capability preconditions, evidence-cited findings, lessons, telemetry, and honest harness capability matrix. + +### Integration lens: Agent instruction / MCP architecture + +Use this research to pressure-test the few-tools / discover-schema + execute model. Determine whether the canonical Agent OS graph can expose its schema and operations without MCP tool explosion. Focus on stable construct identity, relationship types, capability lookup, adapter discovery, and compile/discover operations. Avoid making filesystem conventions the API. + +### Integration lens: Agent OS taxonomy / skill sync + +Reconcile this with the existing cross-harness plugin model in this repo, especially `plugins/agent-compiler/`, `plugins/docs-hygiene/`, `plugins/context-handoff/`, `plugins/recurrence-detector/`, and `plugins/redgate/`. Decide which concepts become canonical, which remain generated harness projections, and whether `AGENTS.md` is source, compatibility contract, or generated view. + +### Integration lens: Copilot control plane / observability + +Treat Lousy Agents' doctor and `agent-shell` as evidence for a control plane that distinguishes intent, tool execution, artifact mutation, verification, and agent claims. Decide what belongs in GitHub-native work surfaces versus Agent OS state. Prefer verifiable evidence over self-reported completion. + +### Integration lens: automation / project curator + +Design a continuous-curation loop where doctor findings, recurrence detection, lessons, and backlog state feed each other. Repeated findings may become candidate invariants or policies; resolved findings should retire cleanly; curators should evolve the portfolio rather than simply report it. + +**Receiving-thread resolution:** this lens is now worked through in [`automation-curation-lens.md`](./automation-curation-lens.md). It settles the lane-scoped naming invariant, a seven-concept minimal automation ontology, the hard `Gov`/`Meta` boundary, the meta-curation loop, progressive-disclosure recipe structure, `grill-me` composition, and the adapter capability matrix. Treat that document as the current decision record for automation taxonomy/curation work rather than reopening these questions from scratch. + +### Questions the receiving threads should resolve + +- What is the smallest useful canonical ontology? +- What belongs in the graph versus harness adapters? +- What is an automation versus an agent, workflow, recipe, scheduled run, or policy? +- How should intent inherit across org/workspace/repo/automation/agent/run scopes? +- What evidence is sufficient to verify an agent claim? +- How do lessons graduate into durable policy without accumulating noise? +- How should doctor findings create, update, or close backlog work? +- Which stages must remain deterministic, and where is agent-assisted reasoning acceptable? +- How do we preserve native harness escape hatches without turning Agent OS into another mandatory harness? + +Expected output from each receiving thread: + +- accepted implications +- rejected implications with rationale +- ontology/taxonomy changes +- adapter/compiler changes +- governance/observability changes +- backlog items +- unresolved decisions that require interactive grilling + +## Suggested skills + +- `context-handoff` when moving conclusions between sessions or harnesses; keep future handoffs pointer-only. +- `find-before-build` before implementing concepts that Lousy Agents or an existing plugin already covers. +- `codebase-design` before committing to the canonical graph API or adapter interface. +- `grill-me` for high-blast-radius ontology and source-of-truth decisions. +- `redgate` composed around the applicable specialist when the work warrants explicit falsifiable criteria, iterative verified rounds, or a classified human gate; it reinforces how that specialist's procedure is executed — it does not own the domain procedure. +- `recurrence-detector` when repeated doctor findings begin to suggest a candidate invariant. +- `docs-hygiene` before propagating generated cross-harness instruction surfaces.