--- title: "Can an AI Agent Use Your Product, or Only Read About It?" canonical: https://wavect.io/blog/can-an-ai-agent-use-your-product/ language: en description: "What it takes to make a product agent-usable rather than only agent-readable: delegated identity, data-level authorization, idempotency, error semantics, MCP and agent skills." image: "https://wavect.io/img/blog/headers/header_can-an-ai-agent-use-your-product.png" --- [**Back**](/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/team/kevin-riedl/) [Kevin Riedl](/team/kevin-riedl/) https://linkedin.com/in/wsdt 8 min read · 18 Aug 2026 Last reviewed August 18, 2026 [**Next**](/blog/agent-readable-website-llms-txt-markdown-mirrors/) # Can an AI Agent Use Your Product, or Only Read About It? TL;DR Being readable by an agent and being usable by one are separate projects, and most teams have only done the first. Readable means an assistant can fetch, parse, quote and attribute you. Usable means it can authenticate as a specific user, call a tool, change state, and be refused when it should be. The second is mostly an authorization, identity and error-semantics problem rather than a model problem, and it is paced by how precisely you can say no, because a readability bug costs a citation while an authorization bug costs an incident. A usable tool surface needs five things: delegated identity that expresses which agent acts for which user in which scope, authorization enforced at the data layer rather than in the prompt, idempotency keys because agents retry on timeouts they misread, error messages that name the failing field so a model corrects instead of looping, and discovery through MCP and published agent skills. MCP is the transport and not the authorization model; treating it as one is the common mistake. A defensible sequence is read-only tools, then a published map, then one low-risk write behind human approval, then widening only where the audit log shows consistently correct behaviour. Nobody can currently quantify revenue arriving through agents, so the case for the early steps rests on them being cheap and useful to human integrations regardless. **Being readable by an agent and being usable by one are different projects, and almost every team has only done the first.** Readable means an assistant can summarise and cite you. Usable means it can complete a task on your product on behalf of a named user, and be stopped when it should be. The second one is mostly not a model problem. It is an authorization, identity and error-semantics problem, which is why it lands with engineering rather than marketing. ## Two different questions | | Readable | Usable | | --- | --- | --- | | What the agent does | Fetches, parses, quotes, attributes | Authenticates, calls, changes state, reports back | | Surface | HTML, Markdown mirror, llms.txt, JSON-LD | Tools with schemas, identity, permissions, audit | | Failure | You are absent from the answer | Something happens that should not have | | Cost of getting it wrong | Lost attention | Lost data, money or trust | That last row is the reason the second column takes longer. A readability bug costs you a citation. An authorization bug costs you an incident, so the work is paced by how confidently you can say no. If the first column is not done yet, start there. Our [guide to agent-readable websites](/blog/agent-readable-website-llms-txt-markdown-mirrors/) covers it, and it is a fraction of the effort. ## What "usable" actually requires A tool surface an agent can operate needs five things, and the interesting ones are not the API. - **Identity that is not the agent's.** The agent acts for a user or a tenant. If your tokens cannot express "this agent, on behalf of this person, for this scope, until this time", every call is effectively an admin call. - **Authorization at the data layer.** Filtering in the prompt is not access control. The boundary belongs where the query runs, so a persuasive instruction cannot widen it. - **Idempotency.** Agents retry. They retry on timeouts they misread, and on partial responses they did not understand. Any state-changing call needs a key that makes the second attempt a no-op. - **Error semantics a model can act on.** A 400 that says "invalid request" produces a retry loop. One that says which field failed and what shape it wanted produces a corrected call. This is documentation as a control surface. - **Discovery.** Something has to tell the agent the tools exist, what they cost, and what they are for. That is what MCP and published agent skills do. ## Where MCP fits, and where it does not MCP gives you a standard way to expose tools and resources to a model, and it is the right transport. It is not an authorization model, and treating it as one is the most common mistake in this area. The protocol carries your decisions; it does not make them. The design questions underneath it are the familiar ones. Which tenant is this call for. Which of that tenant's records may this scope see. Who approves a write. What gets logged so an incident can be reconstructed. We have written both halves up in detail: [enterprise MCP authorization architecture](/blog/enterprise-mcp-authorization-architecture/) for the multi-tenant reference design, and [MCP security boundaries](/blog/mcp-security-boundary-data-level-access-control/) for why data-level enforcement is the only enforcement that holds. Agent skills sit above the tools as the instruction layer: when to use which tool, what the house rules are, what never to do. Tools without skills get used wrongly; skills without tools are advice. We publish ours as static files with checksums, so anyone can read what our agents are told. ## A staging that does not require faith You do not need to believe agent traffic will be large to justify the first two steps, because they are cheap and they pay off for humans too. 1. **Read-only tools first.** Search, lookup, status. No writes, no approvals to design, and it exercises identity and rate limits under real conditions. 2. **Publish the map.** An MCP endpoint plus skills that describe the tools honestly, including what they will refuse. 3. **One write, behind approval.** Pick the least dangerous state change, add idempotency keys, and put a human confirmation in front of it. Log everything. 4. **Widen by evidence.** Remove the approval gate only for operations where the log shows the agent has been right consistently, and keep the gate everywhere else. Steps one and two are a few days of work on a well-factored API and they are useful immediately, because the same schemas and error messages make your own integrations easier. Step three is where the real design work is. ## The honest part Nobody can tell you today how much revenue arrives through agents. Anyone quoting you a figure is guessing, and we are not going to guess for you. What is defensible is the shape of the bet. The read-only surface is cheap, the standards are converging, and the work is not wasted if agent traffic stays small, because typed tools, real authorization boundaries and machine-legible errors are things a mature API should have anyway. What we would not do is rebuild a product around a channel that has not proven itself. Start with the part that is useful either way. ## Frequently Asked Questions ### What is the difference between an agent-readable and an agent-usable product? Readable means an assistant can fetch, parse, quote and attribute your content. Usable means it can authenticate as a specific user, call a tool, change state and be refused when it should be. The first is a publishing problem, the second is an authorization and identity problem. ### Is an MCP server enough to make a product agent-usable? No. MCP is the transport for exposing tools and resources; it carries your authorization decisions rather than making them. Tenant scoping, data-level permissions, approval for writes and audit logging all have to exist behind it. ### Why do agents need idempotency keys? Because agents retry, including on timeouts they misread and partial responses they did not understand. Without a key that makes the second attempt a no-op, a retry becomes a duplicate order, message or charge. ### Can we just expose our existing REST API? Often, with two changes. Errors need to say which field failed and what was expected, so a model can correct itself instead of looping. And scopes need to express an agent acting on behalf of a user, rather than a single key with everything enabled. ### Should agents be allowed to write to production? Eventually, and narrowly. Start read-only, then put one low-risk write behind human approval with idempotency and full logging, and remove the gate only where the log shows a consistent record of correct behaviour. ### Is it too early to invest in this? For a full rebuild, yes. For read-only tools and published skills, no, because typed tools, real authorization boundaries and machine-legible errors improve your own integrations whether or not agent traffic grows. ## Final thoughts Readable is a publishing problem and it is nearly solved by generating clean copies and letting the right fetchers in. Usable is an engineering problem, and it is gated by how precisely you can say no. Do the read-only surface because it pays off regardless. Then design the write path around identity, data-level authorization, idempotency and audit, and widen it on evidence rather than on optimism. ## You may also like.. [**Enterprise MCP Authorization Architecture** A vendor-neutral multi-tenant reference design for exposing tools to agents without widening the blast radius.](/blog/enterprise-mcp-authorization-architecture/) [**AI enablement vs an in-house AI hire** When to buy the capability and when to hire it, with the honest break-even.](/compare/ai-enablement-vs-in-house-ai-hire/) Agent engineering ## Continue through this cluster Coding agents, MCP, context systems, evaluation and the controls required for dependable automation. [Start with the cornerstone**Graph Engineering for AI Agents: When Does a Knowledge Graph Pay Off?**](/blog/graph-engineering-ai-agents/) - [Agent-Readable Websites: llms.txt, Markdown Mirrors and What Breaks](/blog/agent-readable-website-llms-txt-markdown-mirrors/) - [Localized URLs Break hreflang: Keep One English Slug](/blog/english-slugs-vs-localized-urls-hreflang/) - [Graft Review 2026: Do Agent Repo Maps Belong in Git?](/blog/graft-review-agent-repo-map/) - [How Coding Agents Keep Token Bills in Check with Output Compression](/blog/codag-cost-control/) - [Smarter Token Usage with Your AI Coding Agent](/blog/smarter-token-usage-with-your-ai-coding-agent/) Inbox, without the noise ## Follow the work that matters to you Get a short email when we publish something new. Follow the whole blog or only the problems you care about. [**Back**](/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/team/kevin-riedl/) [Kevin Riedl](/team/kevin-riedl/) https://linkedin.com/in/wsdt 8 min read · 18 Aug 2026 Last reviewed August 18, 2026 [**Next**](/blog/agent-readable-website-llms-txt-markdown-mirrors/) New posts by email × × Get new posts by email A short email when we publish. Free, no tracking. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/blog/can-an-ai-agent-use-your-product/#webpage", "@type": "WebPage", "dateModified": "2026-08-18", "inLanguage": "en", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-08-18", "url": "https://wavect.io/blog/can-an-ai-agent-use-your-product/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "Being readable by an agent and being usable by one are separate projects, and most teams have only done the first. Readable means an assistant can fetch, parse, quote and attribute you. Usable means it can authenticate as a specific user, call a tool, change state, and be refused when it should be. The second is mostly an authorization, identity and error-semantics problem rather than a model problem, and it is paced by how precisely you can say no, because a readability bug costs a citation while an authorization bug costs an incident. A usable tool surface needs five things: delegated identity that expresses which agent acts for which user in which scope, authorization enforced at the data layer rather than in the prompt, idempotency keys because agents retry on timeouts they misread, error messages that name the failing field so a model corrects instead of looping, and discovery through MCP and published agent skills. MCP is the transport and not the authorization model; treating it as one is the common mistake. A defensible sequence is read-only tools, then a published map, then one low-risk write behind human approval, then widening only where the audit log shows consistently correct behaviour. Nobody can currently quantify revenue arriving through agents, so the case for the early steps rests on them being cheap and useful to human integrations regardless.", "articleBody": " Blog overview/AI and agents/Agent engineering Can an AI Agent Use Your Product, or Only Read About It? TL;DR Being readable by an agent and being usable by one are separate projects, and most teams have only done the first. Readable means an assistant can fetch, parse, quote and attribute you. Usable means it can authenticate as a specific user, call a tool, change state, and be refused when it should be. The second is mostly an authorization, identity and error-semantics problem rather than a model problem, and it is paced by how precisely you can say no, because a readability bug costs a citation while an authorization bug costs an incident. A usable tool surface needs five things: delegated identity that expresses which agent acts for which user in which scope, authorization enforced at the data layer rather than in the prompt, idempotency keys because agents retry on timeouts they misread, error messages that name the failing field so a model corrects instead of looping, and discovery through MCP and published agent skills. MCP is the transport and not the authorization model; treating it as one is the common mistake. A defensible sequence is read-only tools, then a published map, then one low-risk write behind human approval, then widening only where the audit log shows consistently correct behaviour. Nobody can currently quantify revenue arriving through agents, so the case for the early steps rests on them being cheap and useful to human integrations regardless. Being readable by an agent and being usable by one are different projects, and almost every team has only done the first. Readable means an assistant can summarise and cite you. Usable means it can complete a task on your product on behalf of a named user, and be stopped when it should be. The second one is mostly not a model problem. It is an authorization, identity and error-semantics problem, which is why it lands with engineering rather than marketing. Two different questions ReadableUsable What the agent doesFetches, parses, quotes, attributesAuthenticates, calls, changes state, reports back SurfaceHTML, Markdown mirror, llms.txt, JSON-LDTools with schemas, identity, permissions, audit FailureYou are absent from the answerSomething happens that should not have Cost of getting it wrongLost attentionLost data, money or trust That last row is the reason the second column takes longer. A readability bug costs you a citation. An authorization bug costs you an incident, so the work is paced by how confidently you can say no. If the first column is not done yet, start there. Our guide to agent-readable websites covers it, and it is a fraction of the effort. What \"usable\" actually requires A tool surface an agent can operate needs five things, and the interesting ones are not the API. Identity that is not the agent's. The agent acts for a user or a tenant. If your tokens cannot express \"this agent, on behalf of this person, for this scope, until this time\", every call is effectively an admin call. Authorization at the data layer. Filtering in the prompt is not access control. The boundary belongs where the query runs, so a persuasive instruction cannot widen it. Idempotency. Agents retry. They retry on timeouts they misread, and on partial responses they did not understand. Any state-changing call needs a key that makes the second attempt a no-op. Error semantics a model can act on. A 400 that says \"invalid request\" produces a retry loop. One that says which field failed and what shape it wanted produces a corrected call. This is documentation as a control surface. Discovery. Something has to tell the agent the tools exist, what they cost, and what they are for. That is what MCP and published agent skills do. Where MCP fits, and where it does not MCP gives you a standard way to expose tools and resources to a model, and it is the right transport. It is not an authorization model, and treating it as one is the most common mistake in this area. The protocol carries your decisions; it does not make them. The design questions underneath it are the familiar ones. Which tenant is this call for. Which of that tenant's records may this scope see. Who approves a write. What gets logged so an incident can be reconstructed. We have written both halves up in detail: enterprise MCP authorization architecture for the multi-tenant reference design, and MCP security boundaries for why data-level enforcement is the only enforcement that holds. Agent skills sit above the tools as the instruction layer: when to use which tool, what the house rules are, what never to do. Tools without skills get used wrongly; skills without tools are advice. We publish ours as static files with checksums, so anyone can read what our agents are told. A staging that does not require faith You do not need to believe agent traffic will be large to justify the first two steps, because they are cheap and they pay off for humans too. Read-only tools first. Search, lookup, status. No", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "dateModified": "2026-08-18", "datePublished": "2026-08-18", "description": "Being readable by an agent and being usable by one are separate projects, and most teams have only done the first. Readable means an assistant can fetch, parse, quote and attribute you. Usable means it can authenticate as a specific user, call a tool, change state, and be refused when it should be. The second is mostly an authorization, identity and error-semantics problem rather than a model problem, and it is paced by how precisely you can say no, because a readability bug costs a citation while an authorization bug costs an incident. A usable tool surface needs five things: delegated identity that expresses which agent acts for which user in which scope, authorization enforced at the data layer rather than in the prompt, idempotency keys because agents retry on timeouts they misread, error messages that name the failing field so a model corrects instead of looping, and discovery through MCP and published agent skills. MCP is the transport and not the authorization model; treating it as one is the common mistake. A defensible sequence is read-only tools, then a published map, then one low-risk write behind human approval, then widening only where the audit log shows consistently correct behaviour. Nobody can currently quantify revenue arriving through agents, so the case for the early steps rests on them being cheap and useful to human integrations regardless.", "headline": "Can an AI Agent Use Your Product, or Only Read About It?", "image": "https://wavect.io/img/blog/headers/header_can-an-ai-agent-use-your-product.svg", "inLanguage": "en", "keywords": "AI Visibility, MCP", "mainEntityOfPage": { "@id": "https://wavect.io/blog/can-an-ai-agent-use-your-product/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/blog/can-an-ai-agent-use-your-product/", "wordCount": 1686 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/", "name": "Home", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/blog/overview/", "name": "Blog overview", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/blog/topics/ai-agents/", "name": "AI and agents", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/blog/clusters/agent-engineering/", "name": "Agent engineering", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/blog/can-an-ai-agent-use-your-product/", "name": "Can an AI Agent Use Your Product, or Only Read About It? | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Readable means an assistant can fetch, parse, quote and attribute your content. Usable means it can authenticate as a specific user, call a tool, change state and be refused when it should be. The first is a publishing problem, the second is an authorization and identity problem." }, "name": "What is the difference between an agent-readable and an agent-usable product?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "No. MCP is the transport for exposing tools and resources; it carries your authorization decisions rather than making them. Tenant scoping, data-level permissions, approval for writes and audit logging all have to exist behind it." }, "name": "Is an MCP server enough to make a product agent-usable?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Because agents retry, including on timeouts they misread and partial responses they did not understand. Without a key that makes the second attempt a no-op, a retry becomes a duplicate order, message or charge." }, "name": "Why do agents need idempotency keys?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Often, with two changes. Errors need to say which field failed and what was expected, so a model can correct itself instead of looping. And scopes need to express an agent acting on behalf of a user, rather than a single key with everything enabled." }, "name": "Can we just expose our existing REST API?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Eventually, and narrowly. Start read-only, then put one low-risk write behind human approval with idempotency and full logging, and remove the gate only where the log shows a consistent record of correct behaviour." }, "name": "Should agents be allowed to write to production?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "For a full rebuild, yes. For read-only tools and published skills, no, because typed tools, real authorization boundaries and machine-legible errors improve your own integrations whether or not agent traffic grows." }, "name": "Is it too early to invest in this?" } ] } ```