Platform · Service Repository
Reusable services your agents can use.
A dedicated repository exposes the actions agents can invoke, each with a clear contract between planning and implementation.
Service Repository
Turn capabilities into reusable services.
A dedicated repository exposes the actions agents can invoke.
The Service Repository is the platform component that makes business capabilities available to agents. An action describes what a service does and which inputs it requires. The agent uses that description when planning a task, without needing to know the service’s internal implementation. This gives the platform a clear separation between the agent that decides which capability is relevant and the service that performs the work.
A common interface for different implementations
Some services are web APIs that call parameterized prompts. Others connect to business systems through their APIs. To the agent, both appear as declared actions with a defined purpose and parameters. These are capabilities that can be configured, not a claim that every connector is present by default.
Reuse expertise across agents
A carefully designed service can support several roles while remaining centrally maintained. Business logic and prompt design evolve behind a stable interface. Integration teams work on implementation; teams configuring agents decide which capabilities each role needs.
The repository principle
Describe the capability
Expose its parameters
Keep implementation behind the interface
Service contracts
The agent knows what. The service handles how.
Available actions are the contract between planning and implementation.
A service contract makes a capability understandable to the agent. It identifies the action’s purpose, the information needed to call it and the kind of result expected. The planner can then select a suitable action and supply the relevant parameters. Behind that interface, the service may perform a prompt-based transformation, query an application or combine application logic with AI. Those details stay within the service boundary.
An example: preparing a structured draft
Imagine an action that prepares a response from supplied context. Its inputs could include the request, supporting policy text, intended audience and requested language. A web API uses a maintained prompt to produce the result. The agent needs the action definition, not the hidden prompt.
Change the implementation deliberately
A team can improve the underlying prompt or adapt an integration while keeping the action’s purpose clear. Changes to required inputs or returned results are changes to the contract and should be tested with affected tasks.

