Your AI Agents Don't Need More APIs. They Need a Nervous System.

There is a predictable pattern in enterprise AI programmes right now. A team wraps a dozen existing REST endpoints in tool definitions, points an agent at them, and demonstrates something impressive in a sandbox. Six weeks later the agent is polling order status every ninety seconds, duplicating actions after a timeout, and nobody can reconstruct why it issued a credit memo last Tuesday. The instinct is to add more endpoints. The actual gap is architectural: the agent has hands but no nervous system. It can act, but it cannot perceive, remember, or be held to account.

Request-response teaches agents to guess

Synchronous APIs are a pull model. They answer the question you thought to ask, at the moment you thought to ask it. That is a poor fit for autonomous software whose entire value proposition is noticing that something changed and responding before a human would have. When the only available primitive is a GET, an agent compensates by polling — burning tokens, inflating cost, and still arriving late. Gartner's widely cited prediction that over 40% of agentic AI projects will be cancelled by the end of 2027, largely due to escalating costs and inadequate risk controls, describes exactly this failure mode. Cost and control problems are usually integration problems wearing a different hat.

Events invert the relationship. OrderBlocked, CreditLimitExceeded, ShipmentDelayed, ContractRenewalDue — these are the moments where judgement is actually required. An event-driven backbone lets an agent subscribe to the small set of situations that warrant its attention, rather than continuously interrogating systems that had nothing new to say. It is also the only economically sane pattern once you have dozens of agents rather than one pilot.

Design events as business facts, not table changes

The common shortcut is to stream change-data-capture output and call it an event backbone. Agents then have to reverse-engineer meaning from row deltas across three tables — precisely the kind of inference that produces confident, wrong actions. A usable event is a business fact with a stable name, a versioned schema, a source of truth, and enough context to act on without a follow-up round trip.

• Name the intent, not the mutation. PaymentTermsRenegotiated tells an agent something; BSEG_UPDATED tells it to go and find out.
• Version the contract explicitly. Schema registries and compatibility rules matter more when the consumer is a probabilistic system that will not raise a compile error.
• Carry provenance. Source system, actor, timestamp, correlation ID. This is what turns a stream into an audit trail.
• Publish a catalogue. If a developer cannot discover your events in a portal, an agent certainly cannot.

In SAP landscapes this is now well-trodden ground — Integration Suite and advanced event mesh give you the transport and the event portal — but the hard part remains editorial, not technical: deciding which two hundred of your ten thousand possible signals are genuinely worth publishing. That curation work sits squarely with enterprise architecture, and it is where we spend much of our time on SAP integration engagements.

API-first is now a safety requirement

Events tell an agent what happened. APIs are how it changes the world, and that side of the contract needs to get considerably stricter. Deterministic clients retry politely; agents retry creatively. Every write endpoint an agent can reach should assume a caller that may repeat itself, misread a partial success, or attempt an action it was never meant to perform.

• Idempotency keys everywhere. Non-negotiable for any state-changing operation exposed to a model.
• Reversibility by design. Publish the compensating action alongside the action itself, and make it callable.
• Scoped, short-lived credentials per agent. Not a shared service account with the union of everyone's permissions.
• Semantic documentation. Preconditions, side effects, and blast radius in the spec — the description field is now runtime input, not decoration.

The rise of the Model Context Protocol, now under Linux Foundation stewardship, has usefully standardised how tools are described and discovered. It has not solved authorisation, rate limiting, or observability. Your API gateway still does that job, and an MCP server placed in front of ungoverned endpoints simply industrialises the exposure.

The event log is the agent's memory

The underrated payoff is forensic. When actions and observations flow through a durable, correlated log, you can replay exactly what an agent saw and what it did — which is what regulators, auditors, and your own risk committee will eventually ask for. Bolting logging onto a mesh of point-to-point calls after the fact never produces the same fidelity. Build the backbone first, and explainability becomes a query rather than an archaeology project.

The enterprises pulling ahead are not the ones with the most agents. They are the ones whose event vocabulary is clean enough that a new agent can be onboarded in days, and whose API estate is safe enough that letting it act is not a leap of faith. That plumbing is unglamorous, it predates the current wave, and it is the difference between a pilot and a platform. If you are deciding where the next architecture investment goes, start with the signals, not the models.