Reading the Proposal: A Queue for Agent Writes Before Apply

A proposal is a row in its own table, not a message in a chat log. Minimum viable schema:

Two of these deserve emphasis. target_rows must be a resolved list or a bounded query with a count, not a predicate like WHERE territory = 'west', because the row set changes between review and apply. expected_effect must include side effects that the reviewer would not infer from the field name: a notification sent, a work queue reassigned, a downstream automation triggered. The preview guidance is explicit that a reviewer who approves a field change should not discover afterwards that it also contacted a customer the preview playbook.

Here is a compact shape you can store as JSONB:

{
  "proposal_id": "wr_01J8ZK4Q",
  "payload_hash": "sha256:9f2c...",
  "operation": "UPDATE leads SET owner_id = $1 WHERE id = ANY($2)",
  "target_rows": [
    {"id": "A-104", "owner_id": "u_alex", "open": true, "exception": null},
    {"id": "A-118", "owner_id": "u_alex", "open": true, "appointment": "2026-11-02"}
  ],
  "row_count": 2,
  "expected_effect": "owner_id changes on 2 rows; 1 appointment handoff email queued",
  "reversal": {"strategy": "inverse_update", "estimated_minutes": 6, "notification_reversible": false},
  "reversal_cost": "low",
  "requester": {"agent": "agent-crm-07", "task": "T-118", "source": "territory_reassign"}
}

The reversal_cost field is the routing signal. Treat it as an enum with a written justification, not a free number, because a number invites false precision and an enum forces the agent to commit to a category.

Most teams get stuck here because they try to score risk with a formula. A simpler rule works: classify by what it takes to undo, then escalate on sensitivity separately.

This tracks the risk-based rule that approval is required when the next action is irreversible, costly, regulated, or high blast radius, and that writes to production databases belong with a service owner or on-call engineer using a proposed diff, preconditions, a rollback plan, and an idempotency key the HITL workflow guide. Note that the guide lists writes to production databases as high cost of error with medium reversibility, which is exactly the R3 bucket.

Sensitivity is a second axis and should be checked independently. A change to a table holding personal data is not R1 even if the SQL inverse is trivial, because the exposure itself is not undone by an inverse update.

Route on three inputs: reversal class, affected table or domain, and time of day for SLA escalation. Do not route on the agent's own confidence, because a confident agent is not a calibrated one.

def route(proposal, table_policy):
    policy = table_policy[proposal.table]
    if proposal.reversal == "R4":
        return [policy.owner, policy.second_approver], "PT4H"
    if proposal.reversal == "R3":
        return [policy.service_owner], "PT2H"
    if proposal.reversal == "R2":
        return [policy.team_lead], "PT8H"
    return [], "auto"          # R1 plus sampling

Keep the policy table in version control next to the schema. When a new table appears, the absence of an entry should fail closed and route to R3 until someone writes a policy, not silently auto-approve.

Two operational details make routing fast rather than bureaucratic. First, an evidence pack: the proposal, the diff, the preconditions, and the rollback plan on one screen, so a decision takes seconds rather than a meeting. Second, approve-with-edits, so a reviewer who wants a smaller scope does not force the agent to restart the whole plan the HITL workflow guide. If the reviewer edits the payload, recompute the hash and re-route if the class changed.

The apply step should not trust the queue's current state. It should read an append-only decision log and require a match. Five conditions, all mandatory:

1. A decision row exists for this proposal_id.
2. Its payload_hash equals the hash of the operation about to run.
3. The decision is approved, not pending, rejected, or expired.
4. The approver's role matches the route computed at submit time.
5. The decision is within its validity window and the target rows still match the reviewed state.

A decision record worth writing:

{
  "proposal_id": "wr_01J8ZK4Q",
  "payload_hash": "sha256:9f2c...",
  "decision": "approved",
  "approver": {"id": "u_sam", "role": "team_lead", "auth": "sso"},
  "decided_at": "2026-10-14T09:12:04Z",
  "valid_until": "2026-10-14T10:12:04Z",
  "edits": null,
  "reason": "appointment handoff confirmed with ops"
}

Log the decision in the same database as the data being changed, inside the same transaction that performs the apply, or at minimum with a foreign key. If your audit requirements mean the log also has to survive outside the application, database-level auditing is the backstop: the pgAudit extension extends native PostgreSQL logging to capture the user who made a change, and it redacts sensitive values such as cleartext passwords from the logs the AWS pgAudit guide. Use both: an application decision log for the business reason, and statement-level auditing for the independent record of what the SQL actually did.

Expiry matters more than teams expect. A preview can go stale while a person is deciding, so the apply step has to recheck the current state before writing the preview playbook. Concretely: re-read the target rows, compare their version column or a hash of the reviewed fields, and abort with a stale_proposal error if anything moved.

An application-level queue is a promise. A database-level grant is an enforcement. The cheapest way to make the gate real is to give the apply path its own role with only the privileges it needs, and to make sure the agent's own credentials cannot write at all.

Role design follows a least-privilege pattern: create roles per use case such as readonly and readwrite, grant them only the object privileges required, and keep the master or admin user out of application code the AWS roles guide. Postgres privileges are granted per object, and a role that has only CONNECT can log in but do nothing until it receives USAGE on the schema and SELECT on the tables the read-only role discussion. That is the shape you want for the agent.

-- agent: can see what it must propose against, cannot write
GRANT CONNECT ON DATABASE app TO agent_readonly;
GRANT USAGE ON SCHEMA public TO agent_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO agent_readonly;

-- apply service: the only writer
GRANT SELECT, UPDATE ON leads TO writer_apply;

-- proposals and decisions: append only for the app role
GRANT SELECT, INSERT ON write_proposals TO writer_apply;
GRANT SELECT, INSERT ON write_decisions TO writer_apply;
REVOKE UPDATE, DELETE ON write_decisions FROM writer_apply;

The GRANT syntax and the privilege list (SELECT, INSERT, UPDATE, DELETE, TRUNCATE, and others, or ALL) are documented in the PostgreSQL reference the GRANT documentation. The append-only revoke is the part that makes the decision log trustworthy: the same role that applies changes cannot rewrite history.

For a worked cost comparison, consider two designs for the same 2-row update. In the direct-write design, a duplicate retry costs one wasted write and a manual correction, plus the reviewer time to find it. In the proposal design, a duplicate retry hits the unique constraint on proposal_id in the decision log and returns the original outcome. The design costs one extra table, one extra insert on approve, and a policy file. The measured effect in test-suite work is instructive as an analogy: replacing physical cleanup with transaction-level rollback took a 447-test suite from roughly 246 seconds to under 3 seconds, because the rollback is a memory operation rather than disk I/O the transaction rollback case study. The same principle applies to approval: a cheap, atomic check at apply time beats an expensive reconstruction after the fact.

Approval is a decision about the future, and the best way to make it concrete is to let the agent run the proposed operation somewhere harmless first. Database branching gives each task its own copy-on-write fork of the schema and data, so migrations and destructive steps run against a disposable copy and the parent stays untouched. The mechanism is copy-on-write: a branch reads the parent's blocks as they were and stores only the blocks it changes the branching explainer. PostgreSQL's own CREATE DATABASE ... TEMPLATE does the same thing at the engine level, copying from a template database that nobody connects to the branching explainer.

The operational discipline is what makes it useful: create the branch when the work starts, point the task's connection string at it, and delete both together, so an agent that wipes a table only wipes its own branch the database branching concept note. For a proposal queue, this gives you a rehearsal step: apply the payload to the branch, capture the resulting diff and row counts, and put the observed effect in the proposal next to the predicted effect. If they disagree, the proposal is wrong and the reviewer should see that before approving.

Keep branch rehearsal optional for R1 and R2 and mandatory for R3 and R4. The cost is a branch creation, which is cheap when storage is shared, and the benefit is that expected_effect stops being a guess. The failure mode this prevents is documented: an agent runs a partial migration, fails halfway, and leaves a schema that no version of the application expects, and a code revert does nothing to recover the data layer the TINE writeup.

The queue is infrastructure, not a feature of one agent. Two consequences follow.

First, every writing agent talks to the same submit endpoint, so there is one place to enforce the schema and one place to audit. Second, the proposal format becomes a contract you can test. Write a property test that no apply can succeed without a matching decision, and a test that a changed payload hash invalidates an old approval. These are the two bugs that actually bite.

If your agents run across several model providers, submitting and reading proposals means many small structured calls: classify the effect, draft the summary, check the diff. Routing those through a single API keeps the key management and spend in one place, which is what Quanta Inference is for. And if you would rather not build the routing policy and evidence pack from scratch, Quanta Experts can take the oversight workflow as a deliverable. Start small: one table, one route, one decision log, and a test that proves the apply step fails without an approval. That single test is worth more than any policy document.