Agents want more than an API. We just shipped the rest.

If you’re building an agent on top of an operations platform in 2026, the surface the platform gives you matters more than the platform itself.

A REST API is the table-stakes answer. Most B2B SaaS ships one, calls it done, and moves on. That used to be enough. It isn’t anymore. The agents your customers are sitting in — Claude Code, Cursor, Claude Desktop, the in-house workflow runner someone hacked together last month — don’t all want the same shape of access. Some want to shell out and pipe the result into jq. Some want a typed client they can call from a dotnet background service. Some want an MCP server they can hand to a model. And all of them need the answers to agree.

Today we’re shipping the next two surfaces. The Ekso CLI and the Ekso SDK are live.

Four surfaces, one source

Ekso now ships four ways to drive the product:

1. The REST API. The HTTP surface every other surface calls. Documented, versioned, public.
2. The CLI (ekso, dotnet tool install -g Ekso.Cli). A single binary that exposes every public API operation as a curated command, shaped for shells, scripts, and CI.
3. The SDK (Ekso.Sdk on NuGet). A typed C# client backed by Kiota, with auth, retry, and a real exception hierarchy.
4. The MCP server. 104 Model Context Protocol tools, mountable into any agent that speaks the protocol. Already shipping.

All four are generated from the same canonical OpenAPI spec, regenerated on every backend release. There is no drift. There is no “the SDK is two versions behind the API”. The typed surface is always the surface the API actually serves. For an agent, that’s the difference between I can plan against this and I have to write a probe call to find out what’s true today.

Why the CLI matters for agents

A CLI looks old-fashioned. It isn’t.

Every popular coding agent — Claude Code, Cursor, Continue, Aider, Codex, every CI runner — can shell out. None of them require a special integration to do it. If your product has a CLI, it has an integration with all of them, today, by default. “Run ekso item list --tenant acme --format json” is something a model can plan, write, and verify in one turn. “Read the OpenAPI spec at this URL, construct the right HTTP request, parse the response, handle the auth” is something a model can plan, write, and get wrong in three.

The Ekso CLI is built for that loop:

• Every operation is a command. Not a curated subset. The same depth as the API, shaped for shells.
• Output is structured. JSON by default, with table, yaml, and jsonl formats available. An agent piping ekso item list --format jsonl into the next step gets clean, line-delimited records — no scraping required.
• Exit codes mean things. Auth failure, validation, not-found, rate-limit — each maps to a specific POSIX exit code. A shell pipeline can branch on the cause without parsing stderr.
• Auth fits both humans and agents. ekso auth login opens a device-flow tab for humans. EKSO_API_KEY=... works for headless callers — CI runners, agents, background workers.
• Migration is in the box. ekso migrate collect and ekso migrate apply move tenants off Jira, Linear, Azure DevOps, Zendesk, and Countersoft Gemini. Attribution preserved, dry-runnable, resumable.

If you’ve ever tried to wire an agent into a SaaS product that only ships a REST API, you know what the alternative looks like. You write a wrapper. You write an authentication helper. You handle the token rotation. You parse the responses. You normalise the errors. You maintain it as the API drifts. The CLI is what that wrapper should be, written once, by us, generated from the same source as the rest.

Why the SDK matters too

The CLI fits the most agent workflows. The SDK fits the demanding ones.

When an agent is generating production code rather than driving a one-shot terminal session — a background service, a workflow runner, an internal tool — typed responses, compile-time guarantees, and a real exception hierarchy stop being nice-to-haves. They become the difference between code that runs in production for a year and code that breaks the first time the API changes a field name.

Ekso.Sdk ships:

• A single typed root, EksoClient, with every operation reachable as client.Api.{Resource}.{Verb}Async(...).
• Two auth strategies — ApiKeyAuth for service identities, RefreshableBearerAuth for OAuth tokens with automatic refresh and a TokensRefreshed event you can hook for persistence.
• A typed exception hierarchy: EksoAuthException, EksoRateLimitException (with RetryAfter), EksoValidationException, EksoNetworkException, EksoApiException. Catch the one you want; let the rest propagate.
• Generated model types for every request and response shape. IntelliSense is the discovery surface.

The first call is five minutes from dotnet new console:

var client = new EksoClient(new EksoClientOptions
{
    Tenant = "acme",
    Auth = new ApiKeyAuth(Environment.GetEnvironmentVariable("EKSO_API_KEY")!),
});

var page = await client.Api.Item.List.PostAsync(new ItemListRequest());
foreach (var item in page!.Data!)
    Console.WriteLine($"{item.Key}: {item.Name}");

That’s it. No bespoke HTTP client. No JSON dance. No unwrapping nullable nullable nullable. The types are the spec.

A deliberate rule about what scripts get to touch

Here’s the part that doesn’t get talked about often enough.

Every authenticated request through the CLI or SDK carries a JWT claim that says “this caller is a script, not the webapp.” The CLI marks itself Cli. The SDK marks itself Sdk. The backend reads that claim on every operation and uses it to decide what’s allowed.

Most operations don’t care. Listing items, creating items, updating fields, sending emails, running migrations — all fine from any client. But a small set of operations — the ones that change the shape of the platform itself, like editing system fields — are deliberately rejected when the caller is a script. The webapp can do them. The CLI and SDK cannot.

This is a real design decision, not a side effect. As more of the work in operations software gets done by agents, the platforms that survive the transition will be the ones that thought carefully about which actions belong to humans. “The agent can do anything the user can do” sounds liberating until the agent decides to delete the foundation everything else stands on. Drawing the line in code, at the API layer, is the only way to make that line load-bearing.

What ships today

• ekso CLI on NuGet as Ekso.Cli. Install with dotnet tool install -g Ekso.Cli.
• Ekso.Sdk on NuGet. dotnet add package Ekso.Sdk.
• 104 MCP tools, already live, already mountable.
• The REST API the other three are built on.

Docs live at ekso.dev/cli/overview and ekso.dev/sdk/overview.

If you’re building an agent over operations data — yours or your customers’ — try Ekso. Free tenant, unlimited users, sample data seeded: ekso.app/get-started. Sixty seconds from signup to your first ekso item list.

The next post in this series is about what we learned shipping all four surfaces from one source — the build pipeline, the generation strategy, the things we’d do differently. If you have an opinion on what’s worth covering, the contact link on ekso.app is the place.