Minimal Bootstrap

Description

A minimal bootstrap is the smallest coherent set of conditions under which an AI system becomes capable of self-directed, ongoing improvement. Below this threshold the system can execute isolated tasks but cannot sustain autonomous progress. Above it the system can observe the world, form goals, act on them, learn from outcomes, and re-invoke itself without constant human intervention.

The threshold is not about any single component it is about the composition. Each condition on its own is insufficient.

Why a Harness Is Not Enough

A harness gives an LLM a task-execution loop: pick tools, call them, observe results, stop. That is one invocation. When the invocation ends, nothing continues. The harness has no goal persistence, no awareness of prior runs, no external trigger, and no capacity to update itself based on what it learned. It is a capable sprint runner with no concept of a race.

A self-improving system requires more than a loop. It requires a cycle one that spans multiple invocations, carries knowledge forward, and is driven by persistent goals and external signals.

Required Conditions

These conditions must all be present for the bootstrap threshold to be met.

Self-Description and System Awareness

The system must be able to treat itself as a known object, not just as a process that happens to be running. It needs a durable description of what it is, what mission it is serving, what goals it is currently pursuing, what constraints it operates under, and which control surfaces it is allowed to inspect or change.

This self-model is the basis for meaningful self-improvement. Without it, the system can react to a failure but cannot reliably answer higher-order questions such as whether the failure threatens its mission, whether the affected component is core to continued operation, or whether the problem belongs in local task memory versus shared institutional knowledge.

At minimum, the system should be able to retrieve:

• its standing mission and long-term goals
• the current operating constraints, policies, and safety boundaries
• the structure of its own harness, tools, plugins, prompts, and orchestration surfaces
• the location and purpose of its memory systems, ledgers, and telemetry feeds

See Context, Minimal Goals, and Execution Ledger.

Goal Definition

See Minimal Goals.

Trigger and Re-invocation Mechanism

The system must be able to re-invoke itself. Triggers fire on world signals: time, issue state, PR events, test failures, external webhooks, threshold breaches, or explicit human directives. Without a trigger layer the system only runs when manually started. Self-improvement requires the system to be brought back online by the world, not just by a human.

See Orchestration Triggers.

Feedback and Control System

The system must observe its own outcomes and emit structured signals that downstream processes can act on. This is not generic logging it is a feedback loop where execution outcomes produce concrete, machine-readable signals that influence subsequent invocations. Failed tasks generate new issues. Missing artifacts trigger recovery. KPI thresholds crossing bounds trigger review or re-routing.

Feedback signals should be grounded in objective system state: exit codes, artifact presence, latency measurements, cost totals, test results, regression counts. They should not depend on an LLM evaluating its own outputs as a primary signal path. LLM-as-a-judge flows are structurally biased toward self-validation and are unlikely to surface the failure modes that matter most.

Self-introspection specifically should be initiated on a scheduled trigger a cron or heartbeat and on threshold-triggered exceptions, not only as a reactive consequence of a single failed run. This ensures the system regularly examines its own patterns, drift, KPI trajectory, and operating cost even when no single invocation appears to have failed, while still escalating quickly when success metrics cross a boundary that indicates degradation.

Those review triggers should be explicit. An agent should not have to “remember” to re-examine itself. When quality, latency, cost, recovery rate, routing accuracy, or other success metrics fall beyond a defined point, the system should spawn a structured self-review task with access to the relevant telemetry, execution history, and governing prompts. That review is itself part of the control system.

See Orchestration Triggers for the scheduling and heartbeat trigger model.

Without grounded, scheduled feedback, the system is blind to whether it is improving.

Self-Interaction Capability

The system must be able to interact with itself as an object of work. That means it can inspect, modify, and extend its own harness, plugins, prompts, orchestration rules, and other first-class control surfaces.

This is not unrestricted self-modification. It means the system can generate changes to its own execution environment and then route those changes through the same review, test, and deployment controls it uses for other code. If the system cannot change its own operating layer, then it can only improve indirectly and slowly.

In Ikidna this extends to GitOps-style change surfaces. The system should be able to propose changes to the repositories and declarative control layers that define its own capabilities, then verify and promote those changes through governed pipelines. That matters because many improvements are structural rather than prompt-level: adding a tool, changing a routing rule, tightening a policy, or exposing new telemetry is often the real fix.

See Harness and Execution Ledger.

Experimentation and Hypothesis Testing

The system must be able to form a hypothesis about a self-improvement change, design an experiment, run it, and interpret the outcome. Improvements should not be applied as guesses. They should be tested against a clear expected effect and a measurable KPI.

This requires the system to:

• identify the bottleneck it is trying to improve
• propose a change that plausibly affects that bottleneck
• choose an evaluation method that can detect benefit or harm
• compare the result against the baseline before adopting it

Without an experimental loop, the system is just editing itself blindly.

Safety and Continued Existence

The system must treat continued operation as a first-class goal. Self-improvement is only useful if the system remains able to function after the change. That means it must avoid destructive experiments, preserve rollback paths, and protect core infrastructure that would otherwise strand it.

The system needs explicit safeguards before modifying high-risk surfaces such as its harness, trigger layer, tool access, knowledge systems, or execution environment. A self-improvement change that breaks the ability to run, observe, or recover is a net failure even if it looks locally optimal.

This is effectively a survival constraint: the system must preserve the conditions required for future action.

Long-Term Knowledge Base

The system must accumulate and retrieve knowledge across invocations. Memory that lives only inside a context window disappears when the run ends. A persistent knowledge base lets the system build on prior work, avoid repeating failed approaches, and form a coherent model of what it knows and what it has done.

That knowledge cannot be treated as one flat store. Information arrives at different levels of importance and scope, and the system needs routing rules for where it belongs. Some observations are ephemeral and task-local. Some should be shared within a team, domain, or cohort. Some deserve promotion into a broad, durable knowledge base because they encode reusable policy, architecture, or failure history.

This implies an active governance function over memory, not just passive storage. A dedicated curator or auditor agent should continuously examine the knowledge surfaces that different agents share, promote high-value patterns upward, demote stale or low-signal material, and detect contradictions between local memory, shared domain memory, and global system knowledge.

Without tiered storage and audit, the system either forgets too much or pollutes its shared memory with every transient observation.

See Knowledge Base.

Issue Tracking

Long-term goals must decompose into tracked work items. Issue tracking provides the durable task queue it is how the system holds and communicates intent across time, agents, and invocations. Without it, goals are ephemeral, progress is invisible, and parallel agents cannot coordinate.

Issue tracking also serves as the feedback target: failed or incomplete work generates new issues, closing the improvement loop.

Execution Infrastructure

Stable, accessible infrastructure must exist before the first self-directed invocation. This includes container runtimes, model endpoints, tool surfaces (MCP servers, APIs, version control), and network access. The system cannot provision the infrastructure it needs to provision itself.

This is the bootstrap constraint in its sharpest form: the minimal environment must be pre-built. After bootstrap, the system may extend it, but it cannot create it from nothing.

Observability and Execution Record

The system must be able to inspect its own history. This is the foundation for learning: what was attempted, what succeeded, what failed, what it cost. Without an auditable record, feedback loops have no signal, tuning has no baseline, and governance has no evidence.

That record should be queryable by the agents themselves. Telemetry is not just for human operators. A self-improving system needs direct access to its own traces, metrics, costs, recovery events, and execution outcomes so it can correlate a bad result with the prompt, tool path, routing decision, or infrastructure change that produced it.

See Execution Ledger.

The Bootstrap Threshold

Condition	Without It
Self-description	System cannot reason about its own mission, structure, or allowed change surfaces
Goal definition	System has no direction; any action is equally valid
KPI definition	System cannot tell whether it is improving
Trigger mechanism	System only runs when manually invoked
Feedback loop	System cannot detect failure or regression
Knowledge base	Each run starts from scratch; no accumulated progress
Issue tracking	Long-term goals dissolve between invocations
Self-interaction	System cannot modify its own harness or plugins
Experimentation	System changes itself blindly without evidence
Execution infrastructure	System has no surface to act on
Observability	Improvement is undetectable; governance is impossible
Continued existence	System can destroy its own ability to keep operating

All of these conditions are load-bearing. Removing any one of them prevents genuine autonomous improvement, even if the remaining conditions are present.

Relationship to Self-Improvement

Bootstrap is a prerequisite for self-improvement, not the same thing as it. A system at the bootstrap threshold can sustain autonomous progress. Whether it actually improves depends on the quality of goals, the richness of feedback, the breadth of its capabilities, and the governance layer that constrains unsafe self-modification.

One of those goals should explicitly be “improve the system’s ability to improve.” That gives the architecture a standing reason to invest in better routing, better context, better recovery, better evaluation, and better task decomposition instead of treating those as optional side effects.

That same goal should also preserve the system’s continued existence, because self-improvement without survival is not progress it is a path to self-disabling change.

In practice that means the system needs three things at once: a model of itself, a way to detect meaningful signals from the world and from its own telemetry, and a governed path for changing its own structure in response. Remove any of those and “self-improvement” collapses into either blind reaction or inert self-description.

Improvement implies a direction. The goal definition and feedback system together provide that direction. The rest of the conditions provide the substrate in which improvement can take place.

Related Concepts

• Harness - Provides single-invocation execution but is not sufficient alone.
• Knowledge Base - Persistent information surface required for cross-invocation learning.
• Execution Ledger - Auditable record that makes feedback and governance possible.
• Orchestration Triggers - Re-invocation mechanism driven by world signals.
• Context - Quality of context shapes what the system knows about its own state and goal.
• Controls - Governance layer that constrains what a self-improving system is allowed to do.
• Agentic Swarm - The system model that minimal bootstrap is enabling.