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.
Illustrative action contract

Inputs: request and context

Service: parameterized prompt API

Output: draft for review

    📅

    Book Your Demo

    Fill out the form and we'll get back to you as soon as possible.


    🔒 Your data is safe and will never be shared.