---
kind: project
name: Autonomic Software Loops
summary: Exploring how the control-loop idea applies to software changes that observe consequences and converge against a protected target.
maturity: exploratory
period:
  start: 2026-09-06
status: working-model
areas:
  - autonomic-swe
  - control-loops
  - evaluation
owner: tim
started: 2026-09-06
updated: 2026-09-06
current_question: What makes an engineering loop genuinely autonomic rather than an automation script with a model in the middle?
next: Compare the roles of target, proposer, applier, sensor, scorer, and recovery path in a bounded loop.
featured: false
on_bench: true
artifacts:
  - label: Autonomic software loops guide
    href: /guides/concept/what-makes-software-autonomic
    kind: guide
  - label: Verification guide
    href: /guides/concept/verification-is-state
    kind: guide
claims: []
open_questions:
  - How should a protected target evolve without silently changing the meaning of an earlier verdict?
  - Which failure modes should reduce authority instead of merely retrying?
build_log: []
verifiedAgainst: []
proves: An autonomic software loop needs a protected target and an independent way to judge consequences, not only a mechanism that can emit changes.
domains:
  - autonomic-swe
  - evals
  - agent-systems
runtimes:
  - python
  - typescript
maintainer: tim
---

## Why this exists

Automation can emit changes without establishing that the loop learned whether
the change helped. The useful question is what separates an autonomic loop from
a script with a model in the middle.

## Current model

The repository or service is the managed subject. A work loop can observe,
reason, propose, act, verify, and adapt; a governance loop observes task state,
evaluates policy, evidence, and risk, exposes or revokes capabilities, and
authorizes the next transition. The proposer remains separate from the verdict
path.

## What is unproven

This is a maintained architectural idea, not a claim that ReactorJet ships an
autonomic software engineer. No new experiment or completed progress is
implied by this entry.

## Next experiment

Map one bounded repository-repair loop into work-loop and governance-loop
states, including the failure path that reduces authority.

## Related

- [Controlled delegation](/guides/concept/controlled-delegation)
- [Verification is not the last step](/guides/concept/verification-is-state)
- [Reconciler](/work/reconciler)