PCS: a closed-loop system for controlling a product

Once an AI agent can affect a running product, the problem stops being a prompt-writing exercise. The agent may read logs, choose a command, and run it. Who checks that it saw current state, respected the safety boundary, and actually produced the requested result?

I wrote down Product Control System (PCS) as a methodology for answering those questions. A PCS runs changes through a closed loop: a user request, a metric deviation, an integration failure, or a scheduled operation becomes a case; the system gathers evidence, plans and authorizes an action, checks the effect, and records what it learned.

PCS is not another agent or framework. It does not prescribe a stack, platform, or repository layout. It defines the responsibilities and artifacts required for an agent to change a product in a way that can be reviewed afterwards.

Why an agent alone is not enough

The usual pattern is simple: give an agent context, let it reason, call a tool, and report success. That works for a demo. Production raises different questions.

Was the context current? Was the empty API response really “no incidents”, or did the API fail? Who authorized this exact change? A chat confirmation does not bind a person to a plan and its parameters. Does a successful command prove the postcondition? Usually it does not.

PCS puts these questions into one logical cycle:

Model → Sense → Estimate → Decide → Authorize → Execute → Verify → Learn

These are responsibilities, not necessarily eight services. A small implementation can handle several phases in one process. The important part is that the phases are distinguishable and recoverable from the case record.

Model: what the system knows

Model is the working representation of the product. It includes the boundary of the runtime environment, components and dependencies, goals, policies, safety invariants, known failure modes, and the catalog of permitted actions.

Important claims need a source, collection time, expiry, and confidence. “The provider retries webhooks for 24 hours” is a weak basis for a decision if nobody can say where the statement came from or when it was last checked.

A model can become stale. When a claim is disproved, the old and new versions cannot simply sit next to each other while the agent guesses. PCS requires the discrepancy to reach a recorded outcome: correct the claim, retain the history, and create an observability task when needed.

Sense and Estimate: facts before conclusions

Sense collects unchanged evidence: metrics, logs, traces, consistency checks, external events, and human reports. Each item carries its source, timestamp, target environment, measurement scope, and collection state: success, partial, or fail.

That distinction matters. If a collector read only the latest 200,000 log lines, the report must say partial. It cannot present an incomplete sample as proof that no event occurred.

Estimate separates evidence from the state assessment. It records facts, conclusions, unknowns, and competing hypotheses. Reproducing a failure in a test environment shows that a cause is possible; it does not prove that the same cause produced the production incident.

For high-risk cases, the assessment should be checked independently. The reviewer needs the original requirements and evidence, not only the agent’s conclusion.

Decide and Authorize: a plan before a command

Decide produces an action plan. The plan includes its goal, chosen strategy, alternatives, expected result, preconditions and postconditions, risk, blast radius, time limit, retry rules, and rollback or compensating action.

The plan becomes immutable after authorization. If new evidence changes it, that is a new plan and needs a new authorization.

Authorize grants permission to a specific action, rather than to the agent as a whole. The permission is tied to the operator identity, plan hash, target objects, parameters, and expiry. A global flag such as ALLOW_CHANGES=1 does not carry those bindings.

Authorization can depend on risk. Restarting a stateless worker may be pre-approved. Sending customer notifications or changing data requires authorization for a particular set of objects. Critical operations may require dual control.

Execute and Verify: the command is not the result

Execute runs a typed operation and records attempts and actual effects. Each operation defines its scope, reversibility, preconditions, retry limit, timeout, and partial-execution rules.

Verify checks the result through an independent sensor. The actuator’s own “success” response is not enough: a command may return 200 while the database or external service still lacks the expected state.

The example shop in the PCS repository has a resync-payment-status operation. It accepts one to 500 order IDs, checks payment status with the provider, and creates shipping tasks. The result is verified through a read-only Postgres query. The operation is idempotent by order ID, allows at most three attempts, and reports partial execution explicitly.

In the same example, notification delivery returned 34 of 35, while the warehouse check was not-checked because the API timed out. The case could not be closed as successful: one postcondition failed and another was unknown. The customer went to support, and the warehouse check was repeated after the API recovered.

Learn: closing a case changes the system

Learn does not mean that the model rewrites itself after every guess. It means recording the outcome, updating confirmed facts, and creating work for gaps that the case exposed.

In the shop example, the provider turned out to retry webhooks three times within ten minutes, rather than for 24 hours as the model claimed. The statement was corrected, the old version kept in history, and a retry strategy was added for payment resynchronization. A new sensor was also queued to track the time since the last processed webhook.

That closes the loop: the result of an action changes the next version of the model and the checks used by future cases.

What PCS requires

Safety invariants are checked technically before and after an action. Human approval must not become a way to bypass a rule such as “never charge an order twice”.

Sensors and actuators are inventoried. Each has an owner, a data scope, and a health check. Access follows least privilege.

Every action is reconstructable from the audit trail: case, plan version, authorization, attempts, and effects share a correlation ID. Break-glass access is possible, but it is restricted, recorded, and followed by a case to turn the emergency path into a typed operation.

PCS also measures itself: full loop latency, successful-action rate, human intervention rate, and break-glass usage. Without these measurements, it is impossible to tell whether the controller is getting safer.

Where it applies

PCS does not replace observability, CI/CD, IAM, support, or a secret store. It uses them as evidence sources and execution mechanisms. The methodology is for systems where an agent can affect a running product and the path from signal to verified outcome needs to be auditable.

The current methodology is version 2.4 and is still being designed. In the shop example, the technical core mostly passes the conformance matrix; periodic measurements, automatic drift detection, and some break-glass procedures remain partial. That status is more useful than a polished complete: the matrix shows what still needs work.

Repository: github.com/IvanShishkin/pcs.