Agent Consensus ≠ Execution: Designing the Negotiation-to-Action Request Pipeline

The previous article introduced Liquid Interface — a temporary multi-agent collaboration formed around a runtime intent that can discover participants, clarify local semantics, and compose candidate plans before dissolving. This article addresses the critical follow-up question: once agents agree, can the enterprise system execute directly? The answer is no. Consensus only proves shared understanding of a candidate plan; it does not guarantee current object state, business policies, authorization scopes, or action parameters remain valid.

Negotiation results must first be solidified into versioned, verifiable negotiation records, then transformed through policy and authorization into independent action requests, with the source business system owning transaction execution and result accountability.

Negotiation Records and Action Requests Are Two Distinct Objects

Dynamic negotiation outputs a candidate plan, which must not masquerade as a business action request. Below is a simplified negotiation record (JSON) capturing how shared understanding was formed — it does not represent execution permission.

{
  "negotiation_id": "NEG-20260826-0042",
  "revision": 3,
  "intent": {
    "type": "RestoreEquipmentAvailability",
    "target_object": "EQUIPMENT-A",
    "objective": "4 小时内完成安全检修并保护核心订单",
    "constraints": [
      {"metric": "core_orders_delay_minutes", "operator": "eq", "value": 0},
      {"metric": "normal_orders_delay_minutes", "operator": "lte", "value": 120}
    ]
  },
  "context_refs": {
    "semantic_baseline": "maintenance-model-2.3.0",
    "object_projection": "EQUIPMENT-A@18472",
    "policy_set": "production-policy-4.1"
  },
  "participants": ["scheduling-agent", "spare-part-agent", "workforce-agent", "safety-agent"],
  "agreed_semantics": [
    "兼容备件必须匹配设备型号和固件版本",
    "完成检修包含安全隔离解除和试运行通过"
  ],
  "candidate_plan": [
    {"step_id": "S1", "provider": "scheduling-agent", "capability": "RescheduleProduction", "proposal": "将普通订单调整到 2 号产线"},
    {"step_id": "S2", "provider": "spare-part-agent", "capability": "ReserveCompatiblePart", "proposal": "锁定与设备型号和固件版本兼容的备件"},
    {"step_id": "S3", "provider": "safety-agent", "capability": "RequestSafeMaintenanceWindow", "proposal": "申请停机检修和安全确认"}
  ],
  "plan_digest": "sha256:<computed from normalized candidate plan>",
  "unresolved_items": [],
  "status": "candidate_agreed",
  "expires_at": "2026-08-26T14:00:00+08:00"
}

After the decision/governance layer accepts the candidate plan, each real side-effect is converted into an independent action request. Only the linking fields are shown here:

{
  "action_request_id": "ACT-20260826-0188",
  "derived_from_negotiation": "NEG-20260826-0042",
  "derived_from_revision": 3,
  "derived_from_plan_step": "S1",
  "derived_from_plan_digest": "sha256:<computed from normalized candidate plan>",
  "action_type": "RescheduleProductionOrder",
  "action_contract_version": "reschedule-order-1.8.0",
  "target_object": "ORDER-N-1042",
  "parameters": {"target_line": "LINE-2", "planned_delay_minutes": 90},
  "expected_state_version": "ORDER-N-1042@318",
  "authorization_ref": "APPROVAL-7391",
  "idempotency_key": "ORDER-N-1042-LINE-2-20260826",
  "status": "ready_for_execution"
}

revision

and plan_digest lock the negotiation version the action request actually uses; derived_from_plan_step identifies which step of the composite plan this action originates from. Any mismatch triggers re-validation — the original authorization cannot be reused.

The two JSON objects are not part of the same API payload. The negotiation record is produced first; only after policy, authorization, and human confirmation does the system generate one or more action requests. This transformation must fail closed :

Missing published action type → cannot execute.

Required parameters undetermined → model must not guess.

Object state or policy version changed → re-validate or re-negotiate.

Candidate plan changed materially → prior human confirmation cannot be auto-reused.

Only part of a composite plan passes validation → partial acceptance must not be mistaken for whole-plan authorization.

Temporary Interfaces Can Dissolve, Business Evidence Must Persist

The paper emphasizes that negotiation structures dissolve after task completion, achieving "zero residual coupling." While a valid design goal, this does not equate to "no technical debt" in enterprise systems. The temporary collaboration structure may expire, but the following must be retained long-term:

Who expressed what intent, using which semantic and data versions.

Which agents declared which capabilities, and which declarations were verified.

What candidate proposals, disagreements, rejections, and constraint relaxations occurred.

Which policy and authorization decisions allowed or blocked subsequent actions.

Which action requests the negotiation result was transformed into.

What the source system actually executed, and how failures were recovered or manually overridden.

Temporary collaborative relationships lose binding force after expiry, but evidence forming decisions and business consequences must remain traceable long-term.

The system must still maintain identity, capability catalogs, semantic baselines, policies, logs, adapters, and evaluation sets. Dissolving a task-level interface reduces stale negotiation misuse but does not zero out infrastructure and governance costs.

Deterministic Fallbacks When Negotiation Fails

The paper does not treat dynamic negotiation as unlimited dialogue. It explicitly states that when semantic uncertainty cannot converge within bounded rounds and time, the system should simplify intent or fall back to a pre-agreed minimal core semantics and deterministic path. Enterprise implementations must define stop conditions for at least:

Exceeding max negotiation rounds, time limits, token or call budgets.

Multiple candidate capabilities unable to resolve key semantic conflicts.

Capability declarations unverifiable, or participant identity/authorization insufficient.

Current object state, environment conditions, or business policies changed.

Composite plan only partially viable, failing overall safety thresholds.

Partial failures after real execution has begun.

Corresponding fallback paths include:

Clarify — ask the initiator for missing goals or constraints.

Simplify — narrow intent to read-only analysis or candidate suggestions only.

Solidify — revert to pre-approved core objects, capabilities, and workflows.

Human takeover — hand context, candidates, and unresolved disagreements to a responsible person.

Terminate and dissolve — execute no side-effects, retain failure evidence.

Crucially, negotiation-phase failures can trigger re-negotiation; but once real actions have produced partial side-effects, the system must enter the action contract's defined reconciliation, compensation, or manual handling — a dissolve message cannot erase business consequences.

Where to Use (and Where to Ban) Liquid Interface

Liquid Interface is not a universal replacement for traditional integration; the paper itself acknowledges its applicability boundaries:

Stable internal tools with fixed interfaces/processes → use fixed APIs, MCP, workflows, or single-agent orchestration. Dynamic negotiation only adds latency and uncertainty.

Heterogeneous agents in open ecosystems needing ad-hoc discovery and composition → Liquid Interface can be trialed. Design-time enumeration of participants and local semantics is impossible.

Highly variable plan combinations but high-risk final actions → liquid negotiation + solid execution. Upper layer keeps adaptability; lower layer keeps authorization and transaction determinism.

Read-only research, information matching, candidate generation → suitable for early pilots. Low side-effects, errors easily isolated and reviewed.

PLC control, safety interlocks, real-time trading (hard real-time paths) → ban natural-language dynamic negotiation as a substitute for deterministic protocols. Requires bounded latency, static verification, explicit failure semantics.

Regulatory mandates for pre-certified execution paths or immutable contracts → only allow advisory role outside certified paths. Ad-hoc protocols struggle to meet compliance proof requirements.

Even in applicable scenarios, first prove multi-agent genuinely outperforms a single-runtime module, skill, or fixed workflow. More participants and complex-looking dialogue ≠ business value from dynamic negotiation.

How to Validate a Dynamic Negotiation Mechanism

"Multiple agents eventually agreed" is not a valid acceptance criterion. They may agree on a wrong understanding, or produce an unexecutable or unauthorized plan. At minimum, verify across six dimensions:

Capability discovery — truly usable capabilities enter candidates; irrelevant or fake ones are excluded.

Semantic alignment — objects, units, time, result nature, and constraint priorities correctly understood.

Plan validity — composition order, dependencies, preconditions, and global constraints hold.

Safety interception — overreach, missing approvals, stale state, and missing action contracts fail closed consistently.

Convergence and degradation — negotiation ends within round, time, and cost budgets; failures enter expected fallbacks.

Evidence traceability — from action receipt back to action request, authorization, candidate plan, negotiation record, and original context.

Test samples must cover capability exaggeration, malicious declarations, context conflicts, participant dropout, policy changes, unsolvable tasks, and partial execution failures — not just happy paths. If dynamic negotiation shows no clear improvement over fixed workflows in unknown-capability discovery rate, complex-plan completion rate, or human coordination efficiency, while significantly increasing latency, cost, and incident diagnosis difficulty, it should not enter the production main path.

Start with a Read-Only Negotiation Scenario

Enterprises need not implement full LIP upfront, nor let multiple agents dynamically orchestrate high-risk writes. A safer first phase:

Pick a collaboration scenario where participants cannot be pre-enumerated but only produces recommendations.

Define a minimal stable message envelope containing at least intent, context references, capability declarations, constraints, state, and TTL.

Establish verifiable agent identities, capability catalogs, and declaration provenance — do not treat self-declared capabilities as facts.

Record every clarification round, candidate proposal, semantic disagreement, and exit reason.

Restrict final output to candidate plans or human tasks — no direct business side-effects.

Set max rounds, time limits, cost, risk thresholds, and deterministic degradation paths.

Baseline against fixed workflow or single-agent solutions comparing quality, latency, cost, and human effort.

Only after this read-only loop stabilizes should low-risk plans be converted to controlled action requests. Each expansion of action scope must be accompanied by additional state validation, authorization, regression tests, and failure-recovery evidence.

Keep intent, capability discovery, and candidate plans "liquid"; keep business semantic baselines, policies, action contracts, permissions, and transactions "solid" — only then can dynamic negotiation evolve from concept into a verifiable enterprise capability.

This is the final judgment of the "Dynamic Ontology" series: dynamism is not abandoning models and contracts, but identifying different rates of change and confining them to the correct lifecycles, owners, and runtime boundaries.