This is different from giving an agent an API key. An API exposes a fixed set of calls. An app exposes the working surface: what the screen shows, what data exists, what state the app is in, and what can happen next.
API, plugin, and app for agent
| API | Plugin / tool | App for Agent | |
|---|---|---|---|
| What the agent gets | A set of endpoints | One added capability | The interface, data, state, and actions |
| Can the agent see the current screen? | No | No | Yes, if it reads the rendered structure |
| Can the agent decide what to do next? | Only within the endpoints | Only within the tool | Yes, within permissions |
| Who maintains the integration? | The developer | The plugin author | The Space and the agent, together |
| Typical failure | Wrong call or missing context | Tool is too narrow | Interface or state is not readable |
An API is still useful. A plugin is still useful. The question is whether the agent has enough context to use them well. For a narrow task, an API call may be enough. For work that happens in a screen with data and state, an app for agents is a better fit.
Why agents need the working surface
Agents fail in predictable ways when they cannot see the work:
- They guess the current state and act on stale information.
- They call a tool that does not match what the screen is showing.
- They finish a step but cannot tell whether it worked.
- They need a person to translate between the interface and the task.
Exposing the working surface fixes most of these. The agent can read the current view, check the data, act, and verify the result. The person can still review the change in the same interface.
How Sigla builds apps for agents
In Sigla, the AI Agent Space is both the app and the agent's working environment. The Space holds an interface, data, files, logic, and connected capabilities. MCL, Sigla's AI Native Framework, expresses all of it as one body of code. That code is the context the agent reads.
This has three consequences:
- The agent can see what the app does and where its state lives.
- A change is made in the same structure that runs the app.
- The result is usable by a person and by an agent at the same time.
That is what "an app for agents, not code you maintain" means in practice. You are not shipping a codebase to an integration team. You are using a Space that the agent can read, change, and operate.
FAQ
Is an App for Agent the same as an API?
No. An API exposes calls. An App for Agent exposes the working surface: interface, data, state, and actions. Both can be used by an agent, but they provide different amounts of context.
Do I need to build a separate app for my agent?
Not necessarily. If the work happens in one Space, the same Space can serve the person and the agent. A separate app is useful when the agent needs a narrower or safer surface.
Can an agent use an app that was not designed for it?
Sometimes, through computer use or browser automation. It is usually slower and less reliable than software whose structure is readable. That is why "agent-ready" is a design choice, not only a runtime trick.