Assemble the ecology on demand, then dissolve it.

Concept Paper · v0.1

Dynacology

Dynamic ecology as cognitive infrastructure

Patrick Killebrew · April 2026 · Unpublished working paper

Abstract

Dynacology is a framework for assembling cognitive infrastructure on demand. Where a fixed ecology — like Ontinuity — maintains a predetermined configuration of specialist models for a specific class of problems, a dynacology assembles its configuration dynamically in response to the problem at hand. A controller reads the problem, queries a registry of available promptgrammed specialists, assembles the appropriate ecology, executes the work, and dissolves the configuration when complete. The specialists are artificialware; the controller is itself artificialware; the registry is the substrate that makes composition possible. Together they constitute a new model for how complex cognitive work gets done: not by building dedicated applications, but by assembling purpose-built ecologies from reusable specialist components.

1The Fixed Ecology Problem

Ontinuity is a fixed ecology. Its four roles — Researcher, Challenger, Friction, Parietal — are predetermined, configured at session start and constant throughout. For Ontinuity’s purpose — sustained adversarial research with persistent memory, navigational orientation, and autonomous fork resolution — the fixed configuration is a feature, not a limitation. Knowing the ecology in advance produces better outcomes than assembling it dynamically.

But not every problem belongs to that class. Legal analysis, medical diagnosis, engineering design, strategic planning, scientific research, philosophical inquiry — each domain has different specialist requirements. The ecology that serves carbon-capture constraint mapping is not the one that serves cross-jurisdictional contract review. A fixed ecology scales to its class and not beyond; to address problems outside it, you build another fixed ecology, and another, each designed from scratch, configured manually, maintained independently, its expertise siloed and unavailable to any other.

Instead of building a new fixed ecology for each problem class, you build reusable specialists and a controller that knows how to compose them.

The ecology assembles itself from the registry, executes, and dissolves. The specialists persist. The configuration is ephemeral.

2What Dynacology Is

A dynacology has three components: a controller, a registry, and a set of specialist artificialware models.

The controller is a promptgrammed model whose function set is orchestration, not domain work — functions like ASSESS (read the problem and identify what specialist capabilities it requires), SEQUENCE (determine the order specialists are called and how their outputs connect), SYNTHESIZE (assemble specialist outputs into a coherent product), and EVALUATE (assess whether the assembled ecology produced what the problem required). The controller does not generate domain content. It composes specialists who do.

The registry is a structured catalog of available specialists: what each does, what inputs it accepts, what outputs it produces, what problems it suits. It is the substrate of composition — without it the controller cannot know what is available; with it the controller can query any problem description and identify the relevant specialists. The registry grows as new specialists are built and registered, each one making the dynacology more capable without changing the controller or the existing specialists.

The specialist artificialware are promptgrammed models, each deeply coherent in a domain, each with a defined function registry and standardized interface. A specialist need not know about other specialists, the controller, or the problem that caused it to be called. It receives defined inputs and produces defined outputs. The controller handles composition; the specialist handles domain execution.

A session proceeds: the operator presents a problem; the controller assesses what capabilities it requires, queries the registry, identifies the specialists, sequences their invocation, passes outputs between them as inputs, and synthesizes the combined work into a result. When the problem is resolved, the configuration dissolves — the specialists return to the registry, available for the next problem that needs them.

3Ephemeral Software

The model implies something about software worth stating directly: the right unit of computation for many complex problems is not an application but an ecology, and ecologies can be ephemeral.

Classical software is permanent. Applications are built, deployed, and maintained, persisting long after the problem that motivated them is solved. Legacy code accumulates, maintenance costs compound, the application outlives its purpose. Dynacology inverts this: the ecology exists precisely as long as the problem requires and not one moment longer. When the session ends, the ecology that addressed it dissolves; the specialists persist in the registry, but the specific configuration does not. The next problem gets some of the same specialists, configured differently, in a different sequence, for a different purpose.

This is not a limitation — it is the correct model for cognitive work. A lawyer assembles a team for a case and disbands it when the case closes. A surgical team assembles for a procedure and disperses when the patient is stable. A research group forms around a question and dissolves when it is answered. Cognitive work is naturally ephemeral, and the infrastructure that supports it should be too. The cost of addressing a new problem class becomes the cost of building the specialists that class requires — not the cost of building an entirely new system from scratch.

4The Controller as Artificialware

The controller is not a general-purpose reasoner instructed to orchestrate. It is itself artificialware: a promptgrammed model with a defined function set oriented toward assembling and directing specialist ecologies.

A general model told to orchestrate will improvise, making decisions on whatever reasoning seems relevant in the moment — behavior probabilistic, failures opaque, successes hard to reproduce. That is the same reliability gap that motivates artificialware in the first place. A promptgrammed controller has explicit functions: ASSESS when a problem arrives, SEQUENCE when relevant specialists are identified, SYNTHESIZE when outputs need combining, EVALUATE when a result is produced. Its behavior is structural — when it fails, the failure is in a specific function with specific inputs; when it succeeds, the pattern can be examined, refined, and reused.

The controller need not be a frontier model. Its functions are procedural, not deeply analytical; speed and reliability matter more than reasoning depth. A mid-tier model fine-tuned for orchestration is a better controller than a frontier model given open-ended instructions — the same principle that makes Friction a lightweight model in Ontinuity: match capability to function requirements, not to general impressiveness.

5The Registry

The registry is what makes dynacology composable at scale. Without it, the controller must be told what specialists are available every time it runs; with it, the controller queries any problem description and receives a structured response identifying relevant specialists, their input requirements, and their outputs.

A registry entry contains a name and description, the problem types the specialist suits, its function list with input/output specifications, its model requirements, and its performance characteristics. The registry grows as specialists are built — each one registered becomes available to any future dynacology that needs it. The carbon-capture specialist built for one project becomes available to any project that requires carbon-capture reasoning. The registry is a commons of cognitive capability.

Its design is an open research question. The controller’s ability to identify relevant specialists depends on how well the registry describes them: too narrow and relevant specialists are missed, too broad and irrelevant ones are included. The right granularity of description, and the right query mechanism for matching problems to capabilities, are empirical questions that require accumulated registry data to answer.

6Ontinuity as Dynacology’s First Specialist

The relationship between Ontinuity and dynacology is recursive. Ontinuity is the existence proof that the fixed-ecology concept works; dynacology is the generalization of that concept. But Ontinuity is also, in a mature dynacology, a specialist: a registered artificialware ecology for sustained adversarial research with persistent memory.

A controller encountering a problem that requires sustained multi-session adversarial research would query the registry and find Ontinuity, invoke it as a specialist, provide the objective, and receive structured outputs — its Knowtext schema, session work products, correction history — which become inputs to the controller’s synthesis function, combined with other specialists’ outputs to address a larger problem than any single specialist could alone.

This recursion is the architecture working as intended. Specialists are not atomic units; they can themselves be ecologies. The controller does not need to know whether a specialist is a single model or a multi-model ecology — it knows the interface: what it accepts and what it produces. The practical implication: Ontinuity, once stable, should be registered, its interface defined, so it becomes a component of any dynacology that needs sustained research capability.

7The Minimum Viable Dynacology

The full vision — a controller querying a large registry to address arbitrary problems — is the mature form. The minimum viable dynacology that allows empirical testing is considerably simpler: one controller and one specialist. It validates the critical question: can a promptgrammed controller correctly assess a problem, invoke a specialist with appropriate inputs, and synthesize the output into a usable result? That does not require a large registry — it requires one well-defined specialist and a controller that knows how to use it.

The Parietal is the most immediately available specialist for this test: a defined function registry, standardized inputs and outputs, and a running implementation. A minimum viable controller that assesses when a problem requires navigational orientation, invokes the Parietal’s appropriate function with the right inputs, and incorporates its output into a larger workflow would constitute the first dynacological composition — the right starting point not because it is the most useful configuration, but because it tests the architecture with components that already exist.

8Building Dynacology with Ontinuity

The most compelling demonstration of the Ontinuity architecture is not a research session it runs for a human operator. It is a research session it runs on its own architecture. Given sufficient API access and a well-formed objective — “design the minimum viable dynacological controller and define the first specialist registry entry” — Ontinuity can conduct the research, produce the specifications, and generate the implementation plan autonomously. The Researcher advances the design, the Challenger disputes the assumptions, the Parietal navigates toward the destination and distills the output into Knowtext. The human reviews the work product in the morning.

This is not hypothetical. It is the natural extension of what Ontinuity already does — the objective is well-defined, the problem space bounded, the accumulated project context available. The barrier is not capability; it is compute: free-tier rate limits interrupt long autonomous sessions before they reach their conclusion.

With dedicated compute, Ontinuity builds Dynacology while its builder sleeps.

9Research Agenda

The concept raises questions that cannot be answered theoretically. Minimum viable controller design: what is the smallest function set a controller needs to assess problems, match them to specialists, and synthesize outputs, and is there a coherence ceiling for controller function sets analogous to the specialist ceiling? Registry design and query mechanisms: what granularity of description and what query mechanism let a controller reliably identify relevant specialists from a large registry, and how is degradation prevented as it grows? Composition reliability: when specialists are invoked in sequence, how does error propagate, and what adversarial structure within the controller prevents it from compounding? Ephemeral vs. persistent configuration: when should a dynamically assembled ecology persist rather than dissolve, and is there value in caching configurations for repeated problem classes? The Ontinuity registration study: define the interface specification for registering Ontinuity as a specialist — the first registry entry, validating the registration methodology.

10Open Questions

This paper stakes the claim and defines the territory. Can a promptgrammed controller maintain coherent orchestration across a five-specialist ecology, or does orchestration complexity degrade controller coherence below the reliability threshold? Is the registry a static document or a dynamic structure that updates as specialists accumulate performance data — and if dynamic, what update mechanism preserves its integrity? How does dynacology relate to existing multi-agent frameworks — the claimed distinction, that it is structurally reliable where they are probabilistic, needs to be operationalized and tested. What is the right commercial model for specialist registries built by different developers and shared in a commons? And is dynacology a step toward AGI or a different path — the reliability-floor-rising framing suggests that by systematically eliminating failure modes through compositional architecture, it is as much an AGI path as capability scaling.