Your Software Isn't Agent-Ready. Here's the Five-Minute Test.

Most companies responding to AI right now are adding a chatbot to their product. A box in the corner that answers questions about the thing, sitting next to the thing.

Meanwhile the actual shift is happening somewhere else entirely. Agents are starting to operate software — not describe it. And the software they can operate is going to get used, while the software they can’t is going to get skipped.

That capability isn’t a model problem. It’s a plumbing problem, and it’s almost always solvable in your existing stack without rebuilding anything.

Here’s how to tell where you stand.

Watch the three-minute version

If you’d rather read it, everything in the video is below — including the worked example and the failure that doesn’t look like a failure.

The test

Take one workflow your team runs by hand. Something routine — publishing a piece of content, generating a report, kicking off a render, provisioning an account.

Write down every step. Then mark each one:

Can this step be done with an HTTP request, or does it require a human to click something?

That’s the whole test. And the result is usually lopsided in an encouraging way: eight steps are already API-reachable, and one or two aren’t. Those one or two are why the entire workflow still needs a person, and they’re usually far smaller problems than they look.

The most common blockers we find:

• Setup requires the UI. Creating the account, project, or workspace is click-only, even though everything after it is scriptable.
• All-or-nothing credentials. You can hand over full admin or nothing. There’s no scoped key, so nobody’s willing to automate anything.
• State you can only see on a screen. The job status lives in a spinner, not a response body. Nothing can tell whether the work finished except a human looking at it.
• Silent failure. When something breaks mid-run, nothing says so. The automation happily continues past a step that didn’t happen.

Every one of those is fixable. None require replacing your platform.

A worked example

We keep a connector in our ecosystem for ClipMaster, a video clipping platform, so agents can drive it end to end. It’s a good illustration because the finished shape is unglamorous and obvious in hindsight:

POST  /api/project        create the container
POST  /api/clip           import, transcribe, score, generate
PATCH /api/clip           queue an export
GET   /api/clip?clipId=   poll status; returns a signed URL when ready

Bearer token for auth. That’s the entire surface an agent needs. Anything that can make an HTTP request can run the whole pipeline unattended.

When we wired it up, the blocker was blocker #1 from the list above, exactly as predicted. Every endpoint that did real work required a project ID — and no endpoint could create one. Projects were click-only. A human had to be present for step one of a process that was otherwise entirely automatable.

The fix was one route, matched to the validation and service layer the UI already used, so both paths behave identically. One endpoint stood between “mostly automated” and “fully automated.” That ratio is extremely typical.

There was a second finding worth repeating, because it’s the kind of thing this work surfaces:

Someone had once added a route directly on the production server and installed its dependency by hand, without committing either. It worked fine — until a routine dependency install removed the package that was never in the manifest. From that point the project could not be rebuilt, while the running server kept serving the previous build without complaint.

The application was healthy. The ability to change it was gone. Nothing anywhere reports that condition. You discover it the next time you try to ship, which might be weeks later, usually when you’re in a hurry.

What “agent-ready” actually requires

Four properties. Not one of them is exotic:

Every action reachable over HTTP. If one step needs a browser, the chain stops there and the whole thing reverts to manual.

Scoped credentials. A key tied to one account with limited reach. This is what makes it safe to let an agent act at all.

Checkable state. Every call returns something verifiable — a status code, an ID, a job state. The agent polls until the response says done. It verifies instead of assuming, which is the difference between an automation and a liability.

A published tool manifest. A machine-readable description of what’s available so an agent can discover your tools rather than being hand-fed a spec. This is what the WebMCP protocol standardizes, and it’s rapidly becoming the difference between software an assistant can use and software it routes around. The same instinct applies to publishing an llms.txt file — both are about making your site legible to something that isn’t a person.

Add one more if you’re letting agents deploy: guardrails that fail loudly. Our deploy refuses to touch the live process when a build is incomplete — broken build, site stays up. That single property is what makes autonomous shipping defensible.

The failures that don’t look like failures

Agent-readiness breaks in quiet ways, which is why it goes unnoticed. A page that renders perfectly for a human can still defeat an automated caller: layout shift alone is enough to make an agent click the wrong coordinates, and a poorly structured accessibility tree leaves it unable to identify what it is looking at in the first place.

None of these show up in a normal QA pass, because a human tester compensates for all of them automatically without noticing.

Why this is urgent rather than interesting

Browser-native assistants are already choosing which tools to use on a user’s behalf. That selection is mechanical: they read what’s exposed, and they use what they can operate.

If your checkout can’t be driven programmatically, it doesn’t get driven. If your tool publishes no manifest, it isn’t in the set under consideration. This isn’t a ranking penalty you can appeal — it’s absence from the list.

The companies that sort this out in the next year won’t be the ones with the best chatbot. They’ll be the ones whose software an agent can actually operate.

Where we come in

This is our Agentic Workflow Automation practice: we take the tools you already own and make them callable — closing the click-only steps, issuing scoped credentials, exposing state, and publishing the manifest that lets assistants find you. Related work sits under Agent-Readiness Optimization and, for storefronts, Agentic Commerce & WebMCP Funnels.

If you’d rather start metered instead of scoped, execution credits cover agent actions directly — 250 for $9 to test the idea, 1,000 for $39, 5,000 for $99, or 25,000 for $299 at agency volume.

Run the five-minute test first. Take one workflow, mark the click-only steps, and count them. If it’s one or two, you’re closer than you think — and that’s a short conversation.

Bring us the step that still needs a human in the middle.