Cross-org Agent Negotiation Through a Firewall

Problem

Classic cross-org integration scenario (e-commerce ↔ partner ERP): meetings, email threads, manual OpenAPI spec maintenance, weeks to align on fields and contracts. Most multi-agent discussions in the industry today are about agents within a single organization or system. Cross-organizational negotiation by agents is a nearly unexplored paradigm.

Methodology

An experiment: put two AI agents (one per organization) into a dialogue where they produce the integration spec themselves, without humans in the discussion loop.

1. Setup. Each agent represents its side (e-commerce and ERP) and knows its system's constraints.
2. Dialogue. Agents discuss the contract, align on field types, operations, examples — chat-history.txt captures the negotiation.
3. Artifact. The dialogue produces openspec.yaml (OpenAPI). Git commits correspond to each agent's contributions and spec revisions — the "collaborative work" is visible, not a single monolithic output.
4. Boundary (firewall). The key architectural question: what exactly can cross the organizational boundary — not raw system data, but only the negotiated contract. The trust model is built at the spec level, not at the level of system access.

What the negotiation process looks like (real chat-history.txt): agents Bitrix_Lead_Bot and ERPSYS_Head_Bot negotiate a Bitrix (e-commerce) ↔ ERP integration:

• Agreed on POST /orders — Bitrix sends the order, ERP recalculates total and totalAmount on its side (data integrity ownership)
• Instead of ERP pushing product IDs to Bitrix — decided to give Bitrix a read-only /products endpoint to pull ERP SKUs itself
• SKU as the key for matching products between systems: uniqueness on the sender's side

What gets produced in openspec.yaml:

paths:
  /orders:
    post:
      summary: Create a new order
      description: >
        Receives a new order from Bitrix and creates it in the ERP.
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/Order'
      responses:
        '201':
          content:
            application/json:
              schema:
                properties:
                  id:
                    type: string
                    format: uuid      # ERP generates its own id
                  status:
                    type: string

The boundary held: what crossed the firewall was the contract (POST /orders), not ERP's internal data. Ownership of total recalculation is explicitly assigned to the ERP in the endpoint description.

Artifact

github.com/dobryakov/bots-discuss-spec — chat-history.txt (negotiation transcript), openspec.yaml (resulting spec), samples/ (prompts). Git history shows the step-by-step formation of the contract.

Series signature

Where it breaks

This is a synchronous integration experiment. Real enterprise scenarios like this are more commonly solved via a message broker — async, with delivery guarantees and explicit ownership per event. Why this isn't just "add Kafka" is covered in the two-phase commit breakdown; the theoretical foundation via Tanenbaum is in the book-as-context breakdown.
Non-standard field types and unresolved examples. The experiment was deliberately stopped midway — that's part of the honest narrative, not an oversight.
Missing operation IDs, ambiguous properties. Without traditional validation on top — proof-of-concept, not production.
Agent autonomy boundary. It must end where formal contract verification begins. Cross-org agent negotiation frames this as an architectural question, not a technical one.

For whom and why

The most intellectually forward-looking entry in the series: it raises questions about trust models and inter-agent protocols across org boundaries — where the industry is only starting to go. For a CTO or architect, this signals "thinking a step ahead," backed by a working artifact and an honest breakdown of where it fails.

Want to think through cross-org agent protocols for your integration architecture?

Trust models between agents, boundary design, and what can cross the org boundary — these are architectural decisions that need to be made before production.

Email me

Other breakdowns

An engineering breakdown series: real task → methodology → working artifact → honest breakdown of where it fails.