Service catalog for AI agents: Data model and 90-day plan

A service catalog for AI agents is a versioned, machine-readable list of bookable or requestable services, including terms and conditions and permitted actions. The catalog describes what your business offers, the applicable pricing logic, where the service is available, and the limits within which AI agents are allowed to operate.

For an SME, the benefit arises from a reliable source of information: your team, website, search engines, internal systems, and digital assistants all access the same shared data. This transforms scattered website texts into machine-readable services that can be clearly selected, requested, and later booked.

An agent service catalog transforms a service description into a controllable offer: clearly identified, professionally reviewed, up-to-date, and usable only within defined limits.

What a service catalog for AI agents must be able to do

A traditional service page should inform people and help them make a decision. A machine-readable service catalog must additionally provide clear answers: What service is meant? Where is the service offered? What does it cost? What information is missing for a request? Should an AI agent only provide information or also be allowed to initiate a reservation?

A person can often tell from the context that "consulting from €120" likely refers to an hourly rate. A system needs clear information about the unit, currency, validity period, and any possible deviations. If this information is missing, the AI ​​agent must neither guess nor suggest a supposedly appropriate price.

A good service catalog fulfills four tasks:

• Identify: Each service has a stable service ID, making it unique across languages, channels, and versions.
• Describe: Content, benefits, prerequisites, scope of services and duration are structured and documented.
• Limit: Permitted actions, permissions, and necessary confirmations are explicitly defined.
• To update: Status, version, release, and update date indicate which information may be used.

Knowledge Catalog and Service Catalog are not the same thing

A knowledge catalog manages comprehensive company knowledge. This can include process descriptions, internal documents, experiential knowledge, guidelines, responsibilities, data sources, and confidential information. A knowledge catalog helps your company make knowledge findable, traceable, and controllable.

The service catalog is a deliberately limited publication layer. It only includes verified information from internal knowledge that is necessary for selection, inquiry, availability check, or booking. Internal calculations, personal notes, unapproved prices, and confidential work instructions do not belong in this publication layer.

The transition should not be done by simply copying. A mandatory approval process exists between the Knowledge Catalog and the Service Catalog.

• The service owner confirms content, scope, and operational feasibility.
• The editorial team checks for comprehensibility, language, and consistency.
• Data protection and organization review required input and its purpose.
• The technology validates data format, mandatory fields, and action limits.
• A designated person grants professional approval for publication.

This makes the released catalog the single source of truth for published performance data. Our 30-day starter plan for a single source of truth shows you how to build such a binding data source step by step.

The data model for machine-readable performance

A usable data model must be small enough for everyday business use and precise enough for automated processes. From my work with SMEs, I know the temptation to map every exception from the outset. This often leads to an overloaded system that isn't reliably maintained in daily use. A better approach is a consistent core with clearly defined fields that can be added.

Identity and description

• Performance ID: A permanently stable identifier, for example "PHOTO-BUSINESS-001". The ID does not change if the name or translation is modified.
• Name: The understandable description of the service in the respective language.
• Description: A brief, factual explanation of content, result and scope.
• Language: The language version of the content, for example de, it or en.

Terms and conditions

• Pricing logic: Fixed price, starting price, price range, unit price, individual calculation or not public.
• Currency: For example, EUR. The currency must not be derived solely from the location.
• Area of ​​expertise: The region, specific locations, a radius, or the indication that the service is available digitally or on-site.
• Duration: The typical execution time, a range, or the indication that the duration will only be determined after review.
• Requirements: Conditions that must be met before request, execution or booking.
• Availability: The current status or a defined method for checking available capacity.
• Required fields: The information required for a qualified inquiry.

Control and maintenance

• Permitted actions: Inform yourself, check availability, prepare your request, send your request, reserve or make a binding booking.
• Status: Draft, under review, approved, paused, withdrawn or archived.
• A traceable version number for changes and retractions.
• Update date: The date of the last technically approved change.

Example of a fictitious SME service

The following example shows a fictitious service from business photography. The data is deliberately kept simple and does not include actual prices or partner information.

{
  "service_id": "PHOTO-BUSINESS-001",
  "language": "de",
  "name": "Business-Fotoshooting vor Ort",
  "description": "Fotoproduktion für Team, Arbeitsumgebung und Unternehmenskommunikation.",
  "pricing": {
    "type": "individual_quote",
    "currency": "EUR",
    "public_price": false
  },
  "service_area": {
    "type": "region",
    "value": ["Südtirol"],
    "travel_costs_may_apply": true
  },
  "duration": {
    "type": "range",
    "minimum": 2,
    "maximum": 8,
    "unit": "hours"
  },
  "requirements": [
    "Abgestimmtes Briefing",
    "Zugang zu den Aufnahmeorten",
    "Benannte Kontaktperson am Produktionstag"
  ],
  "availability": {
    "type": "request_required",
    "live_check": false
  },
  "required_inputs": [
    "Unternehmen",
    "gewünschter Einsatzbereich der Bilder",
    "Aufnahmeort",
    "gewünschter Zeitraum",
    "Anzahl der zu fotografierenden Personen"
  ],
  "allowed_actions": [
    "read",
    "prepare_request",
    "submit_request"
  ],
  "human_confirmation": {
    "required_for_reservation": true,
    "required_for_booking": true
  },
  "status": "approved",
  "version": "1.2",
  "updated_at": "2026-04-15"
}

The service ID links all language versions to the same service. The pricing logic "individual_quote" explicitly states that no publicly available price is given. Therefore, the AI ​​agent may request a quote, but not calculate a price.

The service area limits the geographical scope. The duration is given as a range, not a guarantee. These requirements help prevent incomplete requests. The required information is limited to what is necessary. Permitted actions end upon submitting a request; reservations and bookings require human confirmation.

Pricing logic: What an AI agent is allowed to say

Price information is only unambiguous for AI agents if the reference point and validity are clearly defined. Many websites use phrases like "from," "depending on effort," or "price on request" without clarifying what the wording refers to. Therefore, for a machine-readable catalog, every pricing logic must be explicitly defined.

• Fixed price: The defined scope of services has a binding price. Additional services must be described separately.
• Starting price: The stated amount is the minimum. The catalog must explain which factors affect the final price.
• Price range: The minimum and maximum values ​​apply within a defined framework. Outside of this framework, an individual assessment is necessary.
• Unit price: The price is per hour, piece, person, night, square meter or any other clearly named unit.
• Individual calculation: A price will only be determined after the required information has been verified.
• Not public: The price is available internally, but may not be displayed publicly or automatically.

If an approved price is missing, the AI ​​agent must either ask for it or hand the process over to a human. An unapproved or calculated fictitious price must not be displayed.

Pricing rules also require an expiry date and a responsible person. For seasonal services, fluctuations in raw material costs, or highly variable expenses, a short review period may be more sensible than an open-ended price specification.

From "reading" to "booking": permitted actions are tiered.

Machine readability does not automatically grant freedom of action. An AI agent can read a service description without being authorized to submit a request. Similarly, a prepared request is not yet a reservation or a binding booking.

For SMEs, I recommend a phased action model:

• 1. Read: The AI ​​agent is permitted to repeat approved names, descriptions, terms and conditions, and pricing information. Human confirmation is not required.
• 2. Check availability: The AI ​​agent is permitted to query a shared calendar or inventory. This check is non-binding and will be logged.
• 3. Prepare the request: The AI ​​agent gathers the necessary input and creates a draft. A human reviews the draft before it is submitted.
• 4. Submit request: The AI ​​agent transmits the information only after explicit consent. The company then confirms receipt, but not automatically that the information has been processed.
• 5. Make a reservation: The AI ​​agent temporarily blocks a capacity. The reservation duration, expiry date, and the identity of the requesting person must be clearly defined.
• 6. Book now: The AI ​​agent triggers a legally and economically relevant action. Identity, price, scope, payment or cancellation terms, and human confirmation must be defined in advance.

Each action level requires its own authorization. A blanket field like "bookable: yes" is too imprecise. Separate permissions, logged requests, defined error cases, and human escalation as soon as information is missing or rules are contradictory are more sensible.

We describe the further development from request to transaction in more detail in the article about booking by AI agents.

Before and after: a typical South Tyrolean SME

A pattern I frequently encounter in my work with owner-managed businesses is a service provider with multiple service pages in German and Italian. Some prices are listed on the website, others only in PDF documents. Service areas are sometimes specified as "South Tyrol," sometimes as "Bolzano and surrounding area," and sometimes not at all.

If an English version is added later, it sometimes describes an older version. The following example summarizes this recurring pattern and does not refer to a single partner company.

Before structuring

• Services do not have permanent IDs.
• Prices and scope of services are detailed in several documents.
• Translations are maintained as independent texts.
• Requests often arrive without specifying a timeframe, location, or required scope.
• The website and internal offer templates contradict each other in places.
• A digital assistant can read content, but cannot make reliable choices.

After the structuring

• Each service has a language-independent service ID.
• Pricing logic, duration, service area and requirements are centrally available.
• German, Italian and English all access the same technical data set.
• Language-dependent texts and local conditions are maintained separately, but in a linked manner.
• A request only requires the inputs defined for the service.
• The AI ​​agent recognizes whether it is allowed to inform, check, or prepare a request.
• Changes include version, date, responsible party, and release status.

The crucial advancement is operational clarity. The company knows definitively which information is up-to-date and which channels it is authorized to use. Automation thus becomes a consequence of good organization, not a replacement for it.

Multilingual service catalog for South Tyrol

A multilingual service catalog should not consist of three separate databases. Independently maintained records increase the risk of differing prices, outdated requirements, and conflicting service areas.

The stable performance ID therefore remains the same in all languages. The name, description, notes, and user-related selection fields are translated. Currency, status, version, and technical action rights are managed centrally, unless there is a justifiable local deviation.

The catalog should save the translation status with every change:

• News: The language version corresponds to the released original version.
• Translation required: The technical content has been changed.
• Under review: The translation is complete, but has not yet been released.
• Do not publish: The language version is incomplete or contradictory.

Local conditions may differ, but must be explicitly modeled. If a service is only offered in certain regions, this deviation belongs in the service area description and not solely in a body of text.

The approval process from draft to withdrawal

A service catalog needs a defined lifecycle. Without a status model, a withdrawn offering can remain accessible via an interface or be imported from an old dataset by an AI agent.

Recording and testing

• Draft: The performance is recorded, but may not yet be published.
• Professional examination: Service owners check scope, pricing logic, requirements, and availability.
• Language test: The editorial team and translators check for understandable and consistent versions.
• Technical validation: Required fields, formats, IDs, links and allowed actions are tested.

Release and publication

• Release: A responsible person approves a specific version.
• Publication: Only the approved version will be output to websites, structured data, or interfaces.
• The change: Modifications create a new version, while the active version remains in place until release.

Pause and withdrawal

• Break: A service remains documented, but may not be requested or booked temporarily.
• Return policy: The service will be removed from active output. Existing processes and previous versions will remain traceable.

Versioning is not a technical triviality. The version documents the basis on which a request or reservation was made. Especially when prices, deadlines, or scopes of services have changed, the specific status must remain traceable.

Schema.org, interface and website output

An internal service catalog alone does not make a service publicly machine-readable. The released data must be made available via appropriate output channels: as an understandable website, via structured data, and, for more advanced applications, via a controlled interface.

Schema.org provides types such as "Service" and "Offer," as well as properties for pricing, currencies, and availability. This allows you to standardize the tagging of selected service and offer data. However, Schema.org does not automatically map your entire approval process, internal roles, or granular access rights. These rules must be defined in your own data model and process logic.

Structured data is only reliable if the content and technical output match. Our guide to validating JSON-LD and structured data is suitable for this purpose.

The International Monetary Fund outlines several open approaches for agent-based transactions by 2026, including specifications for checkout processes and broader trading processes. These approaches differ in terms of task, security model, implementation, and maturity. Therefore, an SME should not completely tie its own performance model to a single emerging specification.

The stable part of the architecture consists of its own, verified performance data. Technical protocols can be added or exchanged later as an additional interface layer.

btlabs Core as a possible technical foundation

btlabs Core can serve as a central content repository for a service catalog for AI agents. The platform is designed to supply websites, multilingual content, and machine-readable output from a single data source. This supports the principle of maintaining services once and delivering them in a controlled manner across multiple channels.

AI-powered booking agents are a technically advanced development stage and not a standard feature. Whether an AI agent is authorized to check availability, reserve, or book requires an individual process analysis, suitable interfaces, security rules, and a coordinated approval workflow.

Technology can create a well-organized system. However, it cannot decide which services are bindingly bookable, who approves price changes, or when a human must take over. This responsibility remains within the company.

90-day plan for the service catalog for AI agents

Days 1 to 30: Clarify inventory and responsibilities

• Inventory all active services from the website, PDFs, offers and internal documents.
• Mark duplicates, old names, and contradictory price information.
• Designate a professional service owner for each service.
• Establish a uniform scheme for performance IDs.
• Define mandatory fields and permissible pricing logics.
• Assign personnel responsibilities for editorial work, technology, data protection, and final approval.
• Start with five to ten frequently requested services, instead of immediately trying to map the entire company.

Days 31 to 60: Maintaining data and setting limits

• Record the name, description, pricing logic, currency, service area, and duration.
• Define the prerequisites and required inputs for each service.
• Define allowed actions for each service individually.
• Document human confirmation, escalation, and error incidents.
• Link language versions with the same performance ID.
• Introduce a status model and versioning.
• Conduct the initial professional, linguistic, and technical examination.

Days 61 to 90: Publish and test

• Only output approved data records to the website.
• Provide relevant information as structured data.
• Conduct test requests for different languages, locations, and pricing logics.
• Check if missing entries are detected and clearly requested.
• Ensure that the AI ​​agent reliably rejects unauthorized actions.
• Testing returns, pauses, and price changes as real-world scenarios.
• Establish a regular review interval and define who is responsible for updates.

Quality check for an agent service catalog

Data quality

• Does every active power have a unique and stable power ID?
• Is the pricing logic explicitly stated?
• Are the scope of services, duration, and requirements clearly defined?
• Are the required inputs limited to the necessary extent?

Controller

• Are permitted actions defined individually for each service?
• Is it clear when human confirmation is required?
• Can a service be paused or completely withdrawn?
• Are inquiries, reservations, and binding bookings clearly distinguished?

Care and issue

• Do all language versions refer to the same technical dataset?
• Does each release have a status, version, and update date?
• Are changes reviewed by experts before they are published?
• Do the website, structured data, and interface content-wise match?

Questions and answers about the service catalog

What are the minimum fields required in a service catalog for AI agents?

At a minimum, the following information is required: service ID, name, description, pricing logic, currency, service area, prerequisites, required input, allowed actions, language, status, version, and update date. Availability and duration may be marked as "pending review," but should not be omitted without explanation.

How do I handle dynamic or individual pricing?

Specify the pricing logic as a price range, unit price, or individual calculation, and define the factors required for a quote. An AI agent may only provide approved values ​​and must hand over the task to a human if the calculation basis is missing.

How often do performance data need to be updated?

The appropriate frequency depends on the variability of the performance. Seasonal availability may require daily checks, while stable descriptions can be checked quarterly. Crucially, a designated person responsible and a documented check date are essential.

Do the service catalog and website need to look identical?

No, but both versions must use the same core technical information. The website may present content in more detail and in a user-friendly way, while the machine-readable catalog translates the same information into unambiguous fields.

Does my SME need an API immediately?

No. To get started, centrally maintained performance data, consistent website output, and appropriate structured data are often sufficient. An API becomes relevant when external systems need to check current availability, submit requests, or trigger actions.

Is Schema.org sufficient for a complete agent service catalog?

Schema.org supports the standardized description of selected services, offers, prices, and availability. However, internal roles, approvals, versioning, granular access rights, and operational escalations require a supplementary, dedicated data and process model.

Who is liable for false statements made by an AI agent?

The specific legal responsibility depends on the use case, the systems involved, the declarations, and the contractual terms, and should be professionally reviewed. From an organizational perspective, you should limit any automated statements to approved data, log versions, and require human confirmation in cases of uncertainty.

What distinguishes an inquiry from a binding booking?

An inquiry conveys interest and basic information without automatically confirming the service. A binding booking requires a clear scope of services, price, availability, terms and conditions, identity verification, and the necessary consent.

How do I prevent conflicting language versions?

Use the same performance ID and a common core subject data set across German, Italian, and English. After each content change, affected translations receive a review status and are only published after approval.

Should an AI agent be allowed to collect personal data in response to a query?

Only data that is necessary for the specific purpose and has been approved by the organization should be requested. For each service, define which data is required, where it will be transferred, and when the process will be handed over to a human.

What happens if a service is no longer offered?

Set the service to paused or withdrawn and remove it from all active outputs. The previous version should remain traceable internally so that open requests and previous information can be correctly categorized.

What should a small business start with?

Start with five to ten frequently requested services and initially limit the allowed actions to reading and preparing the request. Once data quality, responsibility, and the approval process are functioning reliably, you can add availability checks or more advanced actions.

Conclusion: First clear performance data, then actions.

A service catalog for AI agents doesn't begin with a booking interface. It begins with the binding decision of which services your company offers, which terms and conditions apply, and who is responsible for the information.

When service IDs, pricing logic, service areas, prerequisites, required inputs, and permitted actions are properly maintained, a robust foundation is created. People receive clearer information, your team processes more complete requests, and AI agents can only act within the permitted boundaries.

For SMEs, this is the sensible way forward: fewer contradictions, transparent responsibility, and automation only where data and processes are reliably regulated.

Sources

1. Schema.org — Offer
2. International Monetary Fund — How Agentic AI Will Reshape Payments (2026)