Agent readiness doesn't mean your website is automatically registered with AI agents or enabled for actions. A machine-readable website can be discoverable and understandable. For controlled, operational use, where an AI agent is to retrieve data, send a request, or trigger a booking, a documented interface, a deliberately established connection, and controlled access permissions are also required.
For agent readiness in SMEs, this distinction is crucial: discoverability, technical access, and authorization to act are three distinct maturity levels. Mixing these levels quickly leads to investing in individual files or tools without establishing a commercially viable process.
Being discoverable is no guarantee of selection. Documentation is not registration. Technical accessibility is no authorization to act.
What constitutes agent readiness?
A website or digital interface is agent-ready when an AI agent can find, clearly understand, technically retrieve, and use relevant business information within defined permissions. Agent readiness therefore encompasses more than search engine optimization or a single description file.
In my work with small and medium-sized businesses, I repeatedly encounter the same bottleneck: The technology is fundamentally available, but services are unclearly described, data contradicts itself, or no one knows who authorizes prices, opening hours, and access rights. An additional file format does not solve this organizational problem.
A robust agent readiness is created from five levels:
- Clear achievements: An agent needs to understand what your business offers, who the offer is intended for, and what the requirements are.
- Machine-readable content: Information must be structured, unambiguous, and accessible via stable URLs.
- Technical interfaces: For an agent to act, it needs a documented API endpoint or a connected MCP server.
- Rights and security: Authentication and authorization must define who is allowed to access the system and perform which actions.
- Verifiable evidence: Requests, test calls, error responses and releases must be documented in a reproducible manner.
How does an AI agent find your interface?
Three key access routes are relevant for agent readiness: public content and links, an explicitly configured connection to an MCP server, and machine-readable descriptions such as OpenAPI, llms.txt, and agent descriptors. Each route has its own requirements and limitations.
Method 1: Public content via search engines and links
At the public level of agent readiness, discoverability begins with a technically accessible website. Search systems discover new URLs through various means, including previously known pages, internal and external links, and sitemaps. Google explicitly points out that even if these prerequisites are met, crawling, indexing, or display of results is not guaranteed ( Source: Google Search Central ).
The following points are particularly relevant for public discoverability:
- Requirement: Crawlability is ensured. Relevant pages are not accidentally blocked by robots.txt, meta-robots, login issues, or technical errors.
- Requirement: Indexability is ensured. Pages return a successful HTTP status, contain independent content, and use traceable canonical information.
- Requirement: Internal links lead to important services, locations, contact options and specialist information.
- Requirement: Service information specifies the target group, location, scope of services, requirements, and a clear next step.
- Requirement: Stable URLs remain accessible or are permanently redirected when changes occur.
- Verifiable proof: The URL is accessible without registration, is checked by an indexing tool, and is included in the sitemap and internal linking.
- Border: An indexed page does not need to appear in an AI response, nor does it need to be selected by a specific AI agent.
- Typical mistake: "If Google knows the page, every AI agent automatically knows its performance."
For SMEs, the public sector is usually the most sensible starting point. A clear website and content structure improves search engine optimization and helps people understand services more quickly.
Method 2: Explicitly established connection to an MCP server
The Model Context Protocol (MCP) is a technical standard that allows compatible applications to access external tools, resources, and prompts. An MCP server provides these functions. However, the server does not automatically register with all conceivable AI agents.
In the official MCP architecture, the host creates a separate MCP client for each connected server and maintains a connection to the server through this client ( source: Model Context Protocol ). In practice, this means that each client or host must consciously know about, connect to, and configure the MCP server.
For transactional agent readiness via MCP, the following requirements apply in particular:
- Requirement: An accessible and compatible MCP server provides clearly named tools, resources, or prompts.
- Requirement: The AI client used supports MCP and was connected to the relevant server.
- Requirement: Authentication and authorization are defined. The identity of a user or system must be verified before rights are granted.
- Requirement: Every tool has a limited purpose, traceable inputs, and controlled outputs.
- Verifiable proof: The server is reachable by the intended client, the capabilities are listed correctly, and a documented protocol test is successful.
- Verifiable proof: A test with missing or insufficient authorization will be rejected in a controlled manner.
- Border: An accessible MCP server does not automatically allow every action. Access permissions must be defined for each role, tool, and application.
- Typical mistake: "Once an MCP server is online, all AI assistants can access it."
The economically important question is therefore not primarily: "Do we need MCP?" The crucial question is: What clearly defined task should an agent perform, what data does the agent need for this, and who bears the responsibility? You can find a more in-depth analysis in my article about when an MCP server is worthwhile for SMEs.
Method 3: OpenAPI, llms.txt and agent descriptors
For agent readiness, description files from the technical documentation serve as a guide. Description files can make content or interfaces more understandable, but they do not effect automatic registration or grant access.
An OpenAPI description documents an HTTP interface, its operations, inputs, responses, and possible security schemes. However, the OpenAPI specification itself does not assign any access credentials or permissions ( Source: OpenAPI Specification ).
- Requirement: The OpenAPI file corresponds to the actual reachable API endpoint.
- Requirement: Parameters, mandatory fields, response formats, status codes and security requirements are fully described.
- Verifiable proof: The file can be validated and a test call provides the documented response.
- Border: OpenAPI describes how an interface can be used. OpenAPI does not decide who is allowed to use the interface.
- Typical mistake: "A published OpenAPI file unlocks the endpoint for AI agents."
The llms.txt file was published in 2024 as a voluntary proposal. Its purpose is to make selected information and further links on a website more easily accessible to language models. However, the proposal is not a general registration, authentication, or access standard ( source: llms.txt Proposal ).
- Requirement: The llms.txt file is publicly accessible, up-to-date, and links to relevant content.
- Verifiable proof: Access via the intended URL works and all linked resources are reachable.
- Border: No AI system is obliged to retrieve or consider the file.
- Typical mistake: "With an llms.txt file, my company is automatically registered in ChatGPT."
An agent descriptor or agent descriptor file can provide additional information about capabilities, endpoints, or usage requirements. Such a descriptor is also initially a machine-readable description. The agent descriptor does not replace the deliberate integration into a client or the verification of permissions.
A practical example from Bolzano
The following example illustrates agent readiness using a fictitious technical service provider from Bolzano that offers maintenance appointments for commercial clients. The company first wants to be found correctly and later enable selected business clients to submit appointment requests digitally.
1. Publicly describe the achievement
The service provider publishes a crawlable services page. This page lists maintenance types, areas of operation, target audience, necessary preliminary information, response times, and contact methods. The information is not only hidden in images or PDF files, but is available as structured HTML content.
Evidence: The service page is accessible without registration, internally linked, included in the sitemap and technically indexable.
2. Keep company data consistent
The company name, telephone number, area of operation, and service descriptions are consistent across the website, in directories, and in machine-readable data. The German and Italian versions use technically equivalent terms.
Evidence: An editorial review reveals no conflicting information between the service page, contact page, and structured data.
3. Document a limited API endpoint
For qualified requests, the company provides an API endpoint. Initially, this endpoint only accepts non-binding maintenance requests. The OpenAPI description defines mandatory fields such as device type, location, desired time window, and callback contact information.
Evidence: The OpenAPI file is valid. Successful and failed test calls produce documented status codes and understandable error responses.
4. Separate identity and rights
Authentication verifies which business customer or system is sending the request. Authorization then determines whether this identity is only allowed to read information, create a request, or view an existing process.
Proof: An authorized test account can send a request. An account without the appropriate role receives a controlled rejection and no access to internal data.
5. Configure the connection deliberately
If a specific AI client is to access the system via MCP, the MCP server is set up on the designated host. The client receives only the tools necessary for the agreed-upon process.
Evidence: The client recognizes the intended tool, sends a test call, and logs the result, time, and permission used.
6. Release actions in a controlled manner
Initially, the agent may only prepare a non-binding inquiry. A binding appointment booking remains a later development step and will only be activated once availability, cancellation, data protection, liability, and human oversight have been clarified.
Evidence: The permitted and prohibited actions are organizationally documented and technically enforced.
A small, secure process is more valuable to an SME than a large agent function whose data, responsibilities, and consequences are not reliably controlled by anyone.
Understanding Agent Experience for AI Agents
Agent readiness also includes agent experience for AI agents . In this article, the term refers to the technical and semantic user experience of an automated system: How easily can an AI agent find information, understand input, recognize permissions, process errors, and complete a permitted task?
The term here explicitly does not refer to the work experience of human service or support employees. For AI agents, a good agent experience primarily includes:
- unambiguous performance and field designations,
- predictable data formats,
- complete descriptions of inputs and outputs,
- understandable error responses,
- clearly identifiable authorization limits,
- stable endpoints and version information,
- Current content with verifiable sources.
A good agent experience reduces misinterpretations. However, it doesn't automatically make an AI agent trustworthy. Critical actions still require business rules, logging, and, if necessary, human approval.
Agent Readiness Checklist for SMEs
This agent readiness checklist allows you to check whether your website is only publicly readable or can already be used in a controlled manner by AI agents.
Content and services
- Are all important services clearly named and distinguished from one another?
- Are the target group, area of application, requirements and contact method listed directly on the respective service page?
- Are prices, availability, or conditions marked as binding, approximate, or to be clarified individually?
- Does the company data match across all language versions and channels?
- Is it defined who approves changes from a technical perspective?
Crawlability and indexability
- Are relevant pages accessible without registration, and is central content available in the delivered or rendered HTML?
- Are the pages returning successful HTTP status codes?
- Are important contents linked internally?
- Are the canonical tags, sitemap, robots.txt, and meta robots correctly configured?
- Do URLs remain stable, or are changes permanently redirected?
Machine-readable descriptions
- Is an existing llms.txt file up-to-date and does it point to relevant content?
- Does an agent descriptor accurately reflect the actual capabilities available to the agent?
- Is an OpenAPI file technically valid and up-to-date in terms of content?
- Do the documented fields, status codes, and examples match the production interface?
- Are there version numbers and a person responsible for updates?
Endpoints and tests
- Is every API endpoint reachable and uniquely assigned to a process?
- Are mandatory fields, limit values, and permissible formats documented?
- Are there test cases for successful, incomplete, and invalid requests?
- Do error responses provide an understandable cause without revealing sensitive system information?
- Are the test time, result, and version used logged?
Authentication and Authorization
- Can the system reliably verify the requesting identity?
- Are reading, writing, and action rights separate?
- Does the principle of minimum necessary authorization apply?
- Can access data be revoked and access traced?
- Who is authorized to approve a new campaign from an organizational and technical perspective?
Operational responsibility
- Is it clear who is responsible for content, interface, data protection and approvals?
- Is there a procedure for erroneous or abusive agent calls?
- Can a function be temporarily disabled?
- Is it defined when human review is required?
- Is the benefit assessed based on a concrete process rather than on uncertain bot traffic figures?
If you want to assess agent readiness, the result shouldn't be a simple, blanket score. A more meaningful approach is a measurement log including the URL, test case, expected result, actual result, responsibility, and next steps. Our AI Readiness Check considers these fundamentals from technical, content-related, and organizational perspectives.
What role does btlabs Core play?
btlabs Core is designed as a central content repository for websites and machine-readable corporate information. Its features include multilingual content, llms.txt, brand.json, a machine-readable interface, and the delivery of content as Markdown. This allows for the centralized maintenance of authoritative corporate information and its distribution across various output channels.
A central database supports agent readiness because services, locations, and contact information don't need to be maintained independently in multiple systems. You can find out more about this principle in the article " Structuring Company Knowledge with btlabs Core".
The distinction remains important: Booking agents, live appointments, orders, and other transactions are development stages . Such functions are not automatically part of the standard. Each development stage requires a defined process, a documented endpoint, an access control concept, and robust testing.
Build agent readiness in the correct order
For most SMEs, it makes economic sense to build up agent readiness gradually:
- First: Clarify services, target groups and responsibilities.
- Secondly: Make public content crawlable, indexable and consistent.
- Third: Add machine-readable descriptions and check them regularly.
- Fourth: Select a narrowly defined use case for an interface.
- Funftens: Test authentication, authorization, and error handling.
- Sixth: Only then should you enable selected actions for a connected AI agent.
This sequence protects against unnecessary complexity. People receive clear information, employees gain reliable processes, and AI agents only receive the access they need for a meaningful task. For me, that's a viable win-win-win situation.
Questions and answers about agent readiness
Is my website automatically registered with AI agents if it is machine-readable?
No. Machine-readable content facilitates understanding but does not automatically register with AI agents. Depending on the system, discovery occurs via public sources, search systems, links, or a deliberately configured connection.
What exactly does an llms.txt file achieve?
An llms.txt file can provide selected information and relevant links in a compact format for language models. This file does not replace good website content, crawlability, indexability, authentication, or technical access permissions.
Is OpenAPI sufficient for an AI agent to use my interface?
No. OpenAPI describes the structure and usage possibilities of an HTTP interface. An AI agent additionally requires access to the document, a suitable integration, valid login credentials, and the necessary authorization.
Does an MCP server need to be registered with an AI agent?
A compatible client or host must explicitly connect to or configure the MCP server. Simply deploying a server does not allow any AI agent to automatically discover and use it.
What is the difference between authentication and authorization?
Authentication verifies who or which system is making a request. Authorization then determines which data this identity is allowed to read and which actions it is permitted to perform.
Is an AI agent allowed to do everything that an API endpoint technically enables?
No. The technical function of an endpoint must be separated from access permissions. Rights, roles, limits, and, where applicable, human approvals must restrict the permitted actions.
What role do robots.txt and Meta-Robots play?
The robots.txt file can control the crawling of specific areas, while Meta-Robots provides instructions for individual pages. Both mechanisms are important, but neither guarantees indexing nor the use of a page by an AI agent.
What is particularly important from a data protection perspective?
An AI agent should only receive the data necessary for the specific process. Sensitive data requires a clear legal basis, limited access rights, secure transmission, logging, and regulated deletion periods.
What is the difference between reading and acting?
When reading, an AI agent retrieves publicly available or released information. When acting, the agent changes a state, for example by creating a request, a reservation, or an order. This requires stricter permissions and controls.
How can I recognize a reliable agent readiness?
Reliable agent readiness can be demonstrated through reproducible tests: accessible content, valid description files, successful and rejected API calls, and documented permissions. A single visibility test or a published file is insufficient proof.
Conclusion
Agent readiness encompasses discoverable content, machine-readable descriptions, controlled interfaces, and clearly defined permissions. OpenAPI, llms.txt, and agent descriptors facilitate technical orientation. An MCP server or API endpoint unlocks usage possibilities. Only authentication, authorization, testing, and documented responsibilities transform this into a responsible business process.
For SMEs, maximum automation is not the right goal. What matters is a limited, verifiable use case that reduces workload, provides reliable information, and does not create uncontrolled access rights. Robust agent readiness treats AI as a tool; responsibility remains with the company and the people who design the process.
