B2A with btlabs Core: Your website as an agent interface

For B2A, btlabs Core provides a central content base from which humans and AI agents can access consistent company information. This information base includes, for example, services, terms and conditions, and contact methods. However, the submission of inquiries, reservations, or orders by agents requires additional integrations. Therefore, the first step is a reliable knowledge base, not automated booking.

For over 20 years, I've worked in media, design, and digital implementation. As the founder of Berger+Team in Bolzano, I combine brand strategy with technical development. When working with SMEs, it's important to me that technology makes processes clearer and reduces the workload for your team. An additional interface is of little use if the underlying performance specifications remain contradictory.

B2A with btlabs Core: What does that mean for your business?

B2A stands for Business to Agent: Companies provide information and, where applicable, functions for AI agents that act on behalf of humans. An agent can compare providers, check terms and conditions, or prepare a request. Your offer must be clearly recognizable; decisions and responsibilities must remain clearly assigned.

The website as an agent interface combines two requirements: People need orientation and trust. Software needs clearly labeled information and defined courses of action. The general requirements are explained in the article on agent readiness for your website . This article focuses on B2A with btlabs Core.

A read interface provides information. An action interface enables defined processes. The technical service must separately verify the authorization to execute these processes.

From the central content base to the released action

The B2A implementation with btlabs Core can be divided into five steps:

1. Central content base: You maintain shared company information in one central location, instead of editing the same information multiple times.
2. Structured performance information: Services are given clear names, conditions, and limits.
3. Machine-readable provision: Software receives content in a processable form and does not have to infer performance requirements solely from the page layout.
4. Verification by an agent: An assigned agent can compare the information with their client's requirements. Missing information should lead to follow-up questions, not fabricated answers.
5. Released action: An additional, secure integration allows, for example, the submission of a request or a reservation.

SSOT: Which system is responsible for which information?

A Single Source of Truth (SSOT ) is the authoritative source for a specific piece of information. In B2A with btlabs Core, the system can assume this role for public service specifications. Available appointments can still be sourced from the resource planning system, and inventory levels from the inventory management system.

A central content repository should not replace specialized systems with uncontrolled copies. Therefore, for each piece of information, define the responsible system, the responsible person, the update procedure, and the procedure in case of failures.

B2A with btlabs Core: Foundation and additional expansion stages

The btlabs Core feature overview serves as a reference for the product foundation described here: centralized content management, German, Italian, and English support, a machine-readable interface, Markdown delivery, and discovery files. The specific features and output formats included in your offering should be explicitly documented.

• Central content management: A common foundation supports consistent output of released company information.
• Multilingualism: Shared maintenance facilitates the coordination of German, Italian, and English content. Professionally reviewed translations remain necessary.
• Machine-readable interface: Software can process provided content. This does not imply any authorization to create appointments or orders.
• Markdown delivery: A text-based version allows processing independent of the visual page layout. Markdown does not replace a data model for bookable services.
• Discovery files: Files such as llms.txt They can point to content. A JSON file containing brand information can provide supplementary structured information; the filename and schema must be agreed upon. Third-party AI systems do not necessarily take such files into account.

Machine readability does not guarantee a recommendation by ChatGPT or correct rendering by other AI systems. Changes to your content database also do not automatically update previously saved answers from third-party providers.

Three levels for project planning

• Core system: Centralized, multilingual content management and machine-readable provision form the basis of the information.
• Project-specific implementation: The service model, pricing, and system integrations are defined based on your business. A fully configured service catalog is not a standard requirement.
• Separate expansion stages: Live price calculators, appointment display, booking and other agent actions require additional implementation.

Therefore, for B2A with btlabs Core: An existing read interface does not occupy a ready-to-use booking function.

Service catalog, prices and availability must match

In B2A with btlabs Core, every service needs more than one name. Building a service catalog for AI agents begins with clear technical specifications and verifiable sources.

Specify at least the following for each service:

• Scope of services: What is included, what is excluded?
• Requirements: What information, documents, or preliminary checks do you need?
• Price conditions: Are fixed prices, starting prices, hourly rates, or individual offers applicable? Which taxes, units, and additional costs are relevant?
• Availability: Is the service generally available, or is there current capacity information available?
• Update status: When was the information verified, and who keeps the information up to date?
• Source system: Does the information come from the content database, a price list, or the deployment plan?

Static data is not live information.

Static prices require clear validity statements and conditions. Individual prices require a quotation process: An agent can gather information but may not issue a guideline price as a binding final price.

"Installation by arrangement" describes a condition, not a available date. Live information requires a connection to the responsible planning department. Before a binding reservation can be made, the target system must recheck and confirm availability.

If there is no current response, the process should report "Availability not currently confirmed" and offer a manual contact option. " Unknown" should not be displayed as available.

Approvals and audit log for trading agents

As soon as B2A with btlabs Core goes beyond reading, the process requires technical safeguards. The following points are requirements for additional integrations , not a guarantee of included standard features:

• permissions: Which agent is authorized to initiate which action for which client?
• Approvals: Which actions can be performed automatically, and which require confirmation?
• Action limits: Which services, time periods, or amounts are permitted?
• Repeat protection: How does the target system prevent duplicate reservations in repeated requests, for example through idempotence keys?
• Audit log: How are the time, executing identity, relevant inputs, release decision and result logged?

An audit log is a traceable record of events. Your team needs to be able to distinguish whether an action was requested, rejected, confirmed, or completed. Only store the necessary information and define access rights and deletion periods; complete conversations are not generally required.

The technical service checks rights and permissions – not just the language model. The separation of read and write permissions is explained in the article on permissions for AI agents.

Example: a carpentry workshop in the Bolzano area

This B2A example using btlabs Core is a constructed use case, not a documented customer case study. A small carpentry workshop offers custom-made furniture and repairs.

Initial situation: contradictory information

The German website describes repairs in detail, while the Italian site lists an older range of services. Directions are provided in a PDF file; the office provides further details by phone. Prospective customers inquire about prices without sending photos, measurements, or information about the service location.

First step: agreed-upon service descriptions

In the planned structure, services and terms and conditions will be managed centrally. For "furniture repair," the company defines the services offered, the required information, and the price calculation after verification. The language versions will be professionally coordinated.

A reading agent can thus prepare a more complete request, but receives neither a confirmed appointment nor a binding fixed price. The intended benefit lies in consistent information and fewer avoidable follow-up questions. A savings rate cannot be specified without measurement.

Later expansion stage: Appointment request

An additional integration could connect to the deployment planning system. A reservation will only be added once permissions, current availability, confirmation, and logging have been implemented and tested.

Implementing B2A step by step with btlabs Core

I would start with a small business offering a frequently requested service. A limited process is easier to test and justify than implementing several automations simultaneously.

1. Clarify information needs: Collect the questions your team needs to answer before making an offer.
2. Identify sources and responsible parties: For scope of services, prices and availability, specify a relevant source and a responsible person.
3. Standardize content: Eliminate inconsistencies between pages, language versions, and documents. Plan structured data based on actual customer questions.
4. Testing the reading interface: Check accessibility, completeness, and consistency with the visible website.
5. Release actions separately: Before commissioning, also test for rejections, missing data, retries, and system failures.

Measure the effectiveness of B2A with btlabs Core by analyzing the number of conflicting responses , the percentage of incomplete requests , and the number of successfully completed test scenarios . Document a baseline and then compare the same criteria over comparable time periods.

Frequently asked questions about B2A with btlabs Core

Do you need a new website for that?

Not necessarily. Depending on the architecture, B2A with btlabs Core can also complement an existing website. Whether an integration or a new build makes more sense depends on content management, data access, and maintainability.

What is included in the described product basis?

Centralized content management, German, Italian, and English, a machine-readable interface, Markdown delivery, and discovery files form the basis described here. Verify the scope of services offered in the specific proposal. Individual service catalogs, live availability, and binding agent actions must be assigned separately.

Can an agent book already?

B2A with btlabs Core does not automatically mean that bookings are possible. For that, you need an additional implementation or a connected booking system including permissions, availability checks, and confirmations.

How are individual prices handled?

Mark the service as requiring individual pricing and describe the necessary quote data. An agent may not issue a binding price without approved calculation logic and confirmed terms and conditions.

What happens if the availability is outdated?

The process must report outdated or unknown status and prevent a binding commitment. Before a reservation is made, the responsible system checks the capacity again. In case of outages, a defined manual contact method is available.

Who confirms binding actions?

You define this for each process: for example, the client before submitting and your company before confirming the appointment. Automatic confirmations require that the scope, permissions, and conditions are technically checked.

What ongoing expenses remain?

Even B2A with btlabs Core requires hosting, maintenance, security updates, content management, and translation review. Integrations need monitoring and adjustments when connected systems change. Plan responsibilities and operating costs from the outset.

First reliable information, then automatic actions

B2A with btlabs Core begins with a consistent information foundation. Agents must be able to categorize your offer and recognize where information ends and action begins. Further actions require separate integrations, approvals, and auditable processes.

At Berger+Team, we work as a collective of freelancers with a flexible network of experts in brand strategy, website development, and AI integration. In our strategic consulting, we can jointly define a service, its data sources, and a limited initial implementation phase.