Showing posts with label Agent. Show all posts
Showing posts with label Agent. Show all posts

SemiAnalysis: Compare Realistic Agentic Inference Perf

Mike's Notes

Useful source for inference benchmarking. For future reference.

The first part of the article is copied below. You can read the rest by following the link in the resources below.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > SemiAnalysis
  • Home > Handbook > 

Last Updated

27/08/2026

Compare Realistic Agentic Inference Perf

By: Cam Quilici, Bryan Shan, Alec Ibarra, Daniel Nishball, Zane Fong, Kimbo Chen, Dylan Patel
SemiAnalysis: 23/08/2026

.

Since the Claude Code inflection point in November 2025, long-context, multi-turn agentic workloads have grown rapidly. They now dominate traffic for production inferencing. In April 2026, OpenAI’s Enterprise agentic spending overtook ChatGPT spending.

Agentic workflows have decisively taken the baton. Today, we announce AgentX 1.0 - the world’s first fully open source, multi-turn agentic coding inference benchmark at 1 million context, released under Apache 2.0. Our full dashboard is available here.

Source: SemiAnalysis

In the past most measured performance based on fixed sequence length prefill and decode workloads, but this is an inaccurate way to measure workloads. Reality is multi-turn, long context, high prefill reuse, with sub agent bursts, KVCache offload, and numerous tool calls. As such we aimed to build the correct way for the industry to measure AI hardware and software performance.

We have spent more than $3M building this dataset. Today, we open source everything. InferenceXv3 implements AgentX, a new realistic scenario in addition to the existing “fixed sequence length” scenarios (8k1k, 1k1k, 1k8k). It improves the benchmark scenarios by using agentic coding traffic instead of the previous single-turn traffic of 8k input and 1k output tokens.

The full matrix runs on ~2MW of continuously operated compute across over 1000 chips spanning a wide range of SKUs, featuring the MI355X, GB300 NVL72, GB200 NVL72, B300, B200, MI325, MI300X, H200, and RTX Pro Servers. Rubin arrives later this month, and TPUs and Mi455X UALoE72 arrive later this year. Please drop a star if you found our free open source work valuable.

It is great to see amazing performance from both NVIDIA and AMD on agentic workloads. NVIDIA does very good on a lot of frontier models while AMD also does well on some frontier models for specific comparsions.

Source: SemiAnalysis GitHub

The most valuable thing AgentX produced in its first months was not the initial results. It was the massive industry impact the benchmark is already having. Over 70+ upstream PRs for optimizing real world production agentic workloads across vLLM, SGLang, TensorRT-LLM, ATOM, AITER, Dynamo, LMCache, and Mooncake, uses AgentX as the north star benchmark proxy. Most of these optimization improvements are transferable to production traffic. We deep dive into each of these optimizations later in the article.

Source: SemiAnalysis

Open source is a core principle for InferenceX and thus, we open more of the stack than most people who use that word. That includes an open frontend, a public database served through an easily consumable REST API that multiple tier 1 AI lab’s capacity planning teams already consume, public GitHub Actions CI provenance, logs, and accuracy validation on every single point. Crucially, our benchmark configs mainly track recipes.vllm.ai and SGLang cookbook on upstream images such that we are measuring the performance actual customers are experiencing instead of measuring benchmax’ed images.

In three to four weeks, we will release an AgentX update article. It will cover further optimizations to agentic workloads, plus updated performance results from AMD and Nvidia. It is important to understand that the profile of agentic workloads is updating fast. InferenceX will continue to move swiftly to benchmark the relevant workloads.

InferenceX is 100% committed to being open-source - this would not be possible without the contributions and support from our OSS partners. We would like to thank the following people that have made massive contributions to the AgentX 1.0 release:

  • Inferact/vLLM: Roger Wang, Yifan Qiao, Simon Mo, Jeff Ma, and many others
  • RedHat/llm-d: Michael Goin, Robert Shaw, Tyler Michael Smith
  • RadixArk/SGLang: Baizhou Zhang, Yuwei An, Mingyi Lu, and many others
  • LMCache/TensorMesh: Samuel Shen
  • Weka: Callan Fox, ValB
  • MoonCake Maintainers: Teng Ma, Xu Wenjie, Ke Yang
  • AMD: Thomas Wang, HaiShaw, Andy Luo, Seungrok Jung, Chun Fang, Parth Panchal, Bill He, Theresa Shan, Hongxia, Fangzhou, Gilbert Lei, Yanfei Wang, Duyi Wang, Peng Sun, Lingpeng Jin, Simon Danielsson, Xiaohu Guo, Haichen Zhang, Chang Liu, Doug Lehr, Poovaiah Palangappa, and many others in the AMD Shanghai Development Centre
  • Nvidia: Xin Li, Anthony Casagrande, Kedar Potdar, Ankur Singh, Ishani Dhanani, Nick Comly, Nvidia Shanghai TensorRT-LLM team, and many others
  • Anthropic staff, for promptly fixing multiple bugs that made implementing AgentX possible
  • GitHub: Austen Stone for helping with reliability of GitHub Actions that AgentX uses
  • And many others
In addition, we are thankful to all who support our open source InferenceX initiative, including Meta, Microsoft, Oracle, OpenAI, MiniMax, Moonshot Kimi, Alibaba Qwen, and Zhipu GLM.

Source: InferenceX

... See the original article for the rest.

Creating 18 Engine descriptions

Mike's Notes

18 working engines are currently being imported into Pipi Core, configured, and tested.

Alex has sent me a DeepSeek chat that generated descriptions of those engines and how they worked together by analysing the existing web page "20 Engines". DeepSeek also produced a Mermaid Diagram from Markdown code based on those descriptions. DeepSeek was partially correct in some descriptions.

The Mermaid diagram was wrong, but what a great tool for Pipi to self-document with CL and accurate Markdown descriptions. It will be widely used in future as a plugin.

Feedback and suggestions are very welcome as always.

Update 23/05/2026

Java and CGI Engines added for interoperability by Pipi.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

23/05/2026

Creating 18 20 Engine descriptions

By: Mike Peters
On a Sandy Beach: 06/05/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Most Pipi engines have historically been poorly described. This is an attempt to write better descriptions for the 18 20 engines currently being imported.  I had a go, then used Gemini to come up with better wording, then Mrs Grammarly did her bit. 😎

Much later, once the workspace UI are working, a one-page summary about each engine can be written for the pipiWiki. The Wiki Engine (wik) in the resources above has an example of such a summary.

Note: These are listed in the order they are being imported.

Descriptions

Each engine has;

  • Unique Name (Unique 3-letter code)
  • S: Short description suitable for tooltips under 100 characters.
  • D: Description under 255 characters.

System Engine (sys)

  • S: System identity and lifecycle controller.
  • D: Manages the vital signs and lifecycle of Pipi’s dynamic engine ecosystem, fostering complex emergent behaviours through seamless interaction.

Nest Engine (nst)

  • S: Host and environment interface bridge.
  • D: Serves as the foundational gateway between the host OS, JVM, the application server, CGI, and the internal Pipi environment.

JVM Engine (jvm)

  • S: JVM interoperability.
  • D: Provides Pipi with a way to work directly with an external JVM.

CGI Engine (cgi)

  • S: CGI interoperability.
  • D: Provides Pipi with a way to work directly with external CGI.

Namespace Engine (nsp)

  • S: Global identification and addressing.
  • D: Enforces a conflict-free global naming convention, ensuring every system element is uniquely addressable across the entire platform.

Render Engine (rnd)

  • S: Static file and asset rendering.
  • D: Processes and renders static resources, including HTML, CSS, source code, and databases.

Template Engine (tem)

  • S: Reusable pattern templates.
  • D: Manages reusable structural pattern templates used by the CMS to generate database-driven pages and components.

Variables Engine (var)

  • S: Centralised variables library.
  • D: Provides a centralised repository for managing variables used across templates, system configurations, and executable logic.

Log Engine (log)

  • S: Universal logging and telemetry controller.
  • D: Aggregates and configures logging parameters across all active engines to provide system-wide transparency and diagnostics.

Data Engine (dta)

  • S: Database lifecycle and CRUD operations.
  • D: Generates SQL to command the creation, evolution, and deletion of databases and their underlying data objects with full administrative control.

Configuration Engine (cnf)

  • S: Engine blueprint and manufacturing settings.
  • D: Supplies the precise DNA and configuration parameters required for the automated fabrication of individual Pipi engines.

Versioning Engine (ver)

  • S: Semantic versioning and update tracker.
  • D: Maintains system integrity by aggregating incremental updates from all engines into a unified semantic versioning timeline.

Code Engine (cde)

  • S: Internal code generation.
  • D: Facilitates automated code generation, including class libraries and logic synthesis directly within the Pipi platform.

Conductor Engine (cnd)

  • S: Internal process regulator.
  • D: Operates as the high-level orchestrator for major internal system processes and synchronisation.

Directory Engine (dir)

  • S: CMS file system and path manager.
  • D: Manages the logical and physical file system directories generated and utilised by the CMS.

Node Engine (nde)

  • S: Hierarchical template tree architect.
  • D: Maintains the addressable tree structure of templates to define content hierarchy within the CMS.

CMS Engine (cms)

  • S: Digital content management.
  • D: Powers the end-to-end lifecycle of digital content, from initial creation and editing to final publishing.

Core Engine (cor)

  • S: Primary system driver and logic hub.
  • D: The central engine that powers fundamental system behaviours and executes the primary logic that keeps Pipi running.

Factory Engine (fac)

  • S: Automated engine fabrication.
  • D: Assembles and deploys engines based on stored configuration files and real-time updates.

Page Engine (pge)

  • S: Semantic relationship and metadata mapper.
  • D: Maps external relationships for pages, managing keywords, references, and "See Also" semantic connections.

Open Payment Standard x402 Expands Capabilities in Major Upgrade

Mike's Notes

A need-to-know for handling payments in the future.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > InfoQ
  • Home > Handbook > 

Last Updated

22/03/2026

Open Payment Standard x402 Expands Capabilities in Major Upgrade

By: Sergio De Simone
InfoQ: 22/01/2026

Sergio De Simone is a software engineer. Sergio has been working as a software engineer for over twenty five years across a range of different projects and companies, including such different work environments as Siemens, HP, and small startups. For the last 10+ years, his focus has been on development for mobile platforms and related technologies. He is currently working for BigML, Inc., where he leads iOS and macOS development.

After six months of real-world usage, the open payment standard x402 has received a major update, extending the protocol beyond single-request, exact-amount payments. The release adds support for wallet-based identity, automatic API discovery, dynamic payment recipients, expanded multi-chain and fiat support via CAIP standards, and a fully modular SDK for custom networks and payment schemes.

"V2 is a major upgrade that makes the protocol more universal, more flexible, and easier to extend across networks, transports, identity models, and payment types. The spec is cleaner, more modular, and aligned with modern standards including CAIP and IETF header conventions, enabling a single interface for onchain and offchain payments."

x402 V2 offers a unified payment interface supporting stablecoins and tokens across multiple chains, including Base, Solana, and others, while maintaining compatibility with legacy payment rails such as ACH, SEPA, and card networks. It also introduces per-request routing to specific addresses, roles, or callback-based payout logic, enabling complex multi-step payment workflows.

Another enhancement in x402 V2 is the clear separation between the protocol specification, its SDK implementation, and facilitators (responsible for verifying and settling the payment on-chain), which improves extensibility and enables a modular, plug-in–based architecture.

The new standard also introduces wallet-based access, reusable sessions, and modular paywalls. Wallet support provides clients with greater flexibility, streamlining payment flows and reducing round-trip and latency for previously purchased items. Modular paywalls enable developers to integrate and extend new backend payment logic, fostering a more extensible ecosystem.

Finally, x402 V2 improves the developer experience by simplifying configuration through its modular design, adding support for choosing multiple facilitators simultaneously, and minimizing the amount of glue code or boilerplate required.

x402 is an open, web-native payment standard/protocol designed to make payments a first-class citizen of the internet. It enables micro-payments, pay-per-use, and machine-to-machine payments, allowing web apps, APIs, and autonomous agents (like AI bots) to pay for services directly over HTTP without traditional accounts, subscriptions, or complex payment flows. Within months, the protocol has processed over 100 million payment flows across APIs, web applications, and autonomous agents.

The protocol leverages the rarely used HTTP status code 402 (Payment Required) to signal when payment is required and to include payment instructions in the response. By using x402, payments can be executed directly within the HTTP request–response flow, eliminating the need to redirect users to external payment pages or to rely on API keys and personal accounts.

Cloudflare, as one of the original partners in the x402 Foundation alongside Coinbase, integrated support for the protocol into its developer tools and infrastructure. This includes both the Agents SDK, which allows developers to build agents capable of automatically making payments using x402, and MCP servers that expose x402-enabled tools and enable services to return 402 Payment Required responses and accept x402 payments from clients.

Agent Card

Mike's Notes

Earlier this week, I attended the APAC Cloud Technical Series: On Board from Google. It was 10 hours over 2 days of talks and code workshops from Google staff, who were mainly based in Singapore.

It was excellent and worth the time. I signed up for more sessions planned later in the year. Google Weeklies is a regular in-depth talk available both live and as an archive. Excellent stuff.

I got an invite to join Google for Startups' Rising Founders program. I hope that this will lead to access to researchers at Google DeepMind. I have questions.

I initially registered to participate in the Gen AI Academy APAC Edition, which would have been fun, but then I discovered an age restriction. I'm too ancient. 😊

IaC

This will help me build Pipi Engines to build, deploy, and manage infrastructure-as-code (IaC) in the cloud.

A dedicated agent engine has been created for each cloud platform. They have yet to be differentiated.

  • Apple Engine (ale)
  • AWS Engine (aws)
  • AZURE Engine (azu)
  • Digital Ocean Engine (dgo)
  • Google Cloud Engine (ggc)
  • IBM Engine (ibm)
  • Meta Engine (met)
  • Oracle Engine (ora)
  • (More will be added later; all are welcome)

Agents

Pipi 9 is a type of world-model AI, not an LLM. Google is offering a platform for LLM-based generative AI agents. My thought is to connect Pipi 9 to these external agents via open protocols, leveraging the strengths of both.

  • MCP
    • PostgreSQL
    • TPU
    • etc
  • A2A
    • Agent Card
  • ADK

More Pipi engines

  • MCP Engine (mcp)

Agent card

Here are some initial notes about the Agent Card protocol, part of A2A. I will start building from there.

Pipi is an agent built from hundreds of other kinds of deeply nested agents, and is capable of learning, evolving and replicating. So does this mean that Pipi needs its own Agent Card? 😀

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

13/02/2026

Agent Card

By: Mike Peters
On a Sandy Beach: 1/02/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

From A2A Protocol Documentation

A2A revolves around several key concepts. For detailed explanations, please refer to the Key Concepts guide.

    • A2A Client: An application or agent that initiates requests to an A2A Server on behalf of a user or another system.
    • A2A Server (Remote Agent): An agent or agentic system that exposes an A2A-compliant endpoint, processing tasks and providing responses.
    • Agent Card: A JSON metadata document published by an A2A Server, describing its identity, capabilities, skills, service endpoint, and authentication requirements.
    • Message: A communication turn between a client and a remote agent, having a role ("user" or "agent") and containing one or more Parts.
    • Task: The fundamental unit of work managed by A2A, identified by a unique ID. Tasks are stateful and progress through a defined lifecycle.
    • Part: The smallest unit of content within a Message or Artifact. Parts can contain text, file references, or structured data.
    • Artifact: An output (e.g., a document, image, structured data) generated by the agent as a result of a task, composed of Parts.
    • Streaming: Real-time, incremental updates for tasks (status changes, artifact chunks) delivered via protocol-specific streaming mechanisms.
    • Push Notifications: Asynchronous task updates delivered via server-initiated HTTP POST requests to a client-provided webhook URL, for long-running or disconnected scenarios.
    • Context: An optional, server-generated identifier to logically group related tasks and messages.
    • Extension: A mechanism for agents to provide additional functionality or data beyond the core A2A specification.

- A2A Protocol Documentation

Agent Discovery in A2A

To collaborate using the Agent2Agent (A2A) protocol, AI agents need to first find each other and understand their capabilities. A2A standardizes agent self-descriptions through the Agent Card. However, discovery methods for these Agent Cards vary by environment and requirements. The Agent Card defines what an agent offers. Various strategies exist for a client agent to discover these cards. The choice of strategy depends on the deployment environment and security requirements.

The Role of the Agent Card

The Agent Card is a JSON document that serves as a digital "business card" for an A2A Server (the remote agent). It is crucial for agent discovery and interaction. The key information included in an Agent Card is as follows:

  • Identity: Includes name, description, and provider information.
  • Service Endpoint: Specifies the url for the A2A service.
  • A2A Capabilities: Lists supported features such as streaming or pushNotifications.
  • Authentication: Details the required schemes (e.g., "Bearer", "OAuth2").
  • Skills: Describes the agent's tasks using AgentSkill objects, including id, name, description, inputModes, outputModes, and examples.

Client agents use the Agent Card to determine an agent's suitability, structure requests, and ensure secure communication.

Sample Agent Card

{
  "protocolVersions": ["1.0"],
  "name": "GeoSpatial Route Planner Agent",
  "description": "Provides advanced route planning, traffic analysis, and custom map generation services. This agent can calculate optimal routes, estimate travel times considering real-time traffic, and create personalized maps with points of interest.",
  "supportedInterfaces": [
    {"url": "https://georoute-agent.example.com/a2a/v1", "protocolBinding": "JSONRPC"},
    {"url": "https://georoute-agent.example.com/a2a/grpc", "protocolBinding": "GRPC"},
    {"url": "https://georoute-agent.example.com/a2a/json", "protocolBinding": "HTTP+JSON"}
  ],
  "provider": {
    "organization": "Example Geo Services Inc.",
    "url": "https://www.examplegeoservices.com"
  },
  "iconUrl": "https://georoute-agent.example.com/icon.png",
  "version": "1.2.0",
  "documentationUrl": "https://docs.examplegeoservices.com/georoute-agent/api",
  "capabilities": {
    "streaming": true,
    "pushNotifications": true,
    "stateTransitionHistory": false,
    "extendedAgentCard": true
  },
  "securitySchemes": {
    "google": {
      "openIdConnectSecurityScheme": {
        "openIdConnectUrl": "https://accounts.google.com/.well-known/openid-configuration"
      }
    }
  },
  "security": [{ "google": ["openid", "profile", "email"] }],
  "defaultInputModes": ["application/json", "text/plain"],
  "defaultOutputModes": ["application/json", "image/png"],
  "skills": [
    {
      "id": "route-optimizer-traffic",
      "name": "Traffic-Aware Route Optimizer",
      "description": "Calculates the optimal driving route between two or more locations, taking into account real-time traffic conditions, road closures, and user preferences (e.g., avoid tolls, prefer highways).",
      "tags": ["maps", "routing", "navigation", "directions", "traffic"],
      "examples": [
        "Plan a route from '1600 Amphitheatre Parkway, Mountain View, CA' to 'San Francisco International Airport' avoiding tolls.",
        "{\"origin\": {\"lat\": 37.422, \"lng\": -122.084}, \"destination\": {\"lat\": 37.7749, \"lng\": -122.4194}, \"preferences\": [\"avoid_ferries\"]}"
      ],
      "inputModes": ["application/json", "text/plain"],
      "outputModes": [
        "application/json",
        "application/vnd.geo+json",
        "text/html"
      ]
    },
    {
      "id": "custom-map-generator",
      "name": "Personalized Map Generator",
      "description": "Creates custom map images or interactive map views based on user-defined points of interest, routes, and style preferences. Can overlay data layers.",
      "tags": ["maps", "customization", "visualization", "cartography"],
      "examples": [
        "Generate a map of my upcoming road trip with all planned stops highlighted.",
        "Show me a map visualizing all coffee shops within a 1-mile radius of my current location."
      ],
      "inputModes": ["application/json"],
      "outputModes": [
        "image/png",
        "image/jpeg",
        "application/json",
        "text/html"
      ]
    }
  ],
  "signatures": [
    {
      "protected": "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpPU0UiLCJraWQiOiJrZXktMSIsImprdSI6Imh0dHBzOi8vZXhhbXBsZS5jb20vYWdlbnQvandrcy5qc29uIn0",
      "signature": "QFdkNLNszlGj3z3u0YQGt_T9LixY3qtdQpZmsTdDHDe3fXV9y9-B3m2-XgCpzuhiLt8E0tV6HXoZKHv4GtHgKQ"
    }
  ]
}

The AI advertising wars

Mike's Notes

This is an extract from a recent thoughtful SubStack post by Gennaro Cuofano, in The Business Engineer. The post discusses the AI advertising wars. This extract is about recent changes at the newly formed Agentic AI Foundation, a Linux Foundation initiative.

"What we’re witnessing is the emergence of a complete protocol stack for agentic commerce. Understanding how these pieces fit together reveals both the competitive dynamics and the cascading implications for the digital ecosystem." - Gennaro Cuafano

Note to self

  • Create a Pipi MCP Engine.
  • Look into the open-source protocols at the Agentic AI Foundation.
The post also discusses the war around payment protocols.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > The Business Engineer
  • Home > Handbook > 

Last Updated

28/01/2026

The AI advertising wars

By: Gennaro Cuofano
The Business Engineer: 27/01/2026

Creator of The Business Engineer, the deep-tech research hub, spun off from FourWeekMBA, the leading blog on business model strategy. Gennaro has over 10 years of experience as a deep tech executive.

...

The Protocol Stack: Five Layers of the New Commerce Architecture

What we’re witnessing is the emergence of a complete protocol stack for agentic commerce. Understanding how these pieces fit together reveals both the competitive dynamics and the cascading implications for the digital ecosystem.

Layer 1: Foundation Infrastructure

The foundation layer has effectively been won by the Model Context Protocol. MCP, launched by Anthropic in November 2024, has achieved what few technology standards accomplish in a single year: industry-wide adoption backed by competing giants. The numbers tell the story:

  • 97 million monthly SDK downloads
  • 10,000+ active servers
  • ~2,000 entries in the MCP Registry (407% growth since September)
  • First-class client support across ChatGPT, Gemini, Microsoft Copilot, Cursor, and VS Code

In December 2025, Anthropic donated MCP to the newly formed Agentic AI Foundation under the Linux Foundation. This wasn’t an act of charity but strategic positioning—by making MCP vendor-neutral, Anthropic ensured its protocol would become critical infrastructure rather than a competitive weapon that might be forked or abandoned. As Mike Krieger, Anthropic’s Chief Product Officer, put it:

"A year later, it’s become the industry standard for connecting AI systems to data and tools.”

MCP now sits alongside two other founding projects under the AAIF:

  • AGENTS.md (OpenAI): Adopted by 60,000+ open-source projects for providing AI coding agents with project-specific instructions
  • goose (Block): An open-source, local-first agent framework
  • Agent2Agent / A2A (Google): Enables communication between autonomous agents, supported by 150+ organizations

The significance of this consolidation under the Linux Foundation cannot be overstated. These protocols are becoming the TCP/IP of the agentic economy—essential infrastructure that no single company controls but upon which all higher-value services depend.

Layer 2: Payment Infrastructure

The payment layer remains more fragmented. Google’s Agent Payments Protocol (AP2), co-developed with PayPal and backed by over 60 merchants and financial institutions, provides secure payment tokenization for agent-initiated transactions. It’s designed to work seamlessly with Google Pay and the broader Google commerce ecosystem.

The payment processor alignment is telling:

  • Stripe → OpenAI’s commerce stack (Shared Payment Token, Agentic Commerce Suite)
  • PayPal → Google’s AP2 + Perplexity’s commerce features

This isn’t neutral infrastructure—the payment processors are choosing sides in the protocol wars, betting on which business model will dominate.

Layer 3: Commerce Infrastructure—The Battlefield

This is where the war is actually being fought. Two competing protocols with fundamentally different architectures and business models are vying to become the standard for agentic commerce.

Google’s Universal Commerce Protocol (UCP), announced at the National Retail Federation conference on January 11, 2026, was co-developed with Shopify, Etsy, Wayfair, Target, and Walmart, with endorsement from over 20 partners including Visa, Mastercard, American Express, Stripe, Best Buy, and Zalando.

UCP is a full-journey protocol covering:

  • Product discovery
  • Cart management
  • Checkout
  • Post-purchase support
  • Loyalty programs and returns (roadmap)

The architectural philosophy is revealing: UCP establishes a common language through which agents can discover merchant capabilities, negotiate supported features, and execute transactions. Merchants publish their capabilities via a .well-known/ucp file, agents discover what’s available, and transactions proceed through standardized primitives.

OpenAI’s Agentic Commerce Protocol (ACP), launched in September 2025 in partnership with Stripe, takes a narrower approach. ACP is checkout-focused—it solves the “last mile” of completing a purchase rather than the entire shopping journey. The protocol is Apache 2.0 licensed and explicitly designed to work across payment processors and AI platforms.

ACP’s architecture reflects OpenAI’s strategic position: they don’t need to own discovery (ChatGPT’s conversational interface handles that) or post-purchase (merchants handle fulfillment). They need to capture value at the moment of conversion. For merchants already on Stripe, enabling agentic payments requires as little as one line of code.

The scope difference is intentional. UCP gives Google a reason to keep merchants within its ecosystem across the entire customer journey. ACP lets OpenAI capture transaction value wherever discovery happens.

...

Recent work on system messaging

Mike's Notes

The work this week. 

I found a problem with the existing Pipi 6 era Messaging Engine (msg). It needed to be replaced to support the richer Pipi 9 internal environment of autonomous agents that can self-organise and move.

I spent days staring into space, and then the solution became very clear while daydreaming 😴 between morning coffee and ice cream summer afternoons 😎. Slow but getting there.

Resources

References

  • Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (Addison-Wesley Signature Series), by Gregor Hohpe and Bobby Woolf.
  • Integration Patterns (Patterns & Practices). Microsoft.

Repository

  • Home > Ajabbi Research > Library > Authors > Gregor Hophe
  • Home > Handbook > 

Last Updated

25/01/2026

Recent work on system messaging

By: Mike Peters
On a Sandy Beach: 22/01/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Pipi 4 (2005-2008)

A simple internal messaging system was invented and built for Pipi 4 around 2005. It had a messaging store and handled interactions between different internal systems. It was not called a messaging system; it was an unnamed part of the Metadata Repository. It was built in CFML code and ran on MS SQL Server.

Pipi 6 (2017-2019)

After reading about Apache Kafka and RabbitMQ, I realised that Pipi 4 had contained a primitive internal messaging system, 5 years before Kafka. A new, quick-and-dirty broker-based messaging system, similar to RabbitMQ, was built as a CFML module to send messages across hundreds of modules when Pipi 4 was rebuilt from memory as Pipi 6. The work of Gregor Hohpe and Bobby Woolf was an inspiration. Martin Fowler was an enormous influence on everything.


Pipi 9 (2023-

It has taken all week to figure out a solution. I ended up splitting the role of the engine

  • The existing Pipi 6 messaging module is now being fully refactored into the Pipi 9 Messaging Engine (msg). Previously, it used a wrapper to make it appear to be an agent. Some minor changes are being made to the Namespace Engine (nsp).
  • The new Messaging Engine (msg) is used to create the local messaging systems via the Factory Engine (fac). The Factory Engine (fac) will place a local message store using a separate embedded database inside each agent to connect to its Messaging Endpoint. Each system (made up of many agents) has its own messaging store attached to the system router.

As agents dynamically self-assemble in response to events, the messaging system always works.

The new Engine closely follows the patterns in Enterprise Integration Patterns and even uses the same icons, aka "Gregorgrams".

Summary of changes underway

  • Internal system messaging between hundreds of autonomous agents.
  • Possible because of the Namespace Engine (nsp) built into Pipi 8.
  • External messaging between Pipi and applications, such as databases, cloud platforms and containers, will be handled using an open-source messaging system, such as Kafka or RabbitMQ.
  • The two messaging systems need to interconnect. I don't know how yet! 😇
  • Event messaging and Pub/Sub are the most common; others include CQRS, Dead Letter, and Point-to-Point.
  • Each agent has a state.
  • Essential for robust Pipi self-management.
  • The pipiWiki will automatically document the configuration of each engine, including messaging (Gregorgrams) diagrams. See link to the Primative Engine (prm) mockup above.
  • The messaging configuration can change dynamically.
  • The Messaging Engine will be accessible for configuration via the coming msg module in the Agent Workspace

Pipi Engines to build, deploy and manage in the cloud

Mike's Notes

Finally got onto this job. Should be fun. 😊

Update 1

This is Infrastructure as Code (IaC). Get Pipi to generate the Terraform script.

Update 2

Don't use HCP Terraform Free Tier; it is being discontinued by IBM. Use an open-source product that Pipi can use internally without restriction to orchestrate cloud infrastructure.

  • OpenTofu + DIY Pipeline (Cloud Native Computing Foundation)
  • Terramate

The criticisms of Terramate

"Adopting Infrastructure as Code creates a new world of challenges

Terraform and OpenTofu lack standard code organization patterns, leading to code complexity, long-running pipelines, poor collaboration, drift, and high blast radii. Most vendors at best only partially mitigate these issues.

    • Poor environment management
    • Large blast radius
    • Config sprawl
    • Complex pipelines
    • Countless drift
    • Lack of observability

Pipi 9

The issues raised by Terramate could be handled natively by a yet-to-be-built Pipi Engine. Pipi excels at using standard code organisation patterns.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

25/01/2026

Pipi Engines to build, deploy and manage in the cloud

By: Mike Peters
On a Sandy Beach: 30/11/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

The problem

The open-source workspaces under development are designed to be shared on GitHub/GitLab and hosted in production on various Cloud Platforms. Eventually, private cloud and on-premises will be included, provided Pipi 9 can obtain secure access. In that case, hybrid clouds should also be fine.

Pipi 9 needs to be able to automatically build, deploy, and manage this process, either directly or via third-party tools such as GitHub Actions.

Agent Engines

An early Pipi 6 module from 2016 that catalogued cloud services was converted to a Pipi 7 microservice in 2018. Yesterday, this was imported into Pipi 9 and is being used to create these agents, which act as autonomous engines.

  • Platform Engine (plt) - this one is the commander on the battlefield. I will get this finished first.
A dedicated agent engine has been created for each cloud platform. They have yet to be differentiated.
  • Apple Engine (ale)
  • AWS Engine (aws)
  • AZURE Engine (azu)
  • Digital Ocean Engine (dgo)
  • Google Cloud Engine (ggc)
  • IBM Engine (ibm)
  • Meta Engine (met)
  • Oracle Engine (ora)
  • (More will be added later; all are welcome)
Then I remembered: Pipi 9 also has some self-deployment capacity, so generalising the existing capacity for building, deploying, and managing to share with the other engines makes sense.
  • Pipi Engine (pip) - for deploying to the closed data centre in a Boxlang/JRE host environment.

How

Most agents start like a Stem Cell. They are then modified to perform a specific job and can evolve over time. That's what I'm doing now.

I started last night in the GCP console, looking into how to reverse-engineer the APIs and build a data model to drive the API calls. Looks straightforward. The Gemini 3 chat is a big help and saves significant time.

But wait, there's more.

Each agent engine is complex and can incorporate other agents like LEGO bricks. Example: API Engine (api) and YAML Engine (yml). Just as in a living biological cell, everything is structured, in flux and self-regulating in response to its environment and internal processes. Other agent types, like primitives, are not complex.

Free-tier experiments

The Engines will initially play in the free tier of the different cloud providers. The first experiments could use GitHub Actions, leveraging the sample code identified and building on it.

Known available free tiers (more to come)

  • Alibaba Cloud
  • AWS
  • Azure
  • Cloudflare
  • Container Hosting Service
  • Couchbase
  • DigitalOcean
  • Google Cloud
  • Hetzner Cloud
  • IBM Cloud
  • Linode
  • Netlify
  • OpenShift
  • Oracle Cloud
  • OVHcloud
  • Render
  • Salesforce
  • Tencent Cloud
  • Vercel
  • Wasabi
  • Zeabur

Cost $$$$$$$ 😎😎

The free-tier usage limits need to be locked to prevent Pipi from burning through lots of cash.

Cloud credits

If Ajabbi can obtain cloud credits, using the more expensive resources would be possible to ensure everything works for future customers. It would enable customers to choose their preferred cloud provider without barriers.

No Series B

Ajabbi is a bootstrap start-up for public good (with a future foundation) and will have no investors, so there will be no Series B. Unfortunately, these cloud providers are obsessed with giving more credits only to Series B start-ups. Go figure.

Stock numbers

Use more agent engines as the workload increases. So if, for example, IBM Engine (ibm) can handle 1,000 enterprise customers, and 10.000 enterprise customers want IBM cloud setups, then Platform Engine (plt) can get the Factory Engine (fac) to breed more IBM Engine (ibm) to nibble on the work. I won't know the actual stocking ratio until field testing under load. However, it won't be a problem. And some huge customers need a dedicated agent engine or two each. All of this is possible.

Developer Accounts

The Workspaces for Developers, currently under development, will enable developers to help configure these agent engines and keep them up to date. This will also allow any platform to add itself by submitting a request for a dedicated agent engine and its developers, who will help with configuration and user documentation.


From Gemini 3

A Terraform script, more accurately called a Terraform configuration file, uses the declarative HashiCorp Configuration Language (HCL) or JSON to define infrastructure that Terraform will provision, manage, and version across various cloud and on-premises providers. Terraform is an infrastructure as code (IaC) tool, not a programming or scripting language in the traditional, procedural sense. 

Core Concepts

  • Declarative Language: You describe the desired end state of your infrastructure, and Terraform automatically determines the steps required to achieve that state, including dependencies between resources.
  • Providers: Terraform interacts with cloud providers (like AWS, Azure, Google Cloud, etc.) and other services through "providers," which are plugins that wrap existing APIs.
  • Resources: These represent infrastructure objects, such as virtual machines, subnets, or DNS entries, and are defined within resource blocks in the configuration file.
  • State: Terraform maintains a terraform.tfstate file to track the current state of your managed infrastructure, which is crucial for determining what changes to make during an apply operation. 

A Basic Terraform Configuration Example (AWS)

The configuration below defines a simple AWS EC2 instance. This would typically be saved as a .tf file (e.g., main.tf): 

hcl
# Define the required provider and minimum Terraform version
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
  required_version = ">= 1.7"
}
# Configure the AWS provider with a specific region
provider "aws" {
  region = "us-west-2"
}
# Define an AWS VPC resource
resource "aws_vpc" "example" {
  cidr_block = "10.0.0.0/16"
  tags = {
    Name = "example-vpc"
  }
}
# Define an output value to display the VPC ID after creation
output "vpc_id" {
  description = "The ID of the created VPC"
  value       = aws_vpc.example.id
}

 

Key Workflow Commands

Once you have a configuration file, you use the Terraform CLI to manage your infrastructure: 

  • terraform init: Prepares your working directory, downloading the necessary provider plugins.
  • terraform plan: Shows a detailed execution plan of what changes Terraform will make to your infrastructure to match your configuration.
  • terraform apply: Executes the planned actions to create, update, or delete infrastructure resources.
  • terraform destroy: Deletes all the infrastructure resources managed by your Terraform configuration. 

For more information, refer to the official HashiCorp Terraform documentation.