Agent-Native Is a First-Class Surface, Not a REST Translation Layer

The first time you try to drive a creative-tools product through an agent at any volume, you notice something uncomfortable: the product was designed for a human clicking around, and the agent is paying for that assumption on every operation. Most creative tools shipping MCP servers today are bolting an agent surface onto an API built for human form submissions. The choice is recoverable now. It will not be recoverable for long.

This is a technical-architecture argument aimed at CTOs and platform engineers who are choosing between vendors, evaluating their own roadmap, or designing the integration layer for the next two years. The thesis: agent-native is a first-class surface decision made at the API and database boundary, not a translation layer added later. The cost of getting this wrong is invisible at low agent volume and structural at high agent volume.

What “Agent-Native” Actually Means

Agent-native is not a marketing posture. It is three concrete properties of an API surface:

• Agents have a path to the database that does not pass through the human-facing API. A REST endpoint built for a human form submission has request shapes, validation passes, error envelopes, redirect responses, and rate limits tuned to human latency. Routing every agent call through that same endpoint pays the human tax on every operation. A first-class agent surface (an MCP server, a typed RPC layer, a dedicated tool API) gives the agent a direct shape that matches its operation, not the form it would have submitted.
• The security boundary is the database, not the API. This is the load-bearing claim. If your REST API enforces tenant isolation by checking a session cookie at the route handler, an agent surface that bypasses that handler will leak. The fix is not “be careful at the agent boundary.” The fix is to put authorization in the row-level security policies on the database, so any path that reaches the data (REST, MCP, RPC, direct SQL through a service role) is governed by the same policy. The API becomes one consumer among several, not the gate.
• The agent’s instructions are part of the surface, not external documentation. The tool descriptions, schemas, and examples your agent reads at runtime are the actual contract, not the human-readable docs page. Human docs are derived from the contract. If your docs site is the source of truth and your agent surface is the derivative, you are still building for humans and asking agents to translate.

These three properties compound. Each one taken alone is a useful choice; all three together are an architecture.

The Bolted-On Pattern (And Why It Looks Fine in Demos)

The pattern most creative tools follow today: build a REST API for the web app, ship a v1.0, then add an MCP server that wraps the REST API in a thin translation layer. The MCP tool calls deserialize agent input, map it onto a REST request, hit the public API, deserialize the response, and return it to the agent. We covered the protocol side of this in MCP for creative tools; this post is about what sits underneath it.

This works in demos. It scales badly for three reasons.

The first is latency. Every agent operation pays for two serialization passes (agent to REST request, REST response to agent), one HTTP round-trip on a path that did not need to leave the process, and one full pass through middleware (auth, rate-limit, logging) that was designed for human cadence. At ten agent calls per session this is invisible. At a thousand it is a third of your latency budget.

The second is shape. REST endpoints are built around the request the human form would have submitted. Agents do not submit forms. They want to ask “give me every asset in this collection that has not been scored against this rubric in the last seven days, with their lineage parents and their last three annotations.” That query is a single database operation. Forced through a human-shaped REST API, it becomes six round-trips, three of them unnecessary, and a manual join the agent has to perform on the results.

The third is security. If the REST handler enforces tenant scoping by inspecting the session, the MCP server has to either replay the same scoping logic or hold a privileged service-role credential and trust itself to enforce isolation. Either choice creates a duplicated authorization surface, and duplicated authorization surfaces drift. The drift is silent until an audit catches it, or worse.

Shape Isn’t Cosmetic: Evidence From Figma

The shape problem has now been measured outside creative asset management. At Config 2026, in a talk on agentic workflows and the MCP, Figma described what happened when agents received a design over its MCP server in two forms. The default form described a table component in full, every visual style included, so verbose that the presenter had to shrink the slide text to seven points to fit it. The precise form was a short Code Connect snippet naming the production component and how data feeds into it.

With the verbose context, agents wrote most of the code, but people had to fill in a lot before the feature could ship. With the precise context, agents wrote more of the total code, there was less code overall, and less AI was used to get a better result. Figma’s own conclusion was broader than its product: precise context helps agents do more of the work, write better code, and run more cheaply.

That is the shape argument from the agent’s side. An agent surface that returns whatever the human-facing API happened to return pays for it twice: once in latency, and again in the agent’s attempts to infer what the extra payload meant. For a creative library, the equivalent of the seven-point table is handing an agent every node of the workflow that produced an image when it needed three fields: which model, which inputs, which version.

The First-Class Pattern

The structurally different choice: design the database first, the access policies on the database next, and then build two equal-status consumers (REST for humans, MCP for agents) that both go through the same policy boundary.

In the architecture I work on day-to-day, this means:

• Row-level security on every multi-tenant table. Tenant isolation, role-based access, and feature-flag gating live in the database. Anything that reaches the data passes through them.
• MCP tools call typed database functions (RPCs) directly. They do not go through REST. Those functions are themselves governed by the same row-level security policies. The trade is a small amount of duplication between the REST handler’s business logic and the database function’s business logic, in exchange for a path that pays for one serialization pass and one round-trip instead of two of each.
• Tool descriptions and schemas are the contract. The MCP server publishes typed tool definitions with input schemas, output schemas, and natural-language descriptions tuned for agent comprehension. The web app’s documentation pages are generated from those definitions, not the other way around. The same idea runs through agent-first interface design.
• Agents authenticate as themselves, not as the human running them. An agent operating on a tenant’s behalf has its own credential, its own audit trail, and its own permission scope. When the audit log shows an action, it shows whether a human or an agent performed it, and which agent.

The cost of this architecture upfront is real: it is more work in week one. The benefit accrues every time a new agent surface is added, every time the security model is audited, and every time agent volume scales.

Three Tells of an Agent-First Stack

If you are evaluating a creative-tools vendor and want to assess whether their agent surface is first-class or bolted on, three signals:

• Ask whether the MCP server hits the REST API or the database directly. If they hit REST, you are paying the human tax. If they hit the database through a typed RPC layer governed by the same RLS as REST, the architecture is intentional.
• Ask where authorization lives. If the answer is “in the API layer,” the agent surface and the human surface have separate authorization paths and they will drift. If the answer is “in the database, enforced by RLS, with both surfaces as equal consumers,” the policy boundary is structurally correct.
• Ask whether agents authenticate as themselves. If the agent uses a human’s session token, you are conflating accountability. If the agent has its own credential, scoped to its operations, with its own audit trail, the operational model anticipates a world where agents act for organizations, not just for individuals.

These are not gotcha questions. They are the load-bearing decisions that determine whether the platform is durable as agent volume scales from a handful of demos to a steady operational presence.

Why This Matters Now

Within twelve to twenty-four months, agents will routinely act on behalf of organizations: handling asset transfers, brand-conformance reviews, licensing checks, ingestion pipelines, audit responses. The volume of agent-driven operations against creative-tools platforms will not look like the demo volume of 2026. It will look like the operational reality of integration-driven systems: orders of magnitude more calls, with stricter latency budgets, and accountability requirements that demand per-actor audit trails.

In that reality, the platform whose agent surface is a translation layer over REST will eat the human tax on every interaction, leak authorization at every drift, and degrade in latency as agent volume rises. The platform whose agent surface is first-class will not. The buyer choosing between them today is making a structural decision whose cost they will not see for a year, and after which they cannot easily migrate.

If you are building this layer, build it correctly the first time. If you are buying it, ask the three questions.

Key Takeaways

• Agent-native means three things: a path to the database that does not pass through the human-facing API, security at the database boundary, and tool definitions as the contract.
• Bolted-on MCP servers (wrappers around REST) pay a latency, shape, and security tax that is invisible at low volume and structural at high volume.
• Shape is measurable: Figma found that precise context let agents write more of the code with less code and less AI usage than verbose context did.
• First-class architecture: RLS at the database, MCP via direct database functions, tool descriptions as canonical, agents authenticating as themselves.
• Three vendor evaluation questions: where does MCP hit, where does authorization live, do agents authenticate as themselves.
• The decision is structural and hard to reverse, which is why making it correctly the first time matters.