Kourier uses optional analytics across our website, dashboard, and docs to connect referral sources with signup, payment, and first API use. We do not send API content or use analytics for targeted advertising. Read our Privacy Policy.

Back to blog

Agents call your software now: build typed actions on open models

AI agents now call software through typed actions instead of its UI. What that changes for product design and pricing, and why the model making the calls should have open weights.

For forty years, if you wanted to know what a piece of software could do, you looked at it: a window, some buttons, a menu, a settings pane. The interface was the contract. You learned the software by looking at it, and you explained it with a screenshot.

That's changing. More software now also exposes a registry of typed, permissioned actions that a person, a model, or another program can call directly. Sometimes the registry sits under the UI and sometimes it replaces it, and agents call it from outside without ever opening the app. If you ship a product that runs on inference, that changes how you design it, how you price it, and which model you build on.

Intents as the unit of software

An intent is a named request to read or change state. It carries types and authentication, and it's written so a person can say it and a machine can call it. "Send the user a friendly note" is a wish; messaging.send(to: ContactId, body: PlainText) is an intent.

Once intents are what you address, the GUI is one caller among several. A button click and an agent call go down the same path through the same gateway, and they differ only in how the result is rendered.

Compare the usual pattern, where an assistant is bolted onto the corner of an app and somehow can't do everything the app's own buttons can. That gap comes from the architecture: the assistant reaches a smaller set of actions than the UI does. When the action layer is the primary interface, every caller reaches the same actions.

Why this works now when it didn't in 2016

Alexa Skills, Google Actions, and the first version of SiriKit all tried this, and all of them had stalled by 2019. They had schemas. What they lacked was a client that could reliably turn free-form language into a typed call. Large language models are that client, and three developments made them dependable enough to build on:

  • Function calling, where the model emits a call against a schema you declare, went from a research problem to something you can put behind an SLA.
  • MCP gave intents a standard wire format, so any agent can discover an application's capabilities and call them.
  • The OS vendors shipped it. Apple's App Intents is already the largest typed-action runtime in production, on more than a billion devices.

The idea isn't new. The technology that makes it work at scale is, and it changes which architectures are practical to build.

Treat agents as clients

So don't build "an AI assistant" as a feature inside your product. Build typed actions, expose them over MCP, and let any agent call them with the same access your own UI gets. The agent might be yours, the one your user prefers, or another service's orchestrator.

Per-seat pricing stops fitting

Per-seat pricing assumes a person is the caller and that each seat roughly tracks the value a customer gets. One person can now run an agent that makes thousands of calls a day across dozens of services, and their seat says little about that usage. What an agent workload consumes is invocations, and in particular how many of them run at once.

That's why Kourier sells flat monthly plans sized by concurrency. You pay for how many requests your agents can run in parallel, with no per-token or per-request charges.

Why the model underneath should be open

Intent-native software depends on a model that calls tools reliably against typed schemas. If that model comes from a single closed provider, your lock-in moves from the application layer down to the inference layer. That's worse, because lock-in at that layer is harder to see and harder to leave.

Kourier serves open-weight coding models behind one OpenAI-compatible endpoint. Point your base URL at us and set your key, and the OpenAI-format code you already have runs without a new schema to learn. Every model we serve has public weights and a permissive license, so you can always take the model under your agents somewhere else. Each plan is a flat monthly price set by how many requests can run at once, which matches how agents use capacity.

Chat is one way to call software. If your product's main interface is a set of typed, permissioned actions, whatever kind of caller comes next can use them as they are. We're building Kourier to be the open inference layer those callers run on.

Serve open models through one API.

DeepSeek V4.1 Flash today, with Qwen 3.6 35B coming soon. Starter is $20/month; Pro is $50/month. No per-token metering.