The End of CRUD APIs? Designing Intent-Driven Services for AI Agents

Discover AnythingSignupWrite New StoryThe End of CRUD APIs? Designing Intent-Driven Services for AI AgentsbyFlaregun-devbyFlaregun-dev|@uthejdeveloperThis is thej, a software dev currently working on a startup app. Trying to find people to join the journey as wellSubscribeJuly 28th, 2026TLDR Your browser does not support the audio element.Speed1xVoiceDr. One Ms. Hacker byFlaregun-dev@uthejdeveloperbyFlaregun-dev|@uthejdeveloperThis is thej, a software dev currently working on a startup app. Trying to find people to join the journey as wellSubscribeStory's CredibilitybyFlaregun-dev|@uthejdeveloperThis is thej, a software dev currently working on a startup app. Trying to find people to join the journey as wellSubscribeStory's CredibilityTraditional CRUD APIs were designed around resources and operations such as create, read, update, and delete. That model remains effective for browsers, mobile applications, and service-to-service integrations where developers understand the domain and explicitly control the call sequence. AI agents operate differently. An agent receives a goal, selects tools dynamically, evaluates intermediate results, and may revise the execution path. Resource-oriented endpoints expose data structures, but they often hide the business meaning required for reliable autonomous action. As agentic systems become more common, API design is shifting from resource manipulation toward explicit intent. A CRUD interface might expose /customers, /inventory, /payments, and /shipments. Completing a purchase could require the agent to retrieve a customer, validate an address, reserve stock, authorize payment, create an order, and schedule delivery. Each call introduces another schema, dependency, failure mode, and opportunity for incorrect sequencing. The agent must understand details that traditionally belong inside the service boundary. A small prompt interpretation error can produce duplicate reservations, payment authorization without fulfillment, or an order created before required policy checks complete. An intent-driven service accepts the desired outcome rather than the individual mutations required to produce it. Instead of exposing internal workflow mechanics, the service presents a capability such as placeOrder, rescheduleDelivery, or resolveInvoiceDispute. The service then validates the request, applies domain rules, coordinates dependent operations, and returns a structured result. This approach does not remove REST, messaging, or internal CRUD operations. It changes the external contract presented to autonomous consumers. A concise Spring-style endpoint can make the distinction clear:@PostMapping("/intents/place-order") public OrderResult placeOrder(@RequestBody PlaceOrderIntent intent) { policyService.validate(intent); return orderWorkflow.execute(intent); } The endpoint describes a business action rather than a database mutation. Validation and orchestration remain inside the domain boundary, where transaction rules, compensation logic, and compliance checks can be enforced consistently. The agent does not need to infer whether inventory reservation must precede payment authorization or whether fraud analysis must be completed before shipment creation. Intent contracts require more precision than conventional application endpoints because agents depend on machine-readable semantics. An operation name alone is insufficient. The contract should define the goal, required inputs, preconditions, possible side effects, authorization scope, idempotency behavior, timeout expectations, and result states. OpenAPI can represent much of this information, while extensions can describe agent-specific metadata such as risk level, confirmation requirements, and execution mode.operationId: placeOrder x-intent: commerce.order.place x-risk-level: medium x-idempotency-required: true x-confirmation: conditional These annotations allow an orchestration layer to determine whether the operation is safe to invoke