Why Research Needs a Control Plane
Praxist is an autonomous research system for measurable, computer-executable work. The question is not merely whether it can make an agent write code. The more consequential question is whether a sequence of uncertain experiments can remain coherent, measurable, and inspectable after several agents, several failures, and several rounds of revision. Understanding that distinction gives a reader a practical way to judge what Praxist is for, what a research project must provide, and what confidence its records can reasonably support.
The problem with disconnected competence
A single agent session can look productive while leaving a poor research process behind. An agent may inspect a baseline, propose a change, run a command, and report a better-looking number. But if the next session cannot tell which baseline was used, which files were allowed to change, how the number was measured, or why the next experiment was chosen, the local success has not become durable knowledge. The work may have been technically competent and still be difficult to trust, reproduce, or build upon.
This is the weakness in treating research as a string of prompts. A prompt is an instruction at one moment. Research is a relationship across moments: a question produces a hypothesis; a hypothesis produces an intervention; an intervention produces measurements; measurements change what should be tried next. The process also has negative branches. A failed experiment may rule out a direction, a partial evaluation may be useful for repair but unfit to rank, and a late result may arrive after the decision that closes a round. If those distinctions disappear into chat history, the system has no dependable account of what happened.
Praxist therefore treats research as a persistent process. Its product description emphasizes parallel research peers, task-owned evaluation, durable evidence, and synthesis across generations. Those terms point to a change in the unit of work. The unit is no longer an isolated answer from an agent. It is a bounded research run whose experiments, findings, decisions, and interruptions remain connected over time.
That change matters because adding agents increases both possibility and bookkeeping. More peers can explore more hypotheses, but they can also repeat the same idea, compete for the same resource, produce incomparable measurements, or leave a trail no one can reconstruct. A control plane exists to coordinate those relationships without pretending to own the scientific question itself.
What a research control plane does
In ordinary computing, a control plane is the layer that coordinates resources and state while other components perform the substantive work. Praxist applies that idea to research. It coordinates peer sessions, generations, runtimes, scheduling, lifecycle transitions, evidence transport, durable state, replay, and synthesis. It does not supply the objective, invent the evaluator, or decide what counts as a scientifically valid improvement for every domain.
That distinction creates four linked roles:
The researcher or operator supplies intent and decides what trade-offs are acceptable. The external task project supplies domain truth: the runnable code, baseline, data or simulator, evaluator, metrics, prompts, roles, and constraints. Praxist supplies the reusable machinery that moves work through a run. The run directory holds the evidence and lifecycle state for that particular attempt.
The arrows are as important as the boxes. The task project tells Praxist what may be measured and changed. Praxist sends coordinated work back to that project. The project-owned evaluator turns candidate work into results, and the run stores those results with the context needed for later interpretation. The researcher can then examine not only the strongest candidate but also the path that produced it.
This is why calling Praxist a “domain solver” would be misleading. A controller-design task and a text-ranking task may use different metrics, data, and scientific constraints. They can still share a research loop if the framework remains ignorant of those private facts. The reusable object is the process contract, not a universal theory of what a good solution looks like.
The project must bring the science
Praxist begins with an existing runnable research project. Before takeover, the project needs a working baseline path, an available execution environment, locally reachable data or simulator assets, and at least one measurable objective whose direction is known. It also needs scientific constraints: what may change, what must remain fixed, and which trade-offs would invalidate an otherwise attractive result.
These requirements are not ceremonial. Without a runnable baseline, there is no trustworthy starting point. Without a public evaluator, different peers can measure different things while using the same metric name. Without constraints, the system may optimize a number by changing the problem. Without a known direction, even the meaning of “better” is unsettled.
Takeover turns those prerequisites into a task-owned contract. It records the objective and evidence standard, identifies the allowed execution surface, defines roles and prompts, and adds the practical harness around the existing project. That harness can include a reproducible evaluation path, baseline records, retention rules, close conditions, resource observations, and tests. It is an adapter around the project, not a replacement for the project.
The framework is deliberately conservative about gaps. If the required data is missing, it does not silently download an unknown dataset. If the simulator is absent, it does not invent one. If baseline performance has not been measured, it does not fill the gap with a plausible number. When the project can measure its baseline locally, an operator may authorize a bounded baseline benchmark; otherwise the unresolved prerequisite remains visible.
A small canary evaluation serves a narrower purpose. It checks that the public evaluator can launch, produce a structured summary, and project that summary into the run's evidence path. A passing canary shows that execution is connected. It does not show that the metric captures the intended phenomenon, that the result is mature, or that the research direction is promising. That separation is central to Praxist's design: launch readiness and scientific validity are related, but they are not the same claim.
Persistence changes what progress means
Once a project is connected, Praxist organizes work into generations. A generation is a cohort of peer investigations followed by a boundary at which the system decides what evidence is committed and what agenda should guide the next cohort. The broad pattern is simple: inherited state feeds parallel hypotheses; peers create permitted variants and use the task's evaluator; results become structured findings; the system retains selected evidence; a planner proposes what to do next.
Persistence gives each step a place in that chain. A later peer can see a durable candidate, a negative result, a frontier entry, or a previous agenda without relying on a human to reconstruct a transcript. The run can also distinguish a result that was produced from a generation that was actually committed. That distinction matters when a process stops halfway through finalization or when a file arrives after the evidence cutoff. The artifact may remain useful, but it cannot quietly rewrite the past.
The same principle applies to failure. Praxist's stated posture is to capture useful output, label uncertainty, and continue when safe. A failed or incomplete experiment is not automatically discarded, because it may identify a dead end or expose an operational problem. It is also not automatically promoted into the set of clean parents. Preservation and promotion are separate decisions.
This is the beginning of a more useful definition of progress. Progress is not simply a higher number in the latest report. It is evidence that can be traced to a task-owned measurement, interpreted under the declared protocol, and placed in a state where the next research decision can use it appropriately. A platform can make that chain more legible without making the underlying science true by decree.
How to decide whether the model fits
Praxist is most naturally suited to a project in which the objective is measurable, the baseline already runs, and the best path forward is genuinely unknown. That combination creates a meaningful search problem. There is something concrete to evaluate, something stable enough to compare against, and enough uncertainty that parallel exploration could add value.
The fit is weaker when the work is mainly open-ended writing with no evaluator, when the project cannot run in its intended environment, or when success depends on judgments that have never been made explicit. It is also weak when the desired outcome is only a polished answer rather than a sequence of testable interventions. In those cases, adding a persistent research loop may produce more artifacts without producing more knowledge.
Even in a good-fit project, Praxist should be understood as infrastructure for disciplined iteration, not as an assurance that a run will improve the metric. The repository explicitly makes no such guarantee. A run can produce a negative result package and still be valuable if it rules out tested approaches with credible evidence. Conversely, a reported improvement still deserves review of the changed solution, the evaluator, the protocol, and the environment in which it was obtained.
That is the practical judgment this series will develop. First, the task boundary must be clear: the project owns the science, while Praxist owns the reusable process around it. Then the generation lifecycle can be followed from hypothesis to evidence and inheritance. After that, the system's mechanisms for maturity, diversity, memory, scheduling, runtime normalization, replay, and operation can be judged by the failures they are designed to prevent—and by the failures they cannot prevent.
The central promise is therefore one of legibility. Praxist can give a long computational search a durable structure: who was asked to do what, what was measured, what was retained, and what was planned next. That structure is valuable precisely because it does not erase the boundary between coordination and scientific truth. The next question is where that boundary is drawn in a real task project, and how its contracts keep a generic framework from changing the problem it was asked to investigate.