LiveUpdate, coordinator and human-agent authoring
Technical preprint, 16 September 2026 — web reading edition. This preserves the supplied paper’s content and its historical evidence boundary. Proposed interfaces, conditional propositions and constructed studies are not released APIs or deployment proof. Aligned equations, tables and listings retain their source layout. Source figure pages retain the original vector artwork. The accompanying finite model and coverage-map source package were not supplied; their reported results have not been independently reproduced here.
Current guides: reaktor-agentic-tooling · reaktor-capability · architecture-atlas-evolution.
The engine and feature composition · Graph model, protocols and computation · Platforms, identity and polyglot execution · Data authority, contracts and federation · Build, compilation and resource budgets · LiveUpdate, coordinator and human-agent authoring · Assurance and adoption studies · Precedents, evaluation and implementation sequence · References, notation, exercises and source lineage
26. LiveUpdate: replacement of supported subgraphs
26.1 Delivery, rewriting, and activation
LiveUpdate coordinates replacement of a supported graph region and its implementation artifacts. Over-the-air code delivery, referred to here as CodePush, is one delivery mechanism. Graph rewriting describes the structural change. Activation determines whether and how the replacement becomes part of the
running system. These operations use the existing release, patch, artifact, and execution models rather than a second update-specific graph. Updateability belongs to module boundaries, artifacts, loader capabilities, and state contracts. It is not a new dimension of every port. A native host can retain an unchanged service interface while a compatible Hermes implementation behind that interface is replaced. Graph-only updates can select existing implementations or alter supported wiring. They cannot instantiate code that the installed host or supported interpreter does not contain.
26.2 Update regions and closure
An update region 𝑈 is an open subgraph whose externally relevant relationships are mediated by declared
boundary contracts or included in a coordinated replacement. Write the surrounding system as 𝐻 = 𝐶 [𝑈].
Replacement yields
𝐻 ′ = 𝐶 [𝑈 ′ ], (22)
with an explicit mapping from required old boundary endpoints to compatible new endpoints. Internal
identities can change. Required public identities remain stable or have a validated mapping; ports retain
unique ownership in both revisions.
Closure includes more than visible call edges. Artifact imports, shared module state, captured
implementation objects, callbacks, timers, subscriptions, borrowed buffers, and exclusive resource
ownership can prevent independent replacement. For requested changes 𝑆0 , a planner computes a
monotone closure such as
𝑈 ∗ = 𝜇𝑋. 𝑆0 ∪ 𝐷 unmediated (𝑋) ∪ 𝐷 coUpdate (𝑋) ∪ 𝐷 state (𝑋) , (23)
where each dependency function is defined by a supported runtime and contract profile. Stable compatible boundaries stop expansion. The least fixed point is a closure under those declared rules, not a proof of globally optimal packaging. If the importer or runtime cannot account for a relevant escaping reference, independent replacement is unsupported. The planner can enlarge the region, require a whole-runtime restart, or reject the update. A rectangle selected on a canvas is not a closure proof. A hyperedge crossing the region boundary retains its role and membership semantics. Replacing one subscription implementation need not replace all publishers or subscribers. Changing a shared coordination protocol, durable subscription identity, or incompatible event schema can require a larger update group or a mixed-version transition.
26.3 Update kinds and activation modes
What changes, how it is delivered, and when it activates are independent fields. A release can change configuration, graph structure, implementation artifacts, or state representation. Delivery may occur through an application release, an OTA channel, a local development tool, or a server deployment. Stateful migration is a separate dimension of the plan. Next-entry or boundary-restart activation can still require state conversion. A runtime supporting bundle download may support only restart activation. A portable node can be placed in a dynamically loadable domain only when a qualified compiler and loader support its code and dependencies; the graph alone does not make it portable.
26.4 Host contracts, artifacts, and release mappings
A signed update manifest binds the expected base release, graph patch, artifact hashes, dependencies, required contracts, host requirements, activation plan, state transition, and recovery plan. Host requirements include relevant graph and FFI ABIs, engine/compiler compatibility, capabilities, and optional UI or state protocols.
Activation mode Operational contract
Next entry The replacement is selected when a feature is next entered; an existing activation is not
changed implicitly.
Boundary restart The old region is disposed and recreated, with only explicitly preserved state and
resources retained.
Drain and swap Admission pauses, relevant work drains, state and ownership transfer, and the new
generation begins serving.
Versioned coexistence New work selects the candidate while permitted old work remains pinned to its
compatible generation.
Table 9: Activation modes are runtime capabilities. Versioned coexistence is not the default assumption for an arbitrary bundle.
Expo’s runtime-version model provides a precedent for checking the compatibility of an update against native code already installed in the application [108]. Reaktor refines that boundary through explicit contracts and runtime requirements. Declaring a compatible version label is not a substitute for a correctly maintained compatibility description. System revision, artifact hash, boundary generation, state-schema revision, and UI commit sequence remain distinct. A release records their compatible mapping:
𝑅 : BoundaryId −→ ( ArtifactHash, Generation, ContractRevision). (24)
Unchanged boundaries need not acquire a new artifact or generation. A code rollback is a new authorized release decision selecting a compatible previous artifact, not acceptance of arbitrary stale metadata.
26.5 Eligibility and runtime readiness
For a region 𝑈, installed target 𝑇, activation mode 𝑚, and channel 𝑐, define
Eligible (𝑈, 𝑇, 𝑚, 𝑐) = Closed (𝑈) ∧ BoundaryCompatible (𝑈, 𝑇)
∧ LoaderSupports (𝑇, 𝑚) ∧ HostSatisfies (𝑈, 𝑇)
∧ StatePlanValid (𝑈, 𝑇) ∧ CoexistenceValid (𝑈, 𝑇, 𝑚)
∧ BudgetSatisfied (𝑈, 𝑇, 𝑚) ∧ Authorized (𝑈, 𝑇, 𝑐). (25)
Eligibility is distinct from reaching a safe point at time 𝑡. Static evidence can establish some terms; others rely on certified runtime profiles or checked preconditions. Unknown evidence is not interpreted as success. Resource-budget satisfaction can be rechecked during preparation. A supported update may legitimately defer activation when a long-lived session prevents its safe point.
26.6 Preparation and effect isolation
The lifecycle proceeds through staged, prepared, ready, active, draining, and retired states, with explicit rejected and failed states. Preparation verifies signatures and hashes, resolves dependencies, validates the graph patch, creates the candidate generation, installs its restricted bindings, restores staged state, and runs permitted probes. Candidate evaluation can execute arbitrary initialization code. Consequently, preparation must restrict effects, not merely hide the candidate from the UI. Production message consumption, external writes, notifications, and ownership claims remain disabled until the relevant activation step. Staged migrations write isolated state or use a backend-supported transactional protocol. A preparation environment with unrestricted access to production state is not isolated simply because the candidate has not yet been published.
Authentication of artifacts does not establish benign behavior. Capability restriction is enforced by the host and its binding layer. A declaration of requested capabilities grants no additional authority. Existing references, shared globals, and unsafe native entry points must also be included in the threat and isolation model.
26.7 Generation-pinned execution
An update group publishes one immutable execution view. Admission atomically acquires and pins that view. A request or coordinated unit of work carries the view through its relevant internal calls. Loading a fresh binding independently at every call could produce an unsupported mixture even if each pointer update were atomic.
Generation 𝑔
existing work drains
Boundary admission State and resources
acquire and pin view under declared ownership
Generation 𝑔 + 1
new work admitted
Figure 6: Versioned execution pins the appropriate work unit, not merely an individual dispatch lookup. Shared mutable state requires a separate coexistence or handoff contract.
Calls return to their originating invocation. Streams retain or explicitly migrate their subscription and checkpoint semantics. Sessions remain pinned, reconnect, migrate, or close under their protocol. UI boundaries activate a coherent subtree and reject stale-generation commits. Durable workflows retain compatible definitions or migrate at declared recovery points.
Proposition 26.1 (Generation isolation). Assume admission uses a linearizable acquire-and-pin operation on a group execution view; work resolves relevant bindings only through its pinned view; a generation is reclaimed only after its last protected user releases it; and external callbacks validate their registry and generation. Then admitted work does not resolve a required binding through a reclaimed generation, and publishing a replacement does not change the pinned binding view of existing work.
Proof. Acquisition selects one published view and protects it before retirement can reclaim it. Publication
changes the view selected by later acquisitions, not a previously acquired view. Binding resolution is
restricted to that view. The last-release rule prevents reclamation while such resolution is permitted.
A delayed callback without a valid protected generation is rejected rather than reinterpreted in a new
registry. □
The proposition concerns routing and lifetime. It does not imply that old and new code may safely write shared state, that all calls terminate, or that code satisfies its declared behavior. The acquire-and-pin implementation must itself avoid reclamation races and handle reuse.
26.8 Exclusive state and safe points
For exclusive stateful regions, coexistence requires a stronger contract or is disallowed. A drain-and-swap protocol pauses new processing while retaining accepted work, drains the old writer, records a checkpoint, migrates state if necessary, advances the enforced ownership epoch, and activates the replacement. Buffered messages retain their delivery identities and ordering interpretation. An old generation that remains alive cannot continue protected writes after ownership transfer. A fencing check must be enforced by the resource owning the commit, not only by the caller’s in-memory registry. If that resource cannot enforce the required handoff, the realization cannot claim exclusive-state safety under concurrent generations.
Safe-point conditions are profile-specific. A UI boundary may require disposal of callbacks and subscriptions. An actor may require no active transition. A stateful session may require an application-defined handoff. Cancellation is not proof that an already issued remote effect did not occur.
26.9 State migration and recovery
State is classified as ephemeral, host-owned, exportable, or durable with a versioned schema. Host-owned product state can outlive a replaceable Hermes generation [88]. This reduces handoff work, but does not make rollback automatically safe: candidate code may have changed the state in a way an old artifact cannot read. A migration is a partial function with a precondition and a postcondition:
𝐼𝑜𝑙𝑑 (𝑠) ∧ 𝑃𝑟𝑒 𝑚 (𝑠) =⇒ 𝐼𝑛𝑒𝑤 (𝑚(𝑠)). (26)
The plan distinguishes activation compatibility from recovery compatibility. A reverse migration is optional and must not erase valid new work. Additive schema evolution and explicit reader/writer compatibility windows are preferred when available. Expo’s recovery documentation similarly distinguishes safe rollback from cases requiring a forward fix after persistent-state changes [109]. Activation uses a crash-safe journal and an independently available recovery entrypoint. Every cut between durable state writes, ownership changes, execution-view publication, and release recording has a specified recovery action. Restart selects a generation compatible with the durable state and ownership epoch, or enters a restricted recovery state. An in-memory pointer swap does not make those durable operations atomic. Repeated failure must not trap the application in a loop that prevents fetching or selecting a repair. A known-good artifact alone is insufficient when its state contract no longer holds. The recovery record therefore includes state compatibility and the permitted forward-repair path.
26.10 Packaging, memory, and update security
Content-addressed artifacts allow unchanged implementation objects to remain cached. The initial supported packaging unit is a complete artifact per valid update boundary, with immutable shared dependencies where the loader supports them. Chunking or bytecode segmentation can reduce transfer size, but does not establish independent retirement of closures, globals, or callbacks. Versioned preparation increases peak memory. The admission budget includes the old generation, candidate, staging buffers, migration state, and deferred work. A target may choose restart activation instead of coexistence when that budget is insufficient. Packaging optimization can consider download size, restart cost, cross-boundary communication, and memory, subject to mandatory co-update constraints; no universally optimal partition is assumed. Update metadata must prevent mix-and-match artifacts and unauthorized rollback. TUF provides a relevant model for authenticated targets, coherent snapshots, version checks, expiry, and key roles [110]. A production design must additionally specify root/key rotation, trust recovery, channel authorization, and how offline targets handle stale metadata without silently abandoning security requirements. Technical eligibility is separate from distribution-channel policy. Store-distributed applications remain subject to the applicable restrictions on downloaded executable behavior [111, 112]. A Hermes-compatible artifact is not automatically authorized for every release channel. Policy approval is represented as attributable evidence rather than inferred from a runtime name.
Original page layout, starting at page 63
27. A concrete LiveUpdate coordinator
Section 26 defines supported replacement. A coordinator implements that definition as a recoverable protocol. Its job is not to make arbitrary code reloadable, but to preserve the selected graph, artifact, state, and lifetime contracts during a supported transition.
publish new execution mapping
call A pins generation 𝑔 release
call B pins 𝑔 + 1
time
old calls remain valid retire 𝑔 only when
all lifetime conditions hold
Figure 7: Versioned coexistence is a lifetime protocol, not only a change of an active pointer. Stateful exclusivity can require a different, drain-and-handoff activation mode.
27.1 Durable decisions and transient preparation
The coordinator records a release decision separately from transient loader state. Useful states include Proposed, Verified, Staged, Prepared, Quiescing, Activated, Healthy, Retiring, Complete, and Failed. A crash can destroy a prepared runtime while leaving the durable release decision intact. Recovery therefore reconciles the journal with actual runtime/artifact state rather than assuming that every recorded step is still resident in memory.
interface UpdateCoordinator {
suspend fun assess(manifest: UpdateManifest): UpdateAssessment
suspend fun stage(approved: ApprovedUpdateRef): StagedUpdate
suspend fun prepare(staged: StagedUpdateRef): PreparedUpdate
suspend fun activate(
candidate: PreparedUpdateRef,
safePoint: SafePointEvidence,
): ActivationReceipt
suspend fun recover(journal: UpdateJournalRef): RecoveryResult
}
SafePointEvidence is issued by the runtime or state owner under the relevant protocol. It is not an arbitrary boolean supplied by an agent. A stateful actor can establish that admission is paused, its current handler finished, its mailbox ownership is accounted for, and the old writer is fenced. A UI boundary can establish that a coherent replacement tree is ready and that its event namespace has a new generation.
27.2 A publication protocol
For a versioned, stateless update group, a simple conceptual protocol is:
- Authenticate the complete release description and artifact hashes. 2. Check host contracts, capabilities, and update-region closure. 3. Load candidate code with production admission disabled. 4. Prepare candidate bindings, resources, and permitted probes. 5. Construct an immutable group execution view. 6. Under the publication protocol, replace the group’s active view. 7. Admit new work through the new view. 8. Retain old views while valid pinned work still references them. 9. Retire old resources after the reclamation condition holds.
A stateful update inserts checkpoint/migration and ownership transfer before admitting its new writer. These additional steps can change the activation mode from coexistence to drain-and-swap. The system should reject an incompatible mode rather than hide it behind the same activate() call. The group view is the publication unit. Updating each endpoint separately can expose combinations never checked together. Code that enters the group acquires a compatible view and uses it for the declared unit of work. Cross-group calls require either compatible mixed versions or a larger coordinated group; local pointer publication cannot create atomicity across independently deployed machines.
27.3 Crash cuts and recovery choices
Every durable step creates a failure boundary worth testing. A download can be incomplete; signature verification can fail; candidate initialization can throw; state migration can complete before activation; activation can succeed before a health receipt is recorded; old work can remain pinned after an operator requests retirement. The recovery rule depends on the last authoritative decision and the state contract. Before activation, deleting an unused candidate may be sufficient. After activation with unchanged backward-compatible state, selecting an authorized earlier artifact may be supported. After an irreversible state transition, forward repair may be the only valid option. A recovery journal must identify which case applies rather than unconditionally selecting the previous bundle. A known-good bootstrap path should be independent of the replaceable feature it repairs. Repeatedly starting the same failing candidate without changing recovery state produces an update boot loop. A protected attempt counter and recovery decision can prevent that loop under a stated storage-failure model. They do not recover a device whose trusted loader or storage has itself been corrupted beyond the assumed boundary.
27.4 Callbacks, subscriptions, and native resources
A function exported from Hermes can outlive the call that acquired it through a queued callback or subscription. The runtime must attach the callback to a boundary generation and either retain its implementation or revoke it safely. Numeric dispatch slots are interpreted together with runtime, registry, and generation identity. Recycling slot 42 for new code does not make an old callback to slot 42 valid. Likewise, a native buffer borrowed by JavaScript cannot be released merely because the graph edge was replaced. Borrowed lifetimes, copied values, and owned handles require distinct protocols. A generation check prevents misrouting; it does not itself preserve memory that was freed too early. The lifetime guarantee depends on ownership or protected reclamation in addition to checking identifiers. For subscriptions, termination and resumption must define replay. Reconnecting at “now” can lose events between generations. Reconnecting from the old checkpoint can duplicate events. A state or stream profile can instead transfer a durable cursor and retain the necessary deduplication or gap-detection semantics. The appropriate behavior is profile-specific.
27.5 Delivery optimization follows correctness
Content addressing can avoid downloading unchanged artifacts. Boundary-aligned packages can limit how much code needs to be staged. Shared immutable libraries can reduce storage, while independently replaceable mutable module state requires stronger loader support. None of these packaging optimizations proves safe unloading. The first deployment profile should favor simple, inspectable replacement units and bounded preparation memory. Fine-grained segmentation, runtime pooling, predictive partitioning, and cross-generation optimization are later refinements. They should preserve the same release and lifetime contracts and be justified by measured costs. An updateability query should return the supported modes and reasons: missing host capability, incompatible schema, untracked callback lifetime, insufficient memory, state-migration requirement, or distribution-policy restriction. The result is an engineering explanation, not a generic claim that JavaScript can always be pushed safely.
Original page layout, starting at page 68
28. Human and agent authoring
28.1 A common engineering surface
A human editor, command-line client, and software agent use the same semantic reader, operation catalog, proposal protocol, and authorization boundary. They need not use the same interaction style. A human can navigate spatially, read source, manipulate a Blueprint, or run a terminal command. An agent can request a bounded working set and issue structured operations. Neither gains direct mutation authority merely by learning an entity’s identifier [113]. A working set contains the selected feature, its public contracts, relevant boundary dependencies, source locations, applicable constraints, available operations, and linked evidence. The query records scope and freshness. Lexical search and implementation inspection remain necessary when the graph lacks the behavior needed for a decision. A partial graph is useful context, but must not be presented as a closed-world account of arbitrary application code. For the photograph feature, an agent can discover the upload and messaging contracts, inspect the existing actor, propose a moderation-pending state, identify affected consumers, and generate tests for retry and expired-upload outcomes. A product developer decides the user-visible semantics and approves the new behavior. A framework engineer reviews a new transport or lifecycle mechanism when the change exceeds the available substrate. These responsibilities are determined by expertise and authority, not by a rule that humans may only plan or that agents may only fill in code.
28.2 Proposals, checks, and receipts
A proposal names its base revision, source patch, intended semantic delta, affected scope, preconditions, required permissions, and acceptance plan. Source elaboration checks that the resulting semantic delta corresponds to the reviewed intent. Unsupported edits remain visible as source changes rather than disappearing outside the review. Concurrent proposals are revalidated against the combined constraints; disjoint text edits can still violate one architectural invariant. Read, propose, apply, test, and operate are distinct authorities. Production deployment and authorization administration require explicitly adopted policy; they are not consequences of permission to edit a feature. The source control-plane design uses a critic that can withhold approval without applying changes itself [113, 114]. A second model’s agreement is review evidence, not an independent proof. Protected acceptance tests, policy definitions, credentials, and verifier configuration cannot be modified through an ordinary feature-change grant.
An operation receipt records the resolved target and artifact, initiating principal, authorization decision, executable action, environment, exit status, output references, and resulting observations. A build receipt and a deployment-health receipt answer different questions. A successful command invocation does not establish that the intended cloud resource is healthy. Bounded recipe execution in the documented DevOps handoff is an early source example of this separation between planner, executor, and evidence [115]. Repository instructions, imported documents, and tool output are untrusted inputs to an agent. They cannot grant authority or change the approved target. Typed tool schemas reduce ambiguity but do not eliminate malicious arguments, unsafe sequences, or incorrect business decisions. Argument validation, invocation authorization, isolation, resource budgets, and attributable review remain necessary.
28.3 Application agents are also application components
Development agents change software; product agents participate in the software’s behavior. The latter require ordinary service contracts, data permissions, deadlines, retries, budgets, and observability. The documented BestBuds proposal places a Koog-based orchestration loop on the JVM, with edge-side prefilters and graph-backed tools, memory, and moderation outcomes [116]. This is a proposed integration, not evidence that every agent loop already runs through Reaktor. An application agent can be exposed as a service or actor-shaped component. Its internal strategy graph is related to, but not identified with, the full application graph. A tool invocation can reach a typed Reaktor operation; the operation’s authorization is enforced independently of what the model says. A structured model response must still be checked against application invariants. Nondeterministic generation is an explicitly recorded dependency when replaying a product workflow. Browser-local assistance is a separate realization choice. The documentation distinguishes browser-managed task APIs from application-managed WebGPU inference [117]. Both require feature probes, download and memory handling, permissions, cancellation, and a fallback policy. Local execution can reduce data movement, but does not prove a model trustworthy or suitable for authoritative decisions. A capability profile can select local summarization while reserving another task for a remote service under its own budget and privacy policy.
28.4 Reusable discoveries, not perpetual rediscovery
A successful agent-assisted change should leave durable engineering assets: source, contracts, tests, examples, migration rules, and operational evidence. A newly implemented feature package becomes discoverable to the next author. A counterexample can become a regression test. A repaired integration can gain a provider conformance check. This is the connection between agent acceleration and engine development: improvements become structured capabilities rather than remaining isolated generated patches. The interaction model follows the practical emphasis on usable tool interfaces and persistent feedback in SWE-agent and long-running-agent harness work [118, 119, 120]. The next section defines the limits of the resulting capability-growth claim. More automation can accelerate composition; it cannot establish unprovided contracts or remove the need to validate a new mechanism.
Original page layout, starting at page 70
29. Capability growth and the changing division of programming work
A platform can expand what applications are practical to build without changing the set of computable mathematical functions. A native application language may already be Turing complete, yet an installed application cannot necessarily load new feature code, invoke a robot actuator, stream a GPU buffer, or participate in a particular authentication protocol. These depend on available mechanisms, permissions, resource budgets, and supported realizations. This distinction makes the idea of adding a new “dimension” to Reaktor precise.
Old mechanism set New mechanism Conservative extension
P 𝑐 and its laws P ′ = P ∪ {𝑐}
preserved realizations
Feasible systems under stated assumptions Feasible systems
S(P, E, B) S(P ′ , E, B)
Figure 8: Capability growth under a fixed environment E and budget B. A strict increase requires a witness that the old mechanism set cannot realize within those constraints; a new API name alone does not establish it.
29.1 A realizable-system space
Let a platform description P contain a typed vocabulary, component implementations, protocol modules, realization providers, runtime capabilities, and assurance rules. Let E describe the execution environment and its available resources. A budget B can constrain memory, latency, operational cost, engineering complexity, and deployment policy. Define
S(P, E, B) = {(𝐻, 𝜌) | 𝐻 is well typed, 𝜌 is supported, and the stated constraints hold}. (27)
This is a set of qualified architectural realizations. It is not automatically a vector space. Adding two applications need not yield an application with a meaningful additive inverse; scalar multiplication of an authorization protocol is undefined. Typed composition, refinement relations, and constrained search are more appropriate mathematical structures. A platform vocabulary can nevertheless act like a collection of generators. Registered components and protocols are combined through permitted module composition, connection, hierarchy, and transformation rules. The closure of these generators describes the systems expressible by those rules. A new generator can create combinations that were previously unavailable. Existing frameworks already exploit this principle through libraries, compilers, and plugin systems; Reaktor’s proposed distinction is to package the relevant cross-system contracts and evidence with the mechanism.
29.2 Conservative extensions
An extension P ⊆𝑐 P ′ is conservative for a stated environment and budget when old well-formed descriptions retain their meaning and supported realizations, the new mechanism is optional, and its presence does not consume or revoke resources required by unchanged applications. Conservative extension is a property to establish, not a default label for adding a plugin.
Proposition 29.1 (Preservation under conservative extension). If P ′ is a conservative extension of P for E and B, then there exists an identity-preserving embedding
𝜄 : S(P, E, B) ↩→ S(P ′ , E, B). (28)
Proof. Map each old description and realization to its unchanged interpretation in the extended platform.
Conservativity preserves typing, supported bindings, behavior, and the relevant resource and policy
conditions. Distinct original descriptions retain distinct identities, so the mapping is injective. □
The proposition states an extension discipline. A stronger default security policy, an incompatible compiler change, or eager allocation by a new runtime can deliberately break its assumptions. Such a change may be justified, but it is a migration rather than a conservative expansion. Strict expansion requires a witness relative to the stated constraints. Consider an installed host that already contains qualified Hermes and FFI capabilities, while the original platform vocabulary exposes only static-native artifact bindings. Under a requirement that the installed host binary remain unchanged,
an otherwise unavailable implementation update can become realizable when an extension adds the checked artifact-loading and LiveUpdate protocols using those existing host capabilities. The witness concerns the supported realization language, not a newly computable function. If the host lacks the loader or bridge, a native host release must install it first; that changes E and is not an example of strict expansion under an unchanged environment. Distribution policy and the resource budget must permit the new realization in either case.
29.3 Where vector spaces are genuinely useful
Numerical design descriptors can live in a vector space. A feature map
Φ(𝐻, 𝜌) = (𝑚𝑒𝑚𝑜𝑟 𝑦, 𝑙𝑎𝑡𝑒𝑛𝑐𝑦, 𝑒𝑛𝑒𝑟𝑔𝑦, 𝑐𝑜𝑠𝑡, 𝑢 𝑝𝑑𝑎𝑡𝑒𝑆𝑖𝑧𝑒, . . .) ∈ R𝑑 (29)
can support measurement, optimization, embeddings, and comparison. Units must be retained or normalized before combining coordinates. Some entries may be intervals, distributions, categorical values, or unknown rather than reliable scalars. Feasible designs form a constrained subset, generally nonlinear and discontinuous. A newly supported mechanism may add a useful coordinate to the design process, such as update granularity or a formally characterized timing profile. It can also enlarge the feasible subset in existing coordinates: a more efficient codec can satisfy a latency budget without adding any new interface shape. Linear independence of sampled feature vectors does not prove that two software capabilities are semantically independent. Rank and basis terminology should be restricted to the numerical model where those operations are defined. This distinction strengthens the original intuition. The platform grows through reusable semantic mechanisms, while vector and optimization methods help characterize the resulting design space. The language of typed algebras explains composition; linear algebra explains selected quantitative analyses.
29.4 A capability package carries more than code
A reusable extension should include its endpoint and domain schemas, permitted compositions, imple-mentation artifacts, realization support, lifecycle, failure semantics, resource ownership, migration rules, source mappings, and tool operations. It should also include conformance tests, property obligations, and evidence about supported guarantees. These items need not all be large. A pure formatter may require little beyond types and tests; a durable workflow runtime requires considerably more. For example, a robotics adapter is incomplete if it only exposes move(x,y). It needs the coordinate frame, units, command lifetime, actuator authority, feedback protocol, failure behavior, and the safety boundary within which commands are accepted. A dynamic-code extension is incomplete if it only evaluates a bundle. It needs artifact compatibility, capability restriction, update closure, generation routing, state handling, and recovery. A human engineer or research team can identify the missing mechanism, build a proof of concept, characterize its limits, and convert it into such a package. Once adopted, applications and agents can compose it without rediscovering every integration detail. The reusable contribution is the mechanism together with its conditions of correct use.
29.5 Human and agent responsibilities
The architecture should preserve several human responsibilities explicitly: deciding which problem is worth solving, choosing acceptable risks and constraints, acquiring domain knowledge, recognizing an inadequate abstraction, and approving changes to the platform’s trust boundary. These are design responsibilities, not a claim that agents can never assist with them.
Agents are useful as candidate generators, implementers, search assistants, test authors, and investigators. They can help find counterexamples and propose a better decomposition. They can also propose new platform mechanisms. However, a capability extension can alter the set of permitted effects and the meaning of verification. It deserves review at a different authority level from application composition. The desired loop is not “humans specify everything, agents type everything.” It is iterative: a difficult task exposes a missing abstraction; people and tools explore it; a precise contract and implementation emerge; evidence identifies the supported domain; and the platform makes the result reusable. Subsequent work can proceed at a higher level while still retaining access to the underlying implementation.
29.6 Evidence about agent environments
SWE-agent demonstrates that the interface through which a model navigates, edits, and tests a repository affects software-engineering performance [118]. Anthropic’s long-running-agent report emphasizes initialization, durable progress artifacts, incremental work, and end-to-end feedback [119]. OpenAI’s harness-engineering report describes repository legibility, architectural constraints, isolated work environ-ments, and tools as central parts of an agent-first development workflow [120]. These are precedents for environment design, not measurements of Reaktor. Reaktor can expose a bounded context package containing the relevant graph projection, source files, contracts, applicable constraints, available operations, and evidence. It should retain lexical search and ordinary source inspection. A graph record saying that a handler is idempotent cannot replace reading or checking its implementation when that claim is not already established. An agent’s context also has a budget. Returning the entire system graph increases noise and can expose unnecessary information. A task-specific working set should include boundary summaries, proof dependencies, and unknowns, with explicit expansion operations. The objective is sufficient context for the task, not maximal context by byte count.
29.7 Faster generation shifts rather than removes bottlenecks
Suppose a development pipeline has proposal generation, implementation, verification, review, and deployment capacities 𝜇1 , . . . , 𝜇 𝑘 . A simple flow model bounds sustained completed work by its limiting stage. Increasing proposal throughput alone can enlarge the review backlog rather than increase accepted changes. This is a modeling observation, not an empirical estimate of future productivity. The graph can improve the limiting stages by narrowing test selection, attaching source-linked counterexamples, preserving implementation intent, and showing which assumptions a change affects. It can also make bad changes fail earlier. The value of formal methods grows when inexpensive proposal generation creates many alternatives but only a subset can be safely integrated. Test-passing and useful change acceptance are different outcomes. METR’s March 2026 study reports a substantial gap between benchmark-passing patches and maintainer acceptance for the agents and repositories it examined; the study’s scope does not establish a permanent limit on future agents [121]. Evaluation should therefore measure accepted changes, maintenance burden, regressions, and review effort in addition to test completion.
29.8 Three trajectories, one robust architecture
Under an incremental trajectory, models improve unevenly and humans remain heavily involved in implementation. Reaktor is useful through typed navigation, local checks, source-linked views, and ordinary modular programming. Agent integration remains optional. Under a strong-agent trajectory, implementation becomes cheaper and more parallel. Reaktor supplies permissioned context, isolated execution, reproducible checks, structured proposals, and explicit approval. The platform must prevent a proposer from silently weakening tests or policies to obtain a passing result.
Under a rapid-capability trajectory, agents contribute increasingly to runtime mechanisms, compilers, and proof development. Reaktor’s extensible vocabulary and verification boundaries become more important, because accepting a new mechanism changes what many applications can do. Mechanism review, evidence provenance, independent checking, and compatibility policy remain necessary even when the implementation process is highly automated. These trajectories are scenarios rather than dated predictions. The architectural investments common to all three are explicit interfaces, faithful source mappings, bounded context, reproducible execution, scoped authority, and reviewable evidence. They do not depend on selecting a particular model vendor or assuming an uninterrupted rate of model improvement.
29.9 Avoiding false confidence from multiple agents
Several agents can share the same mistaken specification, incomplete graph, or training-induced assumption. Agreement among them is not equivalent to independent experimental replication or a proof. A critic can be useful when it examines different evidence and applies a distinct review procedure, but an ensemble vote should not replace a protected verifier or human authorization boundary. The trusted base includes source elaboration, policy enforcement, model extraction, test infrastructure, and evidence handling. An agent that can modify all of these can make an unsafe patch appear acceptable. The platform should distinguish application edits from changes to the apparatus that judges them, and audit the latter at an appropriate authority level. The long-term opportunity is therefore a compounding engineering environment: improved models accelerate work within explicit contracts, and improved human-designed mechanisms enlarge the supported system space. The graph connects these contributions to their assumptions and implementations instead of treating each completed code generation as an isolated artifact.
Original page layout, starting at page 71
Source figure pages
Original figure page 66
Original figure page 68
Original figure page 72
