Giving an AI agent a folder of passwords is not an integration strategy. It is an unbounded delegation of authority.
The pattern feels convenient because it copies how people use software: sign in, open a page, and click. But it hides the questions a production system must answer. Which organization is active? Which records are in scope? Which operations are allowed? Which changes require a person to confirm them?
An action layer makes those questions explicit.
Discovery must be bounded
An agent should not receive a dump of every application and operation a platform has ever implemented. Discovery should be filtered by the active credential and context.
The useful sequence is:
- discover the applications available to this identity;
- select one application;
- discover its permitted actions in a bounded page;
- inspect the input contract for the chosen action;
- execute with the same credential and context;
- record the result.
This approach is easier for a model to reason about and safer for a platform to authorize. It also scales better than placing a giant action catalog into every prompt.
Credentials should describe the operator
People, services, and agents have different risk profiles. A user session, a service credential, and an agent context should not collapse into one anonymous token.
The platform needs to retain who delegated the authority, which organization and resource context is active, and which permissions were granted. That context must survive from discovery through execution. Otherwise the system can show an agent one set of capabilities and execute against another.
Confirmation is part of the contract
Read operations and reversible drafts are different from sending money, deleting data, publishing content, or changing access.
Confirmation should not be a polite sentence in a prompt. It should be a property of the action contract and enforced by the runtime. The client can then present the right approval experience for a person, an autonomous workflow, or a supervised agent.
MCP and CLI are interfaces, not the authority
MCP makes capabilities available to compatible AI clients. A CLI makes the same platform scriptable in terminals and automation. An SDK gives developers a typed integration surface.
None of them should invent authorization. They should all consume the same live catalog, credential context, and action definitions. This is the boundary Topolo is establishing across its Developers catalog, Auth service, SDK, CLI, and MCP server.
A good action layer compounds
Once the boundary exists, every new application becomes more useful. Its actions can be discovered by agents, composed into workflows, exposed in developer tools, and governed through shared policy.
That is a stronger network effect than adding another isolated assistant. Each application expands one operating system instead of creating another island.