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

Traditional 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 automatically. A low-risk intent may execute immediately, while a high-value transfer may require a preview, policy approval, or human confirmation. The API becomes a capability contract rather than a collection of loosely related routes.Idempotency is especially important because agents may retry after timeouts, uncertain responses, or interrupted reasoning loops. A duplicated CRUD call can create a second payment or shipment. Intent-driven services should require an idempotency key and return the original execution result when the same request is replayed.public OrderResult execute(PlaceOrderIntent intent, String idempotencyKey) { return executionStore.find(idempotencyKey) .orElseGet(() -> executionStore.save( idempotencyKey, coordinator.placeOrder(intent) )); } The execution record should capture status transitions such as accepted, validating, awaiting approval, executing, completed, partially completed, compensated, and failed. These states give agents a stable way to continue long-running tasks without guessing whether an earlier action succeeded.Some intents should support planning before execution. A planning endpoint receives the same goal but returns expected steps, costs, constraints, and side effects without making changes. A separate commit operation can execute the approved plan. This pattern is useful for financial transactions, infrastructure changes, travel bookings, account closures, and other actions where consequences must be reviewed before commitment. Planning also improves agent reliability because unsupported assumptions become visible before irreversible work begins.The response model should be equally explicit. Returning a generic success flag forces the agent to infer whether the goal is complete, partially complete, or waiting on another actor. A production contract should return the intent identifier, current state, completed effects, pending requirements, recoverable errors, and the next permitted actions.Errors should be semantic rather than purely transport-oriented. PAYMENT_REQUIRES_REAUTHENTICATION is more actionable than 400 Bad Request, while INVENTORY_CHANGED can include acceptable substitutions or a revised quantity. This structure gives the agent enough information to continue safely without inventing recovery behavior.Capability discovery also matters when tools are selected at runtime. A registry or protocol, such as MCP, can expose operation descriptions and schemas, but discovery must remain constrained by authorization and context. Advertising unavailable or forbidden intents increases planning errors and may reveal sensitive capabilities.Discovery responses should therefore be filtered by identity, delegated permissions, environment, tenant, and current policy. The resulting tool surface becomes smaller, clearer, and easier for an agent to use correctly.Intent-driven services still require bounded autonomy. Authorization should be aligned with capabilities rather than broad resource access. A token that permits reading and updating every order is harder to govern than a token limited to commerce.order.place with a transaction ceiling. Policy checks should evaluate the requesting agent, delegated user, data sensitivity, monetary value, geographic restrictions, and current risk signals. The service must reject an intent when required context or authority is missing rather than attempting to infer permission.Observability must also move above the HTTP request level. A successful 200 OK does not explain whether the intended business outcome was achieved. Telemetry should correlate the original goal, selected capability, policy decision, workflow steps, external dependencies, retries, compensation actions, and final outcome. Structured events make agent behavior auditable and support failure analysis across long-running executions.audit.record(IntentEvent.builder() .intentId(intent.id()) .capability("commerce.order.place") .agentId(context.agentId()) .status(result.status()) .policyDecision(result.policyDecision()) .build()); This event should not expose hidden model reasoning. Operational traceability requires observable decisions and effects, not private chain-of-thought content. Recorded facts should include supplied parameters, selected tools, policy outcomes, state transitions, and externally visible results.Intent granularity requires careful design. An endpoint such as runBusinessProcess is too broad to secure, test, or document. An endpoint such as updateOrderStatus is often too close to CRUD and may expose an invalid state transition. Effective intents represent meaningful domain capabilities with clear boundaries. They should be independently authorizable, idempotent where possible, observable, and explicit about side effects.Migration does not require replacing every existing endpoint. Current CRUD APIs can remain as internal primitives or support conventional clients. An intent layer can orchestrate those operations while gradually moving domain rules away from clients. This creates a practical transition path where existing integrations continue functioning, while agent-facing contracts become safer and more expressive.CRUD APIs are not disappearing, but their role is changing. Resource operations remain useful implementation mechanisms, yet they are often an inadequate interface for autonomous systems expected to act on goals. Intent-driven services place business meaning, sequencing, policy, and recovery inside the service boundary, where those concerns can be controlled consistently. The strongest agent-ready APIs will not merely expose data. They will present bounded, discoverable, auditable capabilities that convert declared outcomes into governed execution.