The Second-Consumer Test: Most "Event-Driven" Enterprises Are Just Doing Async Point-to-Point

Every architecture review deck we see has the same slide: a broker in the middle, arrows radiating outward, the words "event-driven" and "API-first" in the same bullet. Then you open the runtime topology and find forty topics, each with exactly one publisher and exactly one subscriber, half of them carrying payloads shaped around what that one subscriber happened to need in 2023. That is not an event-driven architecture. That is point-to-point integration with extra latency and a licence fee. The distinction matters far more now than it did two years ago, because AI systems are the first consumers your organisation has ever built that nobody planned for in advance.

The test that actually separates the two

There is one diagnostic worth running, and it takes an afternoon: pick an existing event and try to add a second consumer without the publishing team doing any work. No schema change, no new field, no ticket in the producer's backlog, no meeting. If you can't, you have async coupling — the producer still knows who is listening, and that knowledge is baked into the payload.

Gartner's 2025 reference architecture work on event-driven applications puts schema governance and event contracts at the centre rather than treating them as a documentation afterthought, and that emphasis is correct. The broker is commodity infrastructure. The contract is the architecture. Everything expensive about integration — the coordination cost, the release-train dependencies, the reason a two-week change takes a quarter — lives in who has to agree with whom before something can ship.

Why AI raises the stakes on exactly this property

An agent or retrieval pipeline is, architecturally, an unplanned consumer. It wants state it wasn't designed into, at a cadence nobody scoped, with lineage good enough to explain an answer afterwards. Postman's 2025 State of the API report found that roughly one in four developers are already designing APIs with AI agents as the consumer, while fewer than 40% of organisations enforce centralised governance standards — a gap that almost guarantees the agent layer inherits whatever inconsistency the integration layer already had.

The practical consequences show up fast:

• Request-response hides causality. An API tells an agent what is true now. It cannot tell it that the credit limit changed twice this morning, which is often the fact that determines the right action.
• Payload-shaped-for-one-consumer breaks reuse. Events that carry a downstream system's derived fields force every new subscriber to reverse-engineer someone else's business logic.
• No replay means no evaluation. If you can't re-run last month's event stream, you can't regression-test an agent's behaviour against reality, only against synthetic cases.
• Undocumented topics become shadow interfaces. Anything an agent can subscribe to is an interface, whether you catalogued it or not — and uncatalogued interfaces are ungoverned ones.

What we'd actually change first

Not the broker. Start with the catalogue and the contract, then let the runtime follow. Specify events in AsyncAPI the way you already specify REST in OpenAPI, publish both into one discoverable surface, and make schema compatibility a pipeline gate rather than a review-board opinion. Give each event a named owner, a versioning policy, and a stated retention window — retention is a product decision, not a storage setting.

In SAP landscapes this is less exotic than it sounds. The event infrastructure is mature — SAP Integration Suite's advanced event mesh and standard business events from S/4HANA give you a credible publish side — and the real work is resisting the temptation to republish IDoc-shaped payloads onto modern transport. Our SAP services work almost always starts by separating the business event from the technical artefact that happens to emit it; the same discipline underpins how we approach integration in broader architecture engagements.

API-first and event-first are one decision, not two

Treat them as a pair with a clear split: APIs for intent and query, events for facts that have already happened. Trouble starts when teams use events to issue commands or APIs to poll for change. Write the rule down, enforce it in review, and most of the ambiguity disappears.

The organisations that will absorb AI cheaply over the next few years aren't the ones with the most models. They're the ones where adding an unplanned consumer is a self-service act. Run the second-consumer test this quarter. The answer tells you more about your AI readiness than any maturity assessment will.