Agentic readiness

The operating model behind the target role is agents doing work inside portfolio products. So the diligence question is not whether the company has an AI strategy, which every company now says it has. It is whether an agent could ever act inside this product without the team rebuilding it first — and that turns out to be four separate questions with four separate answers.

This is also the axis where you are most likely to be handed a slide deck instead of evidence. A roadmap is not readiness. What you want is the boring structural stuff, most of which is visible from outside because it was built for somebody else’s benefit and published.

Question one: is there an API surface to act through?

An agent acts by calling something. If the only way to change state in this product is a browser session driving an undocumented private endpoint, then every agent built here starts by automating a UI, which is the most expensive and most brittle option available.

Outside-visible evidence, in descending order of strength: a published API reference with a machine-readable schema; officially maintained SDKs; webhooks, which prove the product can also talk outward; a developer portal with credentials you can register for; an integrations directory, which is third-party proof that the surface is usable rather than aspirational. Documented rate limits are a small tell that carries a lot — a product publishes rate limits when real traffic has arrived.

The negative finding is just as scoreable. A large product with no public API, no SDK and no integrations page has made a choice, and it is usually a choice about commercial control rather than an oversight. Write it that way. It also changes the remediation estimate more than anything else on this axis, because the work is not a feature, it is a product decision with a security review attached.

Question two: is application state reachable?

This one people score by intuition and it has a crisp outside test: can you link to it?

Open the product and try to send someone a URL that lands them on a specific record, a specific filtered view, a specific step of a multi-step flow. If the address bar never changes, the state lives inside a client-side component and nothing outside the session can address it. An agent cannot hand a human a link to what it just did, a human cannot hand the agent a starting point, and the review step you will want in question four has nowhere to point.

This is a proxy, not a proof, and you should say so in the cell. A product with clean addressable URLs might still hold its real state in an unreachable place, and a single-page app with poor routing might have a perfectly clean state layer underneath. What the link test gives you is a fast, reproducible, uncurated observation that correlates with the thing you cannot see. That is the standard on this axis, and naming it as a proxy is what keeps the finding survivable when an engineer disagrees.

Question three: is there telemetry to measure impact against?

The weakest of the four from outside, and worth being blunt about. You can open the network panel and see which analytics vendors the page loads. That tells you a tag is installed. It does not tell you that events are meaningful, that anyone reads them, or that a baseline exists for the workflow an agent would take over.

Better outside evidence, where it exists: a public changelog that describes changes in terms of measured effects; an engineering or product blog with experiment write-ups; job postings for analytics or experimentation roles. Each of those is a company telling you voluntarily that it measures things.

The reason this question is on the axis at all, despite being hard to answer, is the failure it predicts. An agent deployed into a product with no baseline cannot be shown to have helped. The pilot then gets judged on anecdote, and anecdote kills agentic projects at exactly the moment they are working. If you cannot answer this from outside, mark it not assessed and put it at the top of the interview list, because it is a question a competent product team answers in one sentence.

Question four: does review-and-approval already exist?

The most observable of the four, and the one most often scored wrong.

Here is the vocabulary worth borrowing. The Model Context Protocol — an open specification originated at Anthropic, not a standard from ISO, the IETF or the W3C, and the difference matters when you cite it — defines elicitation as the mechanism by which a server asks a user for something mid-task. A response carries one of three actions:

• accept — the user explicitly approved and submitted with data.
• decline — the user explicitly declined the request.
• cancel — the user dismissed without making an explicit choice: closed the dialog, clicked outside it, pressed Escape.

The third one is the whole point. Most interfaces have two states, yes and not-yes, and they treat walking away as a no. A protocol that separates an explicit refusal from a dismissal is drawing a distinction that matters enormously once software is acting on your behalf, because the two carry different information about consent. When you assess a product’s existing approval affordances, that three-way split is the sharpest lens available, and it comes from a real published document rather than from you.

Now the scoring judgement, which is the part the rubric flags as most often wrong. A product with an existing approval step — a draft state, a reviewer queue, a confirm-before-send, an editable auto-generated suggestion — has already taught its users that the software proposes and a person disposes. Those users have a mental model that an agent slots into.

Retrofitting that concept into a product where every action has always been immediate and final is not a feature you can estimate like a feature. It is a change to what users believe the software is, and it arrives with retraining, support load, and a real chance the first cohort simply turns it off. Score that red even when the engineering to build the queue looks small, and put the reason in the finding, because the reason is the part management will not have considered.

What this does not cover

Every question here is about whether an agent could act inside this product as it stands. None of them asks the question the operating model actually turns on, which is whether a surface built once somewhere else could be installed here — a question about theming seams, auth boundaries and whether a piece of the interface can ship independently of the whole application. That is the graftability lesson, the last of the four axes, and the one where this course invents the most and cites the least.

The consent and control questions this axis only touches — how an agentic interface should ask, show its work and hand back control — are a design subject rather than a diligence one, and this course does not teach them. It only asks whether the product has the seams where they would go.