Engineering brief · Living software systems
When software becomes a custodian.
A semi-autonomous system watches the organization around it. It helps improve the software that keeps work moving—within boundaries set and approved by people.
Living systems field note · Human-approved evolution
Assistance becomes connective production · capability becomes organizational memory
The argument
Software that helps the organization stay healthy.
AI can make one developer faster. That is only the beginning.
Imagine software that sees the wider system: applications, users, policies, dependencies, and outcomes. It notices what changed and helps decide what to do next.
People still choose direction and approve consequential changes. The system does the patient work between decisions.
Operating safely
Keep the system moving without losing control.
A living system is fast where it can be and careful where it must be. It watches dependencies, incidents, tests, and outcomes.
Fast where it can be. Careful where it must.
It can patch a vulnerability, repair a broken path, or upgrade an application. If the evidence says the current approach is failing, it can prepare a better one.
People decide
- What the connected work must do
- Which systems and owners are involved
- Whether the evidence is good enough to release
The system carries out
- Monitors dependencies, incidents, and outcomes
- Prepares patches, upgrades, and safer alternatives
- Runs remediation with retries and a trace of what happened
Existing pattern: GitHub already combines reusable workflows, protected environments, and automated dependency updates. The pieces can wait for approval and leave a record.
Sequence is a product decision.
Acting across tools
Work as one organization, even when tools are many.
The work is distributed. The system brings the right applications, views, integrations, checks, and people together for each problem.
One mission. Many applications.
A request such as “improve patient intake” may touch a form, a workflow, a report, an operator guide, and a compliance record. Each part can be built by a different tool and still belong to one outcome.
People decide
- Which question the work must answer
- Which systems are authoritative
- Where architecture and exceptions need judgment
The system carries out
- Assembles a harness across tools
- Chooses agents, gates, and retry limits
- Keeps views and outputs tied to one intent
Existing pattern: Backstage templates turn an approved input into repeatable components. The same idea can connect the tools that make the work real.
From one brief to a family of outputs.
Learning from the world
Remember what the organization has learned.
Every intervention leaves evidence. Decisions, failures, tests, exceptions, and outcomes become part of the system’s memory.
Knowledge travels with the work.
The system can compare what was intended, what was built, and what actually happened. That history stays useful across views, applications, integrations, and source systems.
People govern
- Which sources are trusted
- How contradictions are resolved
- Which changes need approval
The system remembers
- Specs, deficiencies, tests, and remediation history
- Current-state reality across connected tools
- Reusable contracts for the next build
Existing pattern: OpenTelemetry gives teams shared meanings for traces, metrics, logs, events, and resources. Common language makes evidence reusable.
The system can tell history from intention.
Knowing the organization
Understand the world the software serves.
Rules and boundaries are not background reading. They change what a safe, useful application looks like.
Policy becomes part of every surface.
A system serving a real organization needs more than source code. It needs the right data boundaries, operating practices, and exceptions.
People clarify
- Which systems and sources are authoritative
- How exceptions are approved
- What the system must never infer
The system applies
- Policy and domain context during production
- Security and compliance checks beside functional checks
- Escalation when a requirement cannot be verified
Existing pattern: Open Policy Agent separates policy decisions from the software enforcing them. Kubernetes can apply those constraints before resources are accepted.
Context is not decoration. It changes the artifact.
Improving over time
Propose the next best change.
The system watches the organization around the software. It can spot a vulnerability, a failing process, a stale document, or a new opportunity.
Then it prepares a change and asks for approval. It acts like a custodian and an engineer, but never gets a blank cheque.
It can suggest a feature when people keep working around a broken process. It can evaluate a new technology in a safe sandbox and recommend whether to adopt it.
A custodian, an engineer, and a careful colleague.
A signal becomes a proposal: what changed, which tools are affected, what should be updated, and who must approve it.
Operations
Artifact integrity
Environment
People
People govern
- Goals, budgets, risk, and approval thresholds
- Whether a proposed change is worth doing
- When the system must stop and ask
The system coordinates
- Ranks changes by impact, urgency, and confidence
- Prepares a patch, upgrade, or alternative approach
- Returns new evidence to shared memory
Existing pattern: Kubernetes controllers reconcile desired and current state. Dependabot turns dependency signals into pull requests. Both show software acting within defined boundaries.
The product can notice without taking control.
The living loop
The system improves itself—but never governs itself alone.
It observes, understands, proposes, and prepares work. People set the boundaries and approve consequential changes.
01
Observe
Signals across tools
02
Understand
Context and impact
03
Propose
Change with a reason
04
Approve
Human judgment
05
Build
Working harness
06
Remember
Shared knowledge
Existing work
The pattern is already visible in pieces.
No single tool is this custodian. But the pieces already exist.
01 · Reuse
GitHub workflows
Shared logic can be reused, checked, and held for approval.
02 · Context
Backstage catalog
Software, ownership, dependencies, and APIs become easier to find.
03 · Policy
Open Policy Agent
Policy can be decided separately from the code that enforces it.
04 · Control loop
Kubernetes controllers
Software watches desired state and makes bounded corrections.
What survives a rebuild
A good custodian leaves the organization stronger.
The code will change. The durable layer is the organization’s knowledge: decisions, evidence, context, and approval boundaries.
The BuildFactory idea is one way to make that knowledge useful while people keep building.