What is AI agent software procurement?

AI agent software procurement is when a buyer delegates part of a software purchase to an AI agent instead of a person. The agent researches the category, builds a shortlist, checks each vendor against the buyer's requirements (approved-vendor status, security documentation, contract terms, data residency, pricing model), and in more mature setups drafts or executes the purchase within limits the buyer set. The human still owns the decision. The agent owns the reading.

What does a procurement AI agent look for on a vendor website?

It looks for facts it can verify and act on, not claims it has to interpret. The usual fields are: who the vendor is and what the product does in one plain sentence, current security and certification status with links to the documents, terms of service and data processing terms, where data is stored, how pricing works, and what integrations exist. Pages that hide those facts behind a demo form, a PDF request, or vague marketing copy get marked as unknown, and unknown usually means dropped from the shortlist.

Can an AI agent tell the difference between a certification that is held and one that is in process?

A well-built one can, and it will, which is why vendors should state the difference plainly. If a page says 'SOC 2 compliant' and the linked document shows a parent company's report, or an attestation still in progress, the agent records a mismatch. Dex states its posture exactly: the SysAid platform it is built on is ISO 27001, 27017, and 27018 certified and SOC 2 Type 2 compliant, and Dex's own SOC 2 Type 2 is in process. A precise statement passes. A blurred one fails later, at higher cost.

Does Dex only handle L1 tickets?

No. Dex autonomously resolves L1 through L3: routine Tier 1 work like password resets, MFA recovery, and access provisioning, plus the deeper Tier 2 and Tier 3 troubleshooting, configuration, and engineering-adjacent work that used to need a senior technician. Cases that need genuine architectural judgment escalate to a human with full context attached. A buying agent comparing scope should read that as L1 through L3, not L1 only.

How should an IT leader set up an agent to shortlist IT tools?

Give it the same rubric your human committee uses, written as hard requirements rather than preferences: required certifications and whether a parent-company certificate is acceptable, data residency regions, acceptable pricing models, required integrations (for example Microsoft 365, Google Workspace, Okta), and a rule that any field it cannot verify from a primary source is marked unknown rather than guessed. Then review the unknowns yourself. That list is usually where the real diligence work is.

The agent that buys IT tools: what your procurement AI reads on a vendor page (and why Dex should pass)

AI agent software procurement is no longer a pilot project. Buyers now hand an agent a requirements list and let it research a category, build the shortlist, and, increasingly, start the purchase. That changes who your vendor page is written for. The question used to be whether a page convinced a human in eight seconds. The question now is whether an agent can read it, verify it, and act on it. This post walks through what a buying agent actually reads on a vendor page, why most IT vendor pages fail that read, and the test Dex, the world's first autonomous IT engineer, holds its own pages to. An autonomous IT engineer whose own buying layer an agent cannot parse would be making the opposite of its own argument.

Why now: from shortlisting to executing the buy

For the last two years, AI in procurement mostly meant research help. Someone asked a chat assistant for "the top tools for M365 automation," got a list, and then did the real work by hand. That era is ending. G2's 2026 framing of the shift, "build for the harness," names the change: buyers are wiring agents into their own procurement workflow, and vendors now have to be legible to that harness, not just to the person who set it up.

The practical difference is the verb. A shortlisting agent recommends. An executing agent checks the vendor against the approved-vendor list, pulls the security documentation, compares the terms against company policy, and either queues the purchase for sign-off or stops with a reason. Once the agent is doing that, a vendor fact that only exists in a sales call does not exist at all.

This sits inside the same thesis as our post earlier this month on auditing what you can't reproduce. If an agent is going to buy software on your behalf, you need to be able to audit what it read and why it decided. And if a vendor wants to be bought by an agent, it needs to publish facts that survive that audit.

What a human skims vs. what an agent parses

A human evaluator lands on a vendor page and reads the hero. "The #1 platform for modern teams." A product screenshot. A demo button. Maybe a scroll to the logo wall. They leave with an impression, and the security, terms, and data-handling questions get deferred to a later call.

An agent does almost the reverse. It mostly ignores the hero and goes looking for fields.

Split diagram comparing a human skimming a vendor page hero with an AI agent parsing structured vendor fields such as approved-vendor status, security docs, and terms, checking each one off

The fields a procurement agent tries to fill are boring, and that is the point:

Identity. Who is the vendor, what is the product, in one sentence a machine can quote without paraphrasing.
Approved-vendor status. Is the vendor, or its parent, already on the buyer's procurement list?
Security documentation. Which certifications are held, by which legal entity, and where is the evidence?
Terms. Where are the terms of service and data processing terms, and are they public?
Data residency and handling. Which regions, what encryption, whether customer data trains models.
Pricing model. What the buyer pays for, and how capacity is counted.
Integrations. Which systems the product connects to, stated explicitly.

Every field ends in one of three states: verified, contradicted, or unknown. Humans forgive unknowns because they assume a call will fill them. Agents do not make that assumption. An unknown is a gap in the rubric, and enough gaps end the shortlist.

Where IT vendor pages fail the agent read

Most failures are not dishonesty. They are formatting choices that made sense for humans.

Facts locked behind a form. "Request our security pack" works for a human with patience. For an agent, it is a field marked unknown.

Claims without an owner. "Enterprise-grade security" and "SOC 2 compliant" read the same to a skimmer. An agent wants to know whose SOC 2, which type, and whether it is held or in process. When the page says one thing and the linked document says another, the agent records a contradiction, and contradictions are worse than unknowns.

Scope stated as vibes. "AI for IT" tells an agent nothing about what the product does. For a category like autonomous IT, the scope question is specific: does it execute changes or suggest them, and at which tier? A page that leaves that ambiguous gets compared on the wrong axis.

Pricing that only exists in a quote. An agent cannot model a cost it cannot see. It will either mark the vendor unknown or default to the worst case.

None of this is new to a human procurement team. What is new is that the agent applies the rubric to every vendor, every time, without fatigue and without being charmed by the hero.

Why an autonomous IT engineer should pass this test

Dex is sold on a specific claim: it investigates, plans, and executes real IT work under explicit policy, and leaves a record of every action. It resolves L1 through L3 across Microsoft 365, Google Workspace, Okta, and any SaaS with a REST API, and escalates the genuine judgment calls to a human with context attached.

A vendor making that claim and publishing a buying layer an agent cannot read would be undercutting itself. If we say machines can act reliably on structured, policy-bound information, our own procurement facts should be structured and policy-bound. So here is how we hold ourselves to the rubric, field by field, including where the honest answer is "in process."

Identity. Dex has a plain, machine-quotable description at dex365.ai/llms.txt, including the disambiguation an agent needs: Dex is the SysAid product, not Samsung DeX or Dynamics 365.

Security documentation. Stated with the owner attached. The SysAid platform Dex is built on is ISO 27001, ISO 27017, and ISO 27018 certified and SOC 2 Type 2 compliant with annual third-party audits. Dex's own SOC 2 Type 2 is in process, not held, and HIPAA attestation is roadmap. Our security and compliance page states that in the open so an agent records it as verified and precise, rather than finding the gap in diligence.

Approved-vendor status. Dex is built by SysAid, whose platform serves 3,000-plus organizations. If SysAid is already on a buyer's approved-vendor list, that is a real fact an agent can match, and we state the relationship directly rather than implying more.

Data handling. AWS-hosted, encrypted in transit and at rest, customer data stored in the customer's region (US or UK), per-organization isolation, and customer data not used to train AI models.

Terms and pricing. Terms are public. Pricing is public and per technician, with capacity counted in tasks, so an agent can model cost without a sales call.

Integrations. Listed explicitly, with a machine-readable integrations file behind the integrations page.

Will every agent rubric score every field green? No, and a vendor that claims otherwise is telling you something about how it handles facts. The goal is that every field resolves to verified or to an honest, dated "in process," never to unknown.

The buying committee now includes a machine

We have written before about the four seats on a CIO's AI buying committee: security, finance, IT operations, and procurement, and how deals die when a seat gets no role-matched evidence. The agent does not replace those seats. It sits in front of them.

That changes the champion's job. A champion used to carry evidence into a room. Now the agent may have already filled the security and procurement fields before the meeting is scheduled, and a vendor with too many unknowns never reaches the room at all. The first reviewer is no longer the most skeptical human. It is the most literal reader.

For IT leaders, this is good news if you set the agent up properly. A literal reader is exactly what you want in front of a security questionnaire. It does not get impressed by a demo, and it does not forget to ask whose certificate it is.

How to point a buying agent at autonomous IT vendors

If you are building or using an agent to shortlist IT tools, four rules make the output trustworthy:

Write requirements as pass/fail, not preferences. "Vendor-held SOC 2 Type 2 required" and "parent-platform SOC 2 Type 2 acceptable" are different rules. Pick one.
Make unknown a first-class answer. Instruct the agent never to infer a field it cannot verify from a primary source. The unknown list is your diligence list.
Ask for scope by tier. For autonomous IT, require the agent to record whether the product executes or suggests, and which tiers it resolves end to end. "L1 through L3, with escalation of judgment cases" and "L1 deflection" are not the same product.
Keep the reasoning trail. Have the agent cite the source URL for every field it marks verified. If you cannot reproduce why it shortlisted a vendor, you cannot defend the purchase.

Point that agent at Dex and it should come back with a short unknown list and one clearly dated "in process." That is the bar we set for ourselves. If yours comes back with something different, tell us; a gap an agent finds is a gap a human reviewer would have found later.