Is Your Business Agent-Readable? Run This 5-Question Diagnostic in 10 Minutes

Your Business Has 10 Minutes to Find Out If Agents Can Use It

Most businesses assume they’re ready for AI agents because they have a website, an API, or a help doc somewhere. They’re not. And the gap between “we have data” and “an agent can act on our data” is where most agent commerce attempts quietly fail.

Nate Jones put together a 5-question diagnostic — records vs. content, state machine vs. labels, explicit ownership field, structural vs. conversational verbs, queryable vs. visible history — that cuts through the noise. You can run it on your own business in about 10 minutes. This post walks through each question with concrete examples so you know exactly what you’re looking for and what to do when the answer is “no.”

The stakes are real. Stripe’s agentic commerce suite — which broadcasts merchant inventory, pricing, and fulfillment logic directly into assistant surfaces — only works if your business data is structured enough for an agent to reason about. If it isn’t, you’re invisible to the buying agents that are already arriving.

---

Question 1: Do You Have Records or Content?

This is the first question, and it’s the one most businesses get wrong because the distinction feels subtle until you see it.

Content is prose. It’s your “About” page, your FAQ, your blog post explaining your return policy. Humans read it and infer meaning. It’s great for people.

Records are structured data. A product with a SKU, a price, an inventory count, a fulfillment window, a return policy expressed as a field with a value. An agent can query a record. An agent cannot reliably extract structured facts from prose — at least not without significant extra work that introduces error.

Here’s a concrete test: find your pricing page. Is your pricing a sentence like “Plans start at $29/month, with enterprise options available upon request”? That’s content. Or is it a table with plan names, prices, feature flags, and billing intervals? That’s closer to a record.

Now find your return policy. Is it a paragraph in your FAQ? Content. Is it a field in your product database that says return_window: 30 and return_condition: unopened? Record.

Stripe’s agentic commerce suite is built around the assumption that merchants can broadcast structured commercial data — inventory, price, payment readiness, fulfillment logic — into assistant surfaces. If your data lives in prose, it can’t be broadcast. It has to be scraped and interpreted, and that’s where agents make mistakes.

The fix isn’t complicated. Start by identifying the five most important facts an agent would need to transact with you: price, availability, delivery window, return policy, identity requirements. Then ask: are these queryable fields, or are they buried in copy? If you’re building agents that need to work across these kinds of data sources, MindStudio provides a visual builder with 200+ models and 1,000+ integrations for orchestrating agents and workflows against structured data — which makes the records-vs-content distinction immediately practical rather than theoretical.

---

Question 2: Is Your Status a State Machine or a Label?

An order can be “processing.” It can also be “in review,” “pending,” “almost ready,” or “we’re working on it.” Those last four are labels. They’re written for humans who will read them and feel reassured. They’re useless to an agent.

A state machine has a finite set of defined states with defined transitions. pending → processing → shipped → delivered → closed. Each state has a meaning. Each transition has a trigger. An agent can reason about a state machine: “the order is in shipped state, the estimated delivery is tomorrow, no action required.” An agent cannot reason reliably about a label: “we’re working on it” could mean anything.

This matters enormously for the kind of agent tasks that are already becoming common. Nate Jones’s framing is that agents will increasingly carry mandates — “buy this when the price drops,” “reorder when inventory falls below threshold,” “escalate if the ticket isn’t resolved in 24 hours.” Those mandates require the agent to check status and decide whether a condition is met. That only works if status is a state machine.

Look at your order management system, your support ticket system, your subscription billing system. What are the status values? Are they a clean enum, or are they a collection of human-written strings that accumulated over time? If your support tickets can be “open,” “in progress,” “waiting on customer,” “pending review,” “escalated,” “almost done,” and “closed,” you have a label problem.

The practical question: can you write a simple conditional against your status field? if status == 'shipped' should work. if status contains some variation of 'we sent it' should not exist.

This is also where the AutoResearch loop pattern becomes relevant — agents running iterative decision cycles against your data need clean state to avoid compounding errors across loops. A single ambiguous status value early in a workflow can cascade into wrong decisions downstream.

---

Question 3: Does Every Resource Have an Explicit Ownership Field?

This one is about trust and authorization, and it connects directly to the fraud problem that Stripe’s Radar announcement is trying to solve.

When an agent acts on behalf of a user, it needs to know: does this user have the right to take this action on this resource? That question requires an explicit ownership field. Not an implicit one derived from session state or inferred from context — an explicit field that says owner_id: user_123 or org_id: acme_corp.

Without explicit ownership, you get two failure modes. The first is that agents can’t safely act autonomously — every action requires a human to verify that the agent is operating on the right resource. The second is that your system becomes vulnerable to the kind of agent fraud Stripe is already seeing at scale: a few thousand humans running millions of agents to register fraudulent accounts and steal tokens from AI products. Explicit ownership fields are part of how you enforce authorization at the data layer, not just the session layer.

Here’s the test: pick any resource in your system — a document, an order, a subscription, a project. Can you query “all resources owned by user X” without joining through session tables or inferring from audit logs? If the answer is no, ownership is implicit.

This also matters for the payment authority shift Stripe is building toward. When a user grants an agent programmatic access through something like Stripe’s Links wallet — where the agent creates a spend request, the user approves, and Link returns a one-time card or shared payment token — the agent needs to know which resources it’s authorized to act on. That authorization chain breaks down if your data model doesn’t have explicit ownership.

---

Question 4: Do Your APIs Use Structural or Conversational Verbs?

This is the question that separates businesses that were designed for software integration from businesses that were designed for human use and then had an API bolted on.

Conversational verbs are things like getInfo, doAction, processRequest, handleThing. They’re named for what a human might say. They’re often vague about what they actually do, what parameters they accept, and what they return.

Structural verbs follow a pattern: create, read, update, delete, list, search, subscribe, cancel. They’re named for the operation, not the intent. An agent can reason about structural verbs because they map to a predictable data model. POST /orders creates an order. GET /orders/{id} retrieves one. DELETE /orders/{id} cancels it. The agent doesn’t need to read documentation to guess what these do.

The practical test: look at your API endpoints or your internal service methods. Can you tell from the name alone what data they operate on and what operation they perform? Or do you need to read the implementation?

This matters because agents working in the agentic commerce model aren’t just executing single transactions. They’re coordinating across services — checking inventory, verifying price, confirming delivery window, initiating payment, handling errors. That coordination requires each step to be predictable. If your processCheckout endpoint sometimes creates an order, sometimes updates an existing one, and sometimes returns a validation error formatted as a success response, an agent will fail in ways that are very hard to debug.

The WAT framework for workflows, agents, and tools makes a similar point about tool design: the cleaner the interface contract, the more reliably an agent can compose tools into a working workflow. And if you’re evaluating which model to run against these tools, the tradeoffs covered in GPT-5.4 vs Claude Opus 4.6 are worth understanding — different models handle ambiguous API responses very differently.

---

Question 5: Is Your History Queryable or Just Visible?

The last question is about memory, and it’s the one that determines whether agents can act on your behalf over time — not just in a single session.

Visible history is a timeline, a log, an activity feed. A human can scroll through it and understand what happened. It’s great for support tickets and audit trails that humans read.

Queryable history means you can ask structured questions: “all orders placed in the last 30 days,” “all failed payments for this account,” “all support tickets resolved in under 4 hours,” “all price changes for this SKU.” An agent can use queryable history to make decisions. It can check whether a condition has been met, whether a pattern exists, whether an action has already been taken.

This connects to one of the most interesting use cases Nate Jones describes: agents with mandates that span time. “Buy this when the price drops.” “Reorder when inventory falls below threshold.” “Escalate if the ticket isn’t resolved in 24 hours.” These mandates require the agent to query history, not just observe it.

The test: can you write a SQL query (or API call) that returns “all events of type X in time range Y for user Z”? If your history is stored as a log of human-readable strings, the answer is probably no. If it’s stored as structured events with typed fields, the answer is probably yes.

Stripe’s Metronome integration for precise usage tracking is a good example of queryable history done right — every token consumed, every API call made, every billing event recorded as a structured record that can be queried for usage-based billing. That’s the model.

---

Running the Diagnostic: What Your Score Means

Here’s how to score yourself. For each question, give yourself a 0 (no), 1 (partial), or 2 (yes):

1. Records vs. content — Can your five most important commercial facts be queried as fields?
2. State machine vs. labels — Can you write a conditional against every status in your system?
3. Explicit ownership — Can you query all resources owned by a specific user without session inference?
4. Structural verbs — Can you tell from an endpoint name what data it operates on and what it does?
5. Queryable history — Can you query events by type, time range, and user?

8–10: Your business is agent-readable. You can start thinking about how to expose your commercial data through protocols and integrations.

5–7: You have partial agent-readiness. Some agents can transact with you; others will fail in specific scenarios. Identify which questions scored low and fix those data models first.

0–4: Agents will struggle to use your business reliably. This isn’t a technology problem — it’s a data modeling problem. The good news is that fixing it makes your business better for human software integrations too.

---

What Agent-Readiness Actually Requires

The diagnostic is a starting point, not a finish line. Passing all five questions means agents can read your business. It doesn’t mean you’ve solved discovery, trust, or payment authorization.

For discovery, you need to think about how your commercial data gets broadcast into the assistant surfaces where buyer intent is forming. Stripe’s agentic commerce suite is one path — it lets merchants project inventory, pricing, and fulfillment logic into AI interfaces. Google’s Merchant Center work is another. The question isn’t just “can an agent find me” but “can an agent understand what I offer well enough to match it to a buyer’s intent.”

For trust, the chain is longer than most people expect. The buyer has to trust the agent. The agent platform has to trust the seller. The payment network has to enforce controls across all of it. Stripe’s Links wallet for agents handles part of this — the user grants programmatic access, the agent creates a spend request, the user approves, and Link returns a one-time card or shared payment token. The agent never sees raw credentials. But that trust chain only works if your business is legible enough for the agent to represent accurately.

For payment authorization, the shift is structural. In the old model, payment authority was extracted inside the seller’s checkout flow. In the agent model, the buyer’s agent may arrive with payment authority already scoped — bounded by amount, merchant, credential type, or approval state. Your checkout needs to be able to receive an authorized purchasing attempt from a bot, not just a browsing human. That’s a different surface to design for.

The brand implication is the one that’s easiest to underrate. In the agent economy, brand isn’t a billboard — it’s an entry in the buyer’s operating context. The agent carries brand loyalty as a constraint: “this user prefers this roaster, avoids this airline, trusts this vendor.” You don’t get to reset that with a landing page. You earn it through consistent data, clear policies, and reliable fulfillment. The seller’s persuasion surface is shrinking; the buyer’s preference layer is growing.

If you’re building the kind of application that needs to expose structured commercial data to agents, Remy takes a spec-driven approach to the underlying data model: you write an annotated markdown spec and it compiles into a complete TypeScript app — backend, database, auth, and deployment included. The spec forces you to be explicit about ownership fields, state machines, and queryable history from the start, rather than retrofitting them later. That’s exactly the discipline this diagnostic is measuring.

The five questions in this diagnostic aren’t new engineering problems. They’re the same data modeling discipline that made software integrations reliable before agents existed. What’s changed is the cost of getting it wrong. When a human hits a confusing checkout flow, they might abandon the cart. When an agent hits an ambiguous status field or an implicit ownership model, it either fails silently or takes the wrong action — and the buyer never comes back.

Run the diagnostic. Fix the lowest-scoring question first. The agents are already arriving.