Architecture and B2B in daily operations

Give the agent a defined place in the system

The purchasing assistant needs to establish the right variant, customer price and delivery date. It also needs to establish who can consent to the purchase and who must approve it internally. That information comes from different parts of the business.

The shop holds prices and baskets, the ERP holds stock, and service knows the recurring questions. For the suitcase purchase, this information has to meet in one transaction. The architecture connects the responsible systems instead of rebuilding their logic inside the assistant.

Four sources behind a purchase

In the suitcase purchase, product data describes dimensions and material while the offer records price and delivery for the traveller. Her consent establishes what may be ordered; order and payment records then document what happened. These four sources serve different purposes while remaining connected.

The separation pays off when something goes wrong. Incorrect dimensions lead back to the product source, wrong shipping charges to the offer calculation, and duplicate orders to the ordering process. Knowing which source failed avoids searching the entire system.

Pick up the task where it left off

A customer task needs a retrievable state containing intent, conditions, selected offer, consent and the last action’s result. The conversation explains the context while the stored task preserves the records needed to continue.

The customer can ask about delivery the next day without explaining the purchase again. Service sees the order and relevant commitment. Personal preferences stay where they are needed and where the customer can manage them. The business establishes suitable access and retention rules.

Continue after an interruption

A connection drops while an order is being processed. The customer now needs an understandable answer. The system retrieves the transaction already started, checks whether the order exists and continues from there.

A multi-step task may also require a reservation to be released or a payment reversed. The merchant needs to recover the connection between the steps. Clear references and an agreed correction process make that possible.

One core, several entry points

Protocols should provide entry points to the same commerce-core functions so the customer agent, internal copilot and conventional frontend follow the same rules. New capabilities can then be checked in one place and reused across routes.

The suitcase merchant follows a task through to the stored order and retrieves it again. After a connection interruption, the same task must continue from that point. This shows whether the components work together beyond a single call.

Sales Agent Harness: a controlled connection

Multiple interfaces need a shared commerce path. Sales Agent Harness places a merchant-controlled layer between model and shop, describing search, basket and checkout handoff capabilities. [S106]

New routes using the same business rules

Custom development pays where expertise or the business model makes a difference; a maintained standard adapter may be more economical for recurring connections. In either case, the team needs to understand how products, prices and orders work together.

At the spare-parts merchant, planning starts with a typical purchase and the point where customers currently wait or correct a wrong selection. Improving that point gives the architecture a specific purpose and identifies which systems need to participate.

B2B: turning expertise into an offer

A spare-parts purchase makes the architecture tangible. A maintenance engineer is not buying any seal: the requirement is the approved variant for a particular machine revision, at the agreed price and before the next shift. The customer’s request connects the shop’s four data domains with procurement rules.

An agent can gather the information, prepare follow-up questions and request a quotation. The merchant must establish compatibility, the right account and the delivery promise. The architecture in the preceding section becomes a workflow procurement and sales can use every day.

Procurement is a relationship

A cheap individual order can be expensive over time. A supplier may provide emergency support, hold spare parts or offer flexible payment. An agent optimizing only the current price can destroy those benefits without recording them.

Procurement’s objective can include total operating cost, downtime risk, quality, supplier concentration and strategic relationships, without reducing every factor to a single score. Hard constraints and explicit trade-offs are often more honest than apparently exact points.

Werkpunkt (fictional): Buying a replacement part

At Werkpunkt, a maintenance engineer needs a replacement component. There is a part number, a machine revision and an urgent delivery deadline. The employer has customer-specific prices, a cost centre and a limit for orders that need no additional approval.

The agent brings these details together and asks for confirmed compatibility. The merchant calculates terms for the correct account. Where several suitable offers exist, purchasing can compare timing, quantity and price together. The goal is to bring the machine back into service on time.

Before ordering, the responsible person sees the proposed allocation and total. An unusual alternative goes to technical advice. Express delivery above the budget is presented for a decision. Familiar replenishment can later operate within a broader scope agreed in advance.

Testing starts with a read-only user before adding a purchase with a spending limit. The team also checks how orders, delivery and invoices reconnect after an interruption, giving procurement a workflow that visibly respects its own rules.

Werkpunkt evaluates the benefit through reduced handling time, suitable components and deadlines met. Downtime risk belongs in the assessment too. A slightly more expensive part can be the better choice when it arrives on time with confirmed fit.

From request to suitable offer

A B2B request should identify organisation, legal entity, cost centre, location, required outcome, quantity and timing. Customer-specific terms should be exposed only in the correct permission context. A public offer and a confidential contract price belong to different information spaces.

With spare parts, even a small difference can make a product unusable or affect safety. Agents therefore need verified mappings and must identify uncertain alternatives; any required technical authorisation or specialist review remains part of the process.

Negotiation requires boundaries

A merchant agent can offer delivery dates, quantities or discounts within permitted limits. It needs fixed boundaries and traceable offers. A polite email promise must not create a discount that the order system will reject.

The number of negotiation rounds needs an economic limit because an automated enquiry may be cheap for the buyer but still costs the seller time and resources. Otherwise two agents optimise a saving of €0.40 while operating an impressively expensive digital debating society.

Merchant Quote Agent: negotiating within a boundary

Negotiation becomes useful when strategy works within dependable boundaries. Merchant Quote Agent places the conversation next to the stored offer. The relationship-oriented negotiation strategy “Relationship builder” can change the tone; the discount corridor remains a system rule. [S100]

rfq-bench: making negotiation measurable

A charming answer and a good deal are different achievements. rfq-bench examines which strategy produces a better economic outcome under matched conditions. [S99]

Procurement as an inspectable plan

Across several suppliers, an optimizer can calculate the best permitted combination of known offers while language models gather information and explain terms. The calculation needs visible inputs and limits because its result depends on capturing all relevant conditions.

Before execution, procurement rechecks offers, quantities and dates and approves the complete allocation internally. Orders, invoices, deliveries and receipts remain linked to the same records so the plan can be followed through to actual fulfilment.

Starting point. Choose recurring procurement with clear specifications and a manageable supplier set. Begin with a prepared decision whose assumptions are visible. Expand execution authority only once that path works reliably and economically.

Procurement Swarm: from a request to two orders

In September 2026, my Procurement Swarm experiment connected three local Shopware supplier shops, agents, UCP and email negotiation. An optimizer calculated an admissible split. The reported run produced two test orders after human approval. [S23]

On this foundation, an agent can also work inside merchant operations. The next step is an operator taking on recurring tasks and, eventually, objectives.