9 posts tagged with "ai"

Functional Programming Isn't Just for Academics — Part 16

A language model can answer a question. An action model can do something about it. That distinction is going to matter more than most commerce platforms are ready for. Whether the term is "agent," "large action model," "task-specific AI," or something else that marketing teams have not finished sanding down yet, the direction is clear enough: software will not merely describe commercial options to buyers, operators, partners, and employees. It will increasingly select actions, call tools, negotiate constraints, and attempt to move workflows forward.

In commerce, "move the workflow forward" is not a harmless phrase. It might mean reserving inventory. It might mean accepting a substitution. It might mean committing an order, issuing a refund, changing a shipping promise, requesting a quote, applying a contract price, cancelling a shipment, or escalating a return. These are not generic software actions. They move money, create obligations, expose data, affect inventory, alter customer trust, and (should) leave evidence behind for someone else to explain later.

Functional Programming Isn't Just for Academics — Part 15

Operators preparing to support agentic commerce will eventually have to talk about protocols. That may mean MCP, UCP, a marketplace-specific interface, a procurement network, a partner API, or something that has not yet settled into a standard. If they start with a protocol, the first questions tend to be mechanical. Which tools do we expose? Which existing endpoints map to those tools? What schema does this protocol expect? How do we authenticate the caller? How do we serialize the response? Those are all necessary questions, but they are boundary questions. They deal with the outside edge of the system. The deeper question is whether there is a coherent business capability behind that edge.

Functional Programming Isn't Just for Academics — Part 12

A purchasing manager needs 200 units of a replacement part delivered to a job site by Friday. The budget is already approved. The supplier must meet a certification requirement. Substitutions are acceptable, but only if they preserve the tolerance class and do not change the installation procedure.

A person can work through that situation even when the systems involved are messy. They can search a supplier's site, read a product page, notice a message like "usually ships in one to two weeks," and decide whether that is worth a phone call. They can ask whether the warehouse really has enough stock. They can ask whether a substitute part is equivalent. They can judge whether the shipping estimate is conservative or risky. Human beings are very good at operating in the gaps between what a system says and what the business actually means.

Abstract​

The emergence of autonomous software agents as primary actors in commercial transactions creates a structural integration problem: agents need to interact with thousands of independent merchants, each exposing heterogeneous APIs with incompatible schemas, inconsistent semantics, and varying reliability guarantees. Existing integration patterns — direct REST consumption, EDI, or bespoke connector libraries — scale as O(A × M) where A is the number of agents and M is the number of merchants. We identify this as the agent-merchant integration problem and propose capability surfaces as a mediating architectural pattern that reduces integration complexity to O(A + M).

A capability surface is a semantic contract layer that sits between a merchant's internal microservices and external agents. It exposes deterministic, versioned, discoverable operations with explicit input/output schemas and error semantics, enabling any compliant agent to transact with any compliant merchant without bespoke integration. We formalize the pattern, specify its required properties, and ground the analysis in a concrete three-party scenario (manufacturer, procurement agent, logistics provider) interacting across an open market without pre-built integrations.

We examine the Model Context Protocol (MCP) as a production-validated mechanism for expressing capability surfaces, and the Universal Commerce Protocol (UCP) as an early domain-specific vocabulary layer. We discuss open problems in contract governance, registry trust, and agent identity that the architecture does not yet resolve.

Abstract​

Autonomous software agents are increasingly executing commercial transactions on behalf of human principals — discovering suppliers, evaluating offers, and placing orders without human involvement at each decision point. This paper examines the human factors dimension of this transition: what changes when humans delegate purchasing authority to agents, how the cooperative structure of commerce changes when one or more parties to a transaction is a software system, and what oversight, accountability, and trust mechanisms are required for agent-mediated commerce to function within organizational contexts.

We analyze a three-party transaction scenario (human principal, procurement agent, manufacturer) to identify the moments of delegation, the accountability gaps that delegation creates, and the design requirements for capability surfaces — the architectural interface layer through which agents interact with merchants — that support rather than undermine human oversight. We argue that the technical architecture of agentic-commerce systems encodes assumptions about human authority that deserve explicit examination, and that CSCW research has important contributions to make in designing systems where automation is a tool of human delegation rather than a replacement for human judgment.

Abstract​

Agent-mediated commerce — in which software agents autonomously discover suppliers, evaluate constraints, and execute transactions without human involvement at each step — is restructuring competitive dynamics in B2B markets. This paper analyzes the economic implications of this transition, identifying which traditional competitive advantages are durable in agent-evaluated markets and which erode, how the cost structure of supplier discovery changes, and what this means for the strategic positioning of manufacturers, distributors, and platform providers.

We argue that the transition to agent-mediated purchasing functions analogously to a market design change: it replaces attention-based competition (UX, SEO, merchandising) with operations-based competition (data completeness, interface reliability, fulfillment accuracy). This shift disproportionately favors organizations that have invested in operational excellence over those that have invested in human-attention capture. We further argue that capability surfaces — semantic contract layers enabling agent-to-merchant interaction without bespoke integrations — function as market infrastructure that reduces supplier discovery costs and changes the economics of direct manufacturer-to-buyer engagement.

Abstract​

The growth of autonomous software agents as commercial actors — buyers that discover suppliers, evaluate constraints, and execute transactions without human involvement — creates a practical interoperability problem: how should agents and merchants communicate when they have no prior relationship and no bespoke integration? This article presents a protocol stack perspective on the emerging answer: a layered architecture combining the Model Context Protocol (MCP) as a general capability mechanism, commerce-domain profiles as shared vocabularies, and capability registries as discovery infrastructure. We examine the stack's current state, its gaps, and the open engineering problems that the community must resolve to support agentic-commerce at production scale.

Something happened recently in B2B procurement that most sellers don't know about yet.

A construction company's software placed an order for 200 precision industrial components — ISO certified, shipped to Denver, all-in for $38,000 — without a human making a single purchasing decision after the initial instruction was given. The software found the supplier, evaluated three alternatives, confirmed availability and certification, arranged freight, and submitted the order. The construction firm's project manager received a structured confirmation email with the purchase order, tracking number, and certification documents.

The supplier that won the business? They didn't win it with a great website. They didn't win it with SEO or a smooth checkout flow or a compelling product description. They won it because their product data was complete, their availability signal was machine-readable, and their API didn't return ambiguous strings when the software asked a yes-or-no question.

The supplier that lost? They had equivalent products. They lost because their availability field returned "usually ships in 1–2 weeks" instead of a structured value. The software couldn't parse that into a procurement decision and moved on.

This is the shift. And it's not coming — it's here.

For three decades, commerce has centered on human buyers navigating browsers, apps, and IoT devices. Humans absorb ambiguity — tolerating unclear checkout processes, mysterious promotions, shifting shipping estimates, and surprise totals. If the brand is strong enough, they might still purchase despite friction.

Agentic commerce marks a fundamental shift: acknowledging that buyers aren't always human. Automated agents operate differently from people. They lack emotional attachment to brands and won't retry after failures. Instead, agents follow intent within constraints and systematically avoid unreliable paths.