Unified APIs vs. AI-Native Actions: What AI Agents Actually Need

StackOne started as a unified API company.

If you’re not familiar with the model: take dozens of SaaS platforms in a category (say, HR systems like Workday, BambooHR, SAP SuccessFactors), normalize their data models into a single schema, and let developers write one integration that works with all of them. Several companies built businesses around this. So did we.

The unified API model works well for its intended audience: developers writing deterministic code where the consumer is software. When we started building for AI agents, the assumptions behind that model stopped holding.

This post explains why, where the problems are worst (documents and permissions are good examples), and what we built instead.

What is the unified API model?

You have 200 HR systems, each with different endpoints, authentication flows, field names, and pagination styles. Instead of building 200 integrations, you build one. A list_employees call returns the same shape whether the underlying system is Workday’s SOAP API or BambooHR’s REST API.

For traditional software, this works. Your application code doesn’t care that Workday calls it Worker and BambooHR calls it Employee. You need a consistent first_name, last_name, department to populate a dashboard or run a sync job.

The unified API handles the translation. Developers ship faster. Customers connect their tools.

This breaks down when the consumer is an LLM instead of application code.

Where unified APIs fail agents

We saw these problems gradually. They started as friction in customer conversations and became technical limitations we couldn’t work around.

Agents think in native system language, not unified schemas

When a user tells an agent “find all open reqs in Greenhouse,” they’re thinking in Greenhouse terms. They know what a “req” is in Greenhouse. They know the fields, the filters, the status labels.

A unified API translates req into a generic job object. It renames opening_id to job_id. It maps Greenhouse-specific statuses into a normalized enum. The agent receives data that doesn’t match what the user said, what documentation describes, or what the LLM was trained on.

The LLM has to translate twice: once from the user’s intent to the unified schema, and again from the unified response back to the user’s mental model. Every translation is a chance to lose meaning. Unified APIs maximize that interpretation distance.

The lowest common denominator problem with unified APIs

A unified API can only expose fields that exist (or have reasonable equivalents) across all providers it supports. Each new provider with fewer capabilities shrinks the unified model further. By the time you support 50 systems, you’re down to the intersection of what they all share.

The pattern is well-documented: the more apps supported within a unified API, the more limiting it becomes.

For agents, depth matters. An HR agent needs to understand that Workday tracks compensation_grade differently from BambooHR’s pay_rate. A recruiting agent needs Greenhouse’s scorecard structure, not a flattened evaluation_score field. Stripping provider-specific fields to maintain a unified model strips the agent’s ability to do useful work.

Some SaaS capabilities are lost in unified APIs

Greenhouse has structured keyword search. Workday uses XPath-based queries. Jira has JQL, a full query language with operators, functions, and nesting. Salesforce has SOQL, which is basically SQL for objects.

How do you unify JQL and free-text search? You can’t, not without destroying what makes JQL useful. A unified search endpoint that accepts a string query works for BambooHR but removes Jira’s ability to run project = BACKEND AND status changed FROM "In Progress" TO "Done" AFTER -7d.

Some capabilities are fundamentally incompatible. A unified API picks a lowest common denominator, and that denominator is usually “simple text search” when the user wanted a structured query.

Unified APIs create query languages LLMs have never seen

Unified APIs offer depth. But it often serves the API design, not the agent consuming it.

Expand parameters, nested include paths, complex filter syntax with dozens of operators. These features exist because the unified API is compensating for its own abstraction. “Yes, we normalized the model, but you can use expand=manager.department.cost_center to get the data you actually needed.”

An agent calling a unified API now needs to understand a query language that isn’t the underlying system’s language and isn’t the user’s language. The LLM wasn’t trained on it. There’s no Stack Overflow post explaining the nuances. The agent guesses, and often guesses wrong.

From unified API compression to agent field-level control

A single employee record from Workday’s native SOAP API runs approximately 17,000 tokens. A unified employee object compresses this to about 600 tokens. That 28x reduction helps traditional API consumers, and it’s one of the clear wins of the unified approach — transforming verbose formats like SOAP into standardized, leaner responses.

But agents have a harder constraint: reasoning quality degrades well before you hit the context window limit. Research on context utilization found that model performance becomes increasingly unreliable as input length grows.

A unified API returns all normalized fields whether the agent needs them or not. An agent asking “what department is Alice in?” gets back her full compensation history, emergency contacts, and employment timeline. Multiply this by a list call returning 100 records, and you’ve burned 60,000 tokens on data the agent will never reference.

The lesson from unified APIs: standardizing and compressing data is valuable. The next step is giving agents field-level control — filtering, field selection, and token-aware responses — so they receive only what matters for the specific task.

Unified APIs contradict what large language models know

LLMs are trained on vast amounts of API documentation. Claude, GPT, Gemini: they’ve all seen Greenhouse’s API docs, Workday’s developer guides, Salesforce’s reference. They know what a Requisition is in Greenhouse. They know Workday’s Worker object structure.

When you route these models through a unified API that renames Worker to Employee, changes field names, restructures nested objects, and maps statuses to different enums, you’re fighting the model’s training data. The agent knows that Workday calls it Worker. Your unified API insists it’s Employee.

We watched agents consistently fail on nested query parameters. Connectors with query params under HTTP in: query created query: { query: "..." } schemas that LLMs misinterpreted, causing invalid_type errors. The fix was schema flattening: making tool schemas match what the model expects, not what the API designer thought was clean.

Documents and permissions: unified behavior, native semantics

Two categories show why combining unified behavior with native semantics matters most: documents and identity/access management (IAM). Both deal with data that varies wildly across providers, and both require precision that goes beyond a single normalized schema.

Documents: where same behavior beats same schema

Google Drive organizes files in folders with sharing permissions at the file level. SharePoint uses sites, document libraries, and item-level permission inheritance. Confluence stores pages in spaces with a parent-child hierarchy. Notion has databases, pages, and blocks.

A unified list_documents endpoint can return file names and IDs. But an agent that needs to “find the Q4 revenue report in the finance team’s SharePoint site” needs to understand SharePoint’s site/library/folder hierarchy. Flattening that into a generic folder model loses the context the agent needs to navigate.

The same applies to file metadata. Google Drive tracks owners, shared_with, last_modifying_user. Confluence tracks space_key, version, ancestors. A unified schema picks a handful of common fields and discards the rest.

StackOne’s Documents API takes a different approach. Instead of forcing every provider into one schema, it exposes native document structures with consistent behavior (pagination, field selection, token-aware responses) while preserving provider-specific metadata. An agent working with SharePoint gets SharePoint concepts. An agent working with Confluence gets Confluence concepts. The API reference covers each provider’s specific capabilities and field mappings.

For agents building RAG pipelines or searching knowledge bases, this distinction between “same schema” and “same behavior” is the difference between finding the right document and returning garbage.

Permissions: native models for compliance and security

IAM data is where the stakes of getting the model wrong are highest.

Every SaaS application models permissions differently. Okta has users, groups, and application assignments. Azure AD has users, groups, roles, and directory roles. Google Workspace has organizational units, groups, and per-service admin roles. Salesforce has profiles, permission sets, and permission set groups.

A unified list_users endpoint can return names and email addresses. But an agent doing a user access review needs to answer: “Does this user have admin access to Salesforce?” That requires understanding Salesforce’s specific permission model, not a flattened role: admin field that means something different in every provider.

The consequences of getting permissions wrong are also different from other categories. A bad employee record is an inconvenience. A bad permissions audit can mean compliance failures, unauthorized access, or missed security risks.

StackOne’s Permissions API covers 80+ SaaS applications and preserves each provider’s permission model. When an agent queries user access in Okta, it gets Okta’s group memberships and application assignments. When it queries Azure AD, it gets Azure AD’s role assignments and directory roles. The documentation maps out each provider’s permission structure so agents (and the developers building them) can work with the actual data model.

For compliance automation, license management, and security reviews, agents need the real permission data, not an approximation.

What unified APIs got right

We built a unified API for years. Some of what we built carries directly into the agent-first model.

Authentication

Managing OAuth flows, token refreshes, API key rotation, and SAML handshakes across 200+ platforms is hard. Abstracting authentication behind a single credential removes an entire category of agent infrastructure work.

Every agent builder who tries to connect directly to enterprise SaaS immediately hits the authentication wall. Unified APIs solved this, and that solution transfers directly to agents.

Deep system knowledge

Years of building integrations teach you things that aren’t in the docs. Rate limit quirks, undocumented pagination behaviors, field-level gotchas that only surface at scale. This institutional knowledge is valuable regardless of whether you expose a unified schema or native actions.

When we built our new engine, we carried this knowledge forward into actions that account for each system’s specific behaviors.

Compound actions

Not everything an agent needs to do maps to a single API call. “Transfer an employee from BambooHR to Workday” involves reading from one system, transforming data, writing to another, and handling edge cases.

Multi-step actions that handle orchestration, error recovery, and data transformation in a single tool call save agents (and their context windows) real work.

Standardized behavior

Pagination is a good example. Every API paginates differently: cursor-based, offset-based, page tokens, link headers. Standardizing pagination behavior so an agent can reliably page through results without learning each system’s approach is useful.

Same for filtering output. If every tool supports a consistent way to select fields, limit response size, and truncate large payloads, agents can manage their context budget without per-tool logic. This isn’t data model unification. It’s behavior standardization.

What AI agents need for SaaS integrations

We spent eighteen months building for agents after years on the unified API model. Here’s what works.

AI-native actions

Instead of mapping everything to a unified schema, build actions that reflect how each system actually works. A Greenhouse action should return Greenhouse objects with Greenhouse field names. A Workday action should use Workday’s terminology.

The agent doesn’t need a universal Employee object. It needs a clear, well-documented workday_get_worker action that returns exactly what Workday returns, structured for LLM consumption.

Anthropic’s research on tool design confirms what we’ve observed: tools that match the model’s training distribution perform better than tools that introduce novel abstractions.

LLM context optimization

Agents need the right data, not all of it.

Metadata surfacing. Before fetching anything, the agent can ask “how big would this response be?” A dry-run mode returns record counts and token estimates. The agent decides whether to proceed, filter, or delegate to a sub-agent.

Server-side filtering. Instead of returning 500 employee records, let the agent filter at the source. Select specific fields. Apply conditions. Filtering happens before data enters the context window.

Token-aware responses. Include total_count, returned_count, truncated, and estimated_tokens_per_item in response metadata. The agent knows exactly what it got and what it’s missing.

None of these require a unified data model. They require tool design that treats context as a scarce resource.

Focused AI tools for specific tasks

An agent planning a compensation review doesn’t need a complete employee record. It needs name, current salary, last review date, manager, performance rating. Five fields, not fifty.

get_employee_compensation_summary is more useful than get_employee with an expand parameter. The tool name tells the agent what it’s getting. The response contains only what’s relevant.

This is the opposite of the unified API philosophy, which tries to serve every use case through one endpoint. Agent-first design builds many focused actions, each returning exactly what a specific task needs.

Dynamic AI tool discovery

With 10,000+ actions across hundreds of connectors, you can’t load every tool definition into the context window. We built meta-tools: a search layer that lets agents discover relevant actions based on what they’re trying to do. For the search algorithms behind this, see our comparison of BM25, TF-IDF, and hybrid search and how we added semantic search with enhanced embeddings.

The agent asks “what can I do with Greenhouse?” and gets back a filtered list of applicable actions, scoped to what the connected account has permissions for. This is closer to how a developer explores an API than how a unified API client works.

Testing AI actions at scale

Building AI-native actions doesn’t mean abandoning quality. Each action in our engine is defined in YAML, generates deterministic RPC/REST and AI tool interfaces from the same spec, and goes through behavioral testing.

We benchmark how accurately models select and call tools across thousands of task scenarios. A focused greenhouse_list_open_jobs action is easier to test than a generic list_jobs endpoint that behaves differently depending on which provider is connected.

Why we rebuilt: from unified API integrations to agent-first SaaS integrations

We built the unified API. We saw where it worked and where it didn’t for agents. We built a new engine that generates AI-native actions purpose-built for agent consumption.

Our old engine added integrations linearly, with each one requiring custom code, manual mapping, and QA cycles. The new engine adds integrations in days, not weeks. We traded data model unification for behavior standardization, and the result is better for agents.

What to evaluate when building agents that interact with enterprise SaaS?

If you’re building agents that need to interact with enterprise SaaS, here’s what to evaluate:

1. Does the tool preserve the underlying system’s semantics? Or does it introduce a new vocabulary the model has to learn?
2. Can the agent control how much data it receives? Filtering, field selection, dry-run modes, token estimates.
3. Are actions scoped to specific intents? Or is it one big CRUD endpoint with complex parameters?
4. Can the agent discover available tools dynamically? Without loading thousands of schemas into context?
5. Does the integration preserve provider-specific capabilities? Especially for documents and permissions, where precision matters most.

Unified APIs will continue to work for traditional integration use cases. For agents, the architecture needs to be different. At StackOne we learned the difference by building both: unified APIs and agent-first enterprise SaaS integrations.