Beyond 'Everything Is a Plugin': Defining Production Responsibility in Agent Harness

Introduction: The Production Boundary After "Everything Is a Plugin"

The previous five articles established a plugin-centric Agent Runtime that can load plugins, replace dependencies, isolate capabilities, and pause or resume tasks during execution. However, moving to production raises three harder questions:

1. Plugins can be unloaded — what happens to the consequences of external actions?
2. Capabilities can be replaced — can we still trust results produced by the old version?
3. The Agent says the task is complete — who proves it actually completed?

These questions define the production boundary that must be added after "everything is a plugin." The runtime manages how capabilities enter and exit, but it cannot alone bear all production responsibility. External side effects need action contracts, version changes need impact analysis, and task completion needs independent evidence. Missing any of these, the more flexible the runtime, the harder production risk becomes to control.

Conclusion First: Composable Runtime Is Not the End of Production Responsibility

A production-grade Agent system must separate at least three categories of responsibility:

Runtime manages capabilities.

Action contracts manage consequences.

Audit evidence manages accountability.

Plugin count, tool-call volume, and automation degree do not prove production readiness. What matters is that every capability assembly, external execution, and state change can be explained, constrained, and verified.

From "Add Login Rate Limiting" to Production: The Problem Is No Longer Just Code

Continuing the case study of adding rate limiting to a login endpoint:

Development phase: Agent modifies code, runs builds and tests. Failures stay inside the workspace and test sandbox.

Release phase: The pipeline becomes: design baseline → config generation → canary release → result receipt.

When the plugin is safely unloaded, the production state is not automatically restored. Configuration may already be written, canary traffic switched, alerts fired, release notifications sent. Even though the runtime cleans temporary files, connections, listeners, and tool registrations, these external consequences persist.

Runtime reversibility ≠ business consequence reversibility.

This is not a defect in the plugin mechanism; it is a problem the plugin mechanism was never meant to solve alone.

Classify Side Effects First, Then Discuss Recovery

"Reversible side effects" are often misunderstood as "all actions can be rolled back." Real systems handle different side effects differently:

Local temporary side effects can usually be undone.

External actions often can only be compensated. For example, restoring an old configuration cannot erase requests already processed under the new configuration; reverting a database update may not automatically revert triggered downstream processes.

Therefore, the runtime cannot simply call dispose() and assume production consequences are handled. It cleans up local resources left by components; the task graph then routes to verification, compensation, human confirmation, or blocking based on the external action state.

External Actions Need Contracts, Not Just Tool Definitions

A tool definition typically answers: name, parameters, return value. A production action must also answer: who can execute, under what preconditions, what consequences it produces, how to prove success, and how to handle failure.

Example: an action contract for publishing a rate-limit configuration:

action: rate-limit-config.publish
target: production/config-center
preconditions:
  - design-baseline-approved
  - regression-tests-passed
effect_class: external-compensatable
permission: release-operator
approval: required
idempotency_key: "${task_id}:${config_version}"
success_evidence:
  - config-center-receipt
  - canary-health-check
  - traffic-policy-verification
compensation:
  action: rate-limit-config.restore
  input: previous-config-version

The key point is not the field names but that an external action must explicitly declare five things: preconditions, effect class, permission/approval, idempotency, success evidence, and compensation. The compensation is a new corrective action, not a full undo of already-occurred external impact.

Action contracts are not about writing longer natural-language prompts; they are about embedding constraints into the call chain that the model cannot bypass. Permission systems, action gateways, external business systems, and audit systems must each enforce their own hard constraints.

Same Interface Name Does Not Mean Same Production Capability

The third article covered how the runtime rebinds capabilities after dependency changes. Production governance must further answer: which approved capability version was actually used for a given external action? Can old evidence still support current responsibility judgments?

An actual capability binding must be traceable to:

Task result
→ bound actual plugin version + artifact digest
→ bound permissions, environment, and policies at that time
→ bound input baseline + external execution receipt

For instance, deploy.execute-v2 and deploy.execute-v3 may expose the same call interface, but approval rules, target environments, rollback strategies, or evidence formats may have changed. Interface compatibility only means the call may still succeed; it does not prove that the old version's test and release evidence remains valid.

Any change in these bindings requires re-verification based on impact scope. Version governance aims not to block upgrades but to prevent the system from continuing to rely on old results and old responsibility judgments after capabilities have changed. Production should not allow the Agent to dynamically discover and load plugins from arbitrary sources. Phase 1 at minimum requires an approved list, fixed sources, version constraints, and compatibility validation. Dynamic composition can only occur within the already-authorized candidate capabilities.

Agent's "Completed" Is Not Audit Evidence

Agents easily output conclusions like:

Configuration published, canary verification passed, task completed.

This is a conclusion, not evidence. The model may misread logs; the tool may have only partially completed; a network timeout may leave the Agent unaware whether the external system received the request. Truly verifiable evidence must come from independent toolchains and external system receipts, not from the Agent's own "pass" statement.

A production action must leave at least three categories of records:

Capability assembly record

External action receipt

Independent verification result

Audit is not dumping all prompts and logs together. Logs help troubleshooting, but audit needs stable correlations: one task, one capability binding, one external action, one approval, and one set of verification evidence must be mutually locatable. The final completed state should be derived by controlled rules from evidence, not freely declared by the model.

The Most Dangerous Situation Is Not Explicit Failure but Unknown Result

Continuing the config publish example: the Agent sends a request and the connection times out. It cannot determine whether the config center executed successfully.

Retrying directly may duplicate the publish.

Judging failure directly may continue using old assumptions after the production config has already changed.

Marking complete directly lacks sufficient evidence.

A more reasonable handling:

blocked

— not system incapability, but explicit knowledge that current evidence is insufficient to proceed automatically. waiting_human — not automation failure; high-risk actions, irreversible consequences, and exception handling inherently require a responsible person's judgment.

The most dangerous behavior is the Agent interpreting "unknown" as "should be fine" just to keep the flow smooth.

Who Is Responsible for Production Must Be Clear in the Architecture

"Humans are ultimately responsible" is correct but incomplete. If the system does not map responsibility to concrete boundaries, humans cannot know what they are approving.

A controllable responsibility division:

Agent Runtime : Resolve actual capabilities, enforce capability visibility, call interception, and resource isolation in Context; record capability bindings and state changes.

Plugin Provider : Declare capability contracts, compatibility ranges, local side effects, and cleanup methods; external actions constrained by action contracts.

Action Gateway & External Systems : Perform final authorization, idempotency, and business validation; store authoritative execution facts; provide compensation entry points allowed by the business.

Loop : Handle intra-node local retries and re-verification; do not autonomously expand action scope.

Task Graph : Route compensation, wait-for-human, and blocked states based on evidence; control failure propagation and recovery scope.

Responsible Person : Approve high-risk actions, handle exceptions that cannot be automatically judged, and accept final business outcomes.

There is no single "master Agent" bearing all responsibility. Responsibility is split to where control and fact sources actually reside; the Agent organizes execution within those boundaries.

Phase 1: Validate Only One Real External Action

No need to build a plugin marketplace, full supply-chain platform, or complex audit center upfront. Start by validating the mechanism in a test environment (which only proves the pipeline runs, not production readiness). Then select one low-risk production action with clear impact and compensatable behavior — e.g., updating a rollbackable canary policy — and close the minimal loop:

Fix approved plugin sources, versions, and artifact digests.

Declare action preconditions, permissions, scope, side-effect type, and compensation method.

Execute via action gateway with authorization, idempotency control, and external receipt capture.

Associate actual capability binding, input baseline, approval, and verification results to the same task.

Verify external state with independent tools; do not accept Agent self-report as completion evidence.

Validate three exception paths: plugin mid-exit, call timeout with possible external success, version change invalidating old evidence.

First prove the system can stop, investigate facts, and recover per boundaries when external consequences have occurred, execution state is uncertain, or capability versions change. Only then expand the range of production actions the Agent can execute.

Summary

"Everything is a plugin" gives the Agent Runtime composition, replacement, and evolution capabilities, but flexibility alone does not equal production capability.

1. Local side effects cleaned up by runtime.
2. External side effects constrained by action contracts.
3. Version changes governed through actual binding and impact analysis.
4. Task completion proven by independent evidence.
5. Unconfirmable states enter wait, block, or compensation flows.

The key to production readiness is not how many plugins the Agent can call, but that every capability assembly, execution, and change is explainable, traceable, verifiable, and that the system explicitly stops when it exceeds automation boundaries. This series has moved from "why we need a composable runtime" to "how the composable runtime assumes production responsibility." Harness, Loop, task graph, component runtime, and audit mechanisms each solve different problems; only when their boundaries are clearly composed together can an Agent evolve from a flexible execution framework into a truly controlled production system.