Redefining service integration

Agents don't call APIs.
They speak to services.

The gateway layer between AI agents and the services they need. One natural language interface. Every action.

The problem

APIs were designed for humans writing code. Not for agents taking action.

For 20 years, REST APIs have been the standard interface between services. They work well when a developer reads documentation, writes integration code, handles authentication, manages errors, and maintains the connection over time.

But AI agents don't work that way. They understand intent. They reason about goals. They shouldn't need to parse OpenAPI specs or manage OAuth flows. They need a layer that translates what they want to do into what services expect to receive.

Traditional API Integration

  • Read documentation for every service endpoint, understanding parameters, auth methods, and rate limits
  • Write glue code for each integration - SDKs, error handling, retry logic, type conversions
  • Manage credentials across services - API keys, OAuth tokens, refresh cycles, permission scopes
  • Handle failures with custom logic for each provider's error format and status codes
  • Maintain over time as APIs deprecate endpoints, change schemas, and update versions

Agent Gateway

  • Describe the intent in natural language - "refund the last payment from this customer"
  • Gateway resolves the correct service, endpoint, parameters, and executes the action
  • Credentials are managed centrally - stored encrypted, injected at runtime, rotated automatically
  • Errors are interpreted and returned as structured context the agent can reason about
  • Services evolve independently - the gateway adapts without breaking agent workflows
How it works

From prompt to action in one call.

The gateway sits between your AI agent and any external service. It receives natural language intent, resolves it to the correct API call, handles authentication, executes the request, and returns structured results.

Request Flow
Your Agent
Sends natural language intent
OAG Gateway
Resolves, authenticates, executes
Service API
Stripe, AWS, Slack, etc.
Structured Result
Back to your agent
before.ts
// Traditional: 47 lines to send a Slack message and create a Jira ticket

import { WebClient } from '@slack/web-api';
import JiraApi from 'jira-client';

const slack = new WebClient(process.env.SLACK_TOKEN);
const jira = new JiraApi({
  protocol: 'https',
  host: 'your-domain.atlassian.net',
  username: process.env.JIRA_USER,
  password: process.env.JIRA_TOKEN,
  apiVersion: '2',
});

await slack.chat.postMessage({
  channel: '#engineering',
  text: 'Payment service is returning 503 errors',
});

await jira.addNewIssue({
  fields: {
    project: { key: 'ENG' },
    summary: 'Payment service 503 errors',
    issuetype: { name: 'Bug' },
    priority: { name: 'High' },
  }
});
after.ts
// With Open Agent Gateway: 1 call, natural language

const gateway = new OpenAgentGateway({ key: process.env.OAG_KEY });

const result = await gateway.execute({
  intent: `Alert #engineering on Slack that payment service is returning 503s,
          then create a high-priority bug ticket in Jira project ENG`,
  services: ["slack", "jira"],
  confirm: true
});

// result.actions: [
//   { service: "slack", action: "postMessage", status: "sent" },
//   { service: "jira", action: "createIssue", status: "created", key: "ENG-4521" }
// ]
Comparison

What changes when the interface is language, not code.

Dimension REST API Legacy Agent Gateway New
Interface HTTP methods, JSON payloads, query params Natural language intent
Authentication Developer manages keys per service Gateway handles credential injection
Error handling Custom code per provider's error format Structured error context for agent reasoning
Multi-service actions Orchestration code, saga patterns, rollbacks Single compound intent, gateway orchestrates
Maintenance Update code when APIs change versions Gateway adapts; agent intent unchanged
Time to integrate Hours to days per service Minutes. Connect credentials, describe intent.
Who builds it Developer reads docs, writes code Agent describes what it needs to do
Use cases

What agents can do through the gateway.

Any action your agent needs to take in the real world - from sending a message to provisioning infrastructure - flows through one interface.

💰

Payments & Billing

Process refunds, create subscriptions, update invoices across Stripe, Square, or any payment provider.

📨

Communications

Send emails, post Slack messages, trigger SMS alerts, create support tickets - all from one prompt.

☁️

Cloud Infrastructure

Provision resources, scale services, configure DNS, manage deployments across AWS, GCP, Azure.

📈

Data & Analytics

Query databases, update dashboards, trigger ETL pipelines, pull reports from any data source.

🛠

DevOps & Monitoring

Create incidents, acknowledge alerts, deploy hotfixes, update status pages through PagerDuty, Datadog, etc.

💼

Business Operations

Update CRM records, schedule meetings, generate documents, manage project boards in Salesforce, Notion, Linear.

Capabilities

What the gateway handles so your agent doesn't have to.

Intent Resolution

Maps natural language to the correct service, endpoint, method, and parameters. Handles ambiguity by asking for clarification when needed.

Credential Vault

AES-256 encrypted storage for API keys and OAuth tokens. Automatic refresh cycles. Your agents never see raw credentials.

Action Guardrails

Define policies per service and action type. Read operations flow freely. Write/delete operations require confirmation. Fully configurable.

Compound Actions

Chain multiple service calls in a single intent. The gateway handles ordering, dependency resolution, and rollback on failure.

Full Trace Logging

Every intent-to-action path is recorded. See what your agent asked for, how it was resolved, what was executed, and what was returned.

Model Agnostic

The gateway is the execution layer, not the reasoning layer. Works with GPT-4, Claude, Gemini, Llama, or any model you choose.

Design principles

How we think about building this.

01

Agents should act, not integrate

An agent's job is to reason about goals and decide what to do. The mechanics of how to call a service - authentication, serialization, error codes - should be invisible to it. The gateway absorbs that complexity.

02

Safety by default

Any action that modifies state requires explicit confirmation. The gateway enforces permission boundaries so agents can explore freely without causing damage. Read everything. Write nothing without approval.

03

Observable and auditable

Every decision the gateway makes is traceable. From the original intent to the final API call, the full chain is logged and inspectable. You should always know exactly what your agents did and why.

04

Open and extensible

We don't gatekeep which services you can connect. Bring any API with an OpenAPI spec and the gateway can learn to speak it. The protocol is open. The connectors are composable.

05

Language is the interface

The best interface for an AI agent is the one it already speaks. Natural language is more expressive than REST conventions. It captures intent, not just method calls. The gateway translates intent into action.

We're building in the open.

Early access is limited. Leave your email and we'll be in touch.