The Deployment That Gave an AI Agent a Steering Wheel

When you build an autonomous agent to manage a fleet of GPU proving machines, you inevitably face a fundamental tension: how much control do you give the human operator, and how much do you leave to the AI? In the opencode session under analysis, this tension crystallized around a single, seemingly simple parameter — target_proofs_hr, the number of proofs per hour the agent should aim to sustain. Message [msg 4656] is the deployment and verification of a feature that transformed this parameter from a hard-coded constant into a live, operator-adjustable control, complete with automatic notification to the agent. It is a masterclass in how to close the loop between human intent and autonomous action.

The Context: An Agent Learning to Scale

To understand why message [msg 4656] matters, we must first understand the agent it serves. The preceding chunks of this segment (see [chunk 32.2] through [chunk 32.5]) describe the construction of an LLM-driven fleet management agent for a distributed GPU proving infrastructure running on vast.ai. This agent observes demand for SNARK proofs, monitors a fleet of rented GPU instances (RTX 5090s, RTX 4090s, etc.), and makes autonomous decisions about when to launch or stop instances to maintain a target throughput.

The agent's core objective was originally hard-coded: maintain 500 proofs per hour. This value lived in DefaultAgentConfig() in the Go backend, invisible to the operator and unchangeable without editing source code and redeploying. The user recognized this as a critical limitation. In [msg 4640], they issued a succinct directive: "Make the target proof/hr a setting in the UI, when updated agent should be notified."

This is a deceptively simple request. It touches three layers of the system simultaneously: the backend API (persist and serve the config), the frontend UI (display and edit the value), and the agent's conversation loop (inject the change as a message the agent can see and act upon). The assistant's response in [msg 4641] laid out a three-item todo list that precisely maps these layers, and the subsequent messages ([msg 4642] through [msg 4655]) executed them in a rapid, methodical sequence of code edits and a build.

What Message 4656 Actually Does

Message [msg 4656] is a single bash command, but it is not a simple one. It is a deployment-and-verification script that executes in four distinct phases, each testing a different aspect of the system.

Phase 1: Deployment. The compiled binary (vast-manager-agent) is copied to the management host at 10.1.2.104 via SCP. The vast-manager systemd service is stopped, the binary is replaced, and the service is restarted. This is routine infrastructure work, but it carries risk: a bad binary or a failed restart could take down the entire management dashboard and the agent with it.

Phase 2: Read-Before-Write Verification. The script immediately issues a GET request to the config endpoint and parses the JSON response to extract target_proofs_hr. The output confirms target=500 — the default. This establishes a baseline before any mutation.

Phase 3: Mutation and Verification. A POST request updates the target to 300. The response {"changed":1,"ok":true} confirms the database write succeeded. A subsequent GET confirms the value persisted: target=300. Then the script checks the agent's conversation log for the notification message, and finds: [Config changed] target_proofs_hr: 500 → 300 (set by operator). This is the critical validation — the human's intent has been injected into the agent's context as a structured message, indistinguishable from a human chat message.

Phase 4: Cleanup and UI Verification. The target is reset to 500 (the production value), and a grep of the UI HTML confirms that three key identifiers exist: target-proofs-input (the editable input field), updateTargetProofsHr (the JavaScript function that sends the POST), and agentTargetProofsHr (the JavaScript variable that holds the current value). The UI is wired up and ready.

The Architecture of Human-in-the-Loop Control

What makes this message remarkable is not the bash script itself, but the architecture it validates. The assistant made several deliberate design decisions across the preceding messages that this verification confirms.

Persistence via SQLite. The config overrides are stored in a dedicated agent_config table in the existing SQLite database ([msg 4647]). This means changes survive service restarts and are immediately available to both the API and the agent. The assistant chose not to use a separate config file or environment variables, which would have required file-system access and manual editing. Instead, the operator changes the value through the UI, and the backend writes it to the database — a clean, auditable path.

Conversation as a Communication Channel. The assistant's most interesting architectural choice was to inject config changes into the agent's conversation thread as user messages ([msg 4645]). This is not merely a log entry; it is a message in the same format as human feedback, placed at the end of the conversation where the LLM will see it on its next observation cycle. The agent's prompt instructs it to consider all messages in the conversation, so a config change becomes part of the agent's context, indistinguishable from a direct instruction from the operator. This elegantly solves the problem of how to communicate asynchronous human intent to an agent that only "wakes up" every five minutes.

UI as the Operator Interface. The editable target field was placed in the summary cards area of the dashboard ([msg 4651]), alongside the live metrics for running instances, proofs per hour, and budget. This is not an admin panel buried in settings — it is front and center, because the target proofs per hour is the agent's primary objective, and the operator needs to adjust it in response to changing demand or budget constraints without navigating away from the real-time view.

Assumptions and Their Validity

The assistant made several assumptions in this message, most of which proved correct.

The first assumption was that the binary built in [msg 4655] was correct despite the sqlite3-binding compiler warnings. These warnings (about strrchr and strchr usage in the C SQLite binding) are long-standing and benign — they appear in every build of this project. The assistant correctly ignored them and proceeded.

The second assumption was that the POST endpoint would accept the update and return the expected JSON. The response {"changed":1,"ok":true} confirmed this. The changed: 1 field is a nice touch — it indicates that the value actually differed from the stored override, so a database write occurred. If the operator had submitted the same value that was already stored, the endpoint could return changed: 0 and skip the unnecessary write and conversation injection.

The third assumption was that the conversation injection would produce a message visible to the agent. The verification confirmed this: the last message in the conversation was [Config changed] target_proofs_hr: 500 → 300 (set by operator). This message format includes the old value, the new value, and the source of the change — giving the agent full context for why its objective shifted.

The fourth assumption was that the UI would render correctly. The grep for the three identifiers confirmed that the HTML, JavaScript, and CSS all contained the expected elements. However, the verification did not test the actual user interaction — clicking the input, changing the value, and seeing the POST succeed. That would require a browser and a human operator. The assistant implicitly trusted that the JavaScript function updateTargetProofsHr would work correctly based on the code written in [msg 4654].

What This Message Reveals About the Agent's Design Philosophy

The broader context of this session reveals a consistent design philosophy: the agent is not a black box that makes irreversible decisions. It is a system that observes, deliberates, acts, and — crucially — listens. The config change notification is one of several feedback channels the assistant has built. Earlier in the chunk ([msg 4633]), the user could send structured feedback ("Noted", "Good call", "Wrong", "Custom feedback") that was injected into the conversation. Alert acknowledgments were also injected. Now config changes join this stream.

This philosophy reflects a deep understanding of how LLM agents fail. Without a feedback channel, an agent can drift into incorrect behavior — over-provisioning, under-provisioning, or pursuing stale objectives — with no way for the operator to correct it without restarting the conversation or editing code. By making the target proofs per hour adjustable through the UI and automatically notifying the agent, the assistant created a closed loop: the operator sets the objective, the agent pursues it, and if conditions change, the operator adjusts without any engineering intervention.

The Thinking Process Visible in the Message

The message itself is a bash script, but the thinking behind it is visible in its structure. The assistant did not simply deploy and walk away. It built a comprehensive verification suite into the deployment command itself, testing every layer:

1. Service health: Restart and wait 2 seconds, then make HTTP requests.
2. Read path: GET the config and parse it.
3. Write path: POST an update and check the response.
4. Persistence: GET again and confirm the value changed.
5. Agent notification: GET the conversation and check the last message.
6. UI wiring: grep the HTML for the expected identifiers. This is the hallmark of an engineer who has learned from experience that deployments fail in subtle ways. The binary might copy but not restart. The endpoint might return 200 but not persist. The conversation might not contain the notification. The UI might render but the JavaScript might have a typo. Each verification step catches a different class of failure. The cleanup — resetting the target back to 500 — is also telling. The assistant could have left it at 300, but that would have changed the agent's behavior in production. The verification was a temporary mutation to confirm the feature worked, and the assistant responsibly restored the production value.

Conclusion

Message [msg 4656] is a deployment message, but it is also a statement about how autonomous systems should be designed. The assistant built a feature that gives the human operator direct, real-time control over the agent's primary objective, with automatic notification that makes the agent aware of the change. The verification script confirms that every layer of the system — backend, database, conversation, and UI — works correctly and in concert.

In doing so, the assistant transformed the agent from a system that pursues a fixed goal into a system that responds to human intent. The target proofs per hour is no longer a constant in source code. It is a live parameter, adjustable in seconds, with the agent informed and responsive. This is the difference between automation and autonomy — and message [msg 4656] is where that difference was deployed into production.