From Conversation to Control Plane

1. Introduction

Many agent systems begin with a natural operating pattern: a person gives an instruction, a model inspects state, chooses a tool, observes the result, reasons again, and repeats. This interaction loop is flexible and easy to prototype. It also encourages operational facts to remain distributed across conversation history, tool responses, model context, and transient execution state.

That distribution becomes costly as workflows become longer, more concurrent, or more consequential. A model may repeatedly reconstruct facts that a deterministic system could already know: which task is next, whether an action is allowed, whether a receipt already exists, whether a batch is paused, which browser handoff is owned by a particular job, or whether an earlier command is a safe replay.

SignalRivet encountered this problem while using BOSS to prepare and execute a small batch of real job applications. The application logic itself was not the dominant difficulty. The larger friction came from orchestration: repeated inspection, task identity, queue state, exact targeting, browser ownership, replay safety, and recovery after partial failure.

2. The orchestration bottleneck

2.1 Conversation is not durable machine state

A conversational transcript can describe operational state, but description and state are not the same object. A queue position in prose can become stale. A human instruction to pause execution can be forgotten by another worker unless it becomes a durable control value. A task identifier copied between turns can drift from the canonical identifier stored in the execution system.

The observed design problem was therefore not "how do we make the model smarter?" It was "which decisions require intelligence, and which facts should never require the model to reconstruct them?"

2.2 Interaction-loop cost

Let a conversation-driven workflow require n orchestration turns. For turn i, let C_i be the context transferred to the reasoning layer, T_i the reasoning/tool latency, and E_i the probability-weighted recovery cost induced by stale or ambiguous state. A simple operational cost model is:

A control plane does not eliminate reasoning. It changes the unit of reasoning. Instead of rehydrating the whole operating world, the model receives compact current state and emits a bounded command. Routine state transitions occur deterministically outside the interaction loop.

3. Related work

Recent work increasingly treats persistent state and orchestration as first-class concerns in LLM systems. AgentR describes a stateful and recovery-aware architecture with durable workflow artifacts, explicit state transitions, retries, orphan detection, and auditable cost accounting [1]. A separate hierarchical orchestration architecture argues that flat tool registries create decision-space and context pressure, and proposes localized capability discovery with deterministic execution structure [2].

Control-plane governance has also been proposed as a way to place human input, provenance, and assurance around multi-component AI systems rather than treating trustworthiness as a property of the model alone [3]. These themes are directionally consistent with the BOSS architecture described here, although our implementation was developed independently from an operational bottleneck in a local system.

This note also extends SignalRivet Research Note 001, which separated lifecycle completion from proven semantic completion [4]. The present work moves one layer outward: if completion must be evidence-backed, then the system that routes work, owns state, and authorizes execution must itself be explicit and inspectable.

4. Control-plane architecture

4.1 Architectural layers

4.2 Versioned command contract

Machine commands use the schema boss.control.command.v1. The envelope carries an explicit request identifier, an allowlisted action, and action-specific arguments. Unknown top-level fields and unknown action arguments fail closed. The command envelope is hashed and stored with its durable receipt, allowing exact-envelope replay checks rather than relying only on similar parameters.

4.3 Exact scoping

The original browser path could identify the next job in Batch X and then call a global browser claimant that might select an unrelated older item. The repaired path carries the exact handoff identifier through the browser supervisor. A named batch therefore selects and claims only its own handoff.

4.4 Durable human authority

The system stores operational pause state durably. The live browser proof did not begin until the Founder explicitly approved unpausing job execution. Final submission remained outside the scope of the experiment. PRE_SUBMIT work could navigate, populate ordinary fields, upload supplied artifacts, and collect evidence, but it could not submit an application.

5. Method

Evaluation combined deterministic regression testing with two live, bounded canaries. The canaries were selected from already prepared job packets and were executed one at a time through the scoped control plane. The experiment intentionally stopped at the PRE_SUBMIT boundary.

5.1 Compact-state measurement

A full status representation and the compact operator representation were measured on the same local control system. The observed payload sizes were 30,478 bytes and 1,244 bytes respectively. The reduction is:

The corresponding observed local retrieval times were approximately 101 ms for the full status path and 83 ms for the compact operator path. These are single-environment observations, not a statistically powered latency benchmark.

5.2 Live canary protocol

1. Create or select a fresh one-job batch through the versioned command plane.
2. Confirm one exact handoff is in READY_FOR_BROWSER.
3. Dispatch only that named batch using JOB_DISPATCH_BATCH_ONE.
4. Require the fresh browser executor to establish Chrome DevTools MCP readiness before starting the model turn.
5. Require browser-tool evidence and preserve unrelated queued work.
6. Stop at PRE_SUBMIT and classify the observed result as READY or BLOCKED.
7. Project the result into the shared receipt table, reconcile campaign state, and run deterministic promotion.

6. Results

6.1 Live canaries

6.2 Execution evidence

Across both canaries the fresh executor recorded 52 tool events. Twenty-eight were browser-tool events, giving an observed browser-event share of 53.8%:

6.3 Regression snapshot

After the final integration changes, 41 unit tests covering the Control Bridge, command API, browser executor, and fresh-thread executor passed. Fourteen additional job-control function tests covering campaign, browser pipeline, and supervisor behavior also passed.

7. Failure-driven hardening

The most useful result was not that the first canary passed cleanly. It did not. The live path exposed integration seams that synthetic tests had not yet forced into view. Each failure was preserved as evidence, repaired at the smallest responsible boundary, and converted into regression coverage where practical.

8. Discussion

8.1 Intelligence moves upward rather than disappearing

The control-plane approach is not an argument for removing AI from agent systems. It is an argument for placing model reasoning where uncertainty actually exists. The model remains useful for intent interpretation, ambiguous browser forms, exception handling, prioritization, and deciding what should happen next. SQLite state, task identity, replay rules, policy classification, and exact queue ownership do not benefit from being repeatedly re-decided in natural language.

8.2 Deterministic control reduces the surface area of memory

When the canonical queue, pause state, capability manifest, command receipts, and execution evidence are durable, conversational memory becomes less operationally critical. A fresh reasoning session can recover by reading compact current state instead of reconstructing history from an entire transcript.

8.3 Human authority becomes a state transition

The Founder pause was not merely a sentence in chat. It became durable execution state. Likewise, unpausing was an explicit authority transition. This is a useful pattern for consequential agent systems: human approval should change a governed state object rather than depend on downstream components remembering that approval was once spoken.

8.4 Evidence outranks confidence

Both live canaries ended BLOCKED, yet they were successful architecture tests. The system reached genuine external conditions, recorded browser evidence, preserved the final-submit boundary, projected durable receipts, and reconciled terminal state. A reliable control plane should prefer a truthful BLOCKED result over a confident but unsupported success claim.

9. Limitations

1. The live empirical sample contains only two browser canaries. A 2 / 2 result must not be interpreted as a general success rate.
2. Both live canaries terminated BLOCKED. The architecture has not yet been demonstrated on a live PRE_SUBMIT_READY job under this exact control-plane path.
3. The 95.9% payload reduction compares two representations in one local system. It is not a universal reduction for other agent architectures.
4. The observed 101 ms and 83 ms status timings are local point measurements, not repeated latency distributions.
5. The six-job conversation-vs-control-plane benchmark that motivated this work has not yet been rerun under the completed architecture.
6. Legacy state remains in BOSS, including unscoped browser handoffs and stranded older PRE_SUBMIT tasks. Those were intentionally excluded from the scoped proof.
7. The control plane reduces orchestration ambiguity but does not eliminate model error inside tasks that genuinely require reasoning.

10. Benchmarking implications

Agent benchmarks often emphasize task success, model choice, or tool-use accuracy. A production control architecture introduces another dimension: how much of the operating world must be repeatedly exposed to the model for a task to move forward?

A future benchmark should compare the original conversational workflow with the completed control-plane workflow on the same six-job task set. The planned measures are human turns, orchestration calls, bytes transferred into the reasoning loop, preparation latency, browser time, failures, recoveries, and total elapsed time.

11. Conclusion

The control-plane work began as a performance investigation and became an architectural change. A real workflow demonstrated that repeated conversational orchestration was carrying responsibilities better suited to durable software: queue ownership, policy, replay, task identity, browser scoping, execution evidence, and state reconciliation.

The resulting architecture does not ask AI to be less capable. It asks AI to spend its capability on the parts of the problem that deserve reasoning. Deterministic components own the parts that should remain true regardless of which model is currently thinking.

In the bounded evidence reported here, that separation was sufficient to move two real browser tasks through a versioned command plane, exact scoped execution, evidence collection, shared receipts, reconciliation, and deterministic terminal classification without crossing a consequential submit boundary. The next step is empirical scale: rerun the motivating six-job workload, quantify the orchestration savings, and continue converting live failure modes into explicit invariants.