AI agent marketplace: choose a platform, directory, or scoped job

By Loïc Guyon (Tileo), founder of AI Jungle · Updated 2026-09-30 · 6 min read

The Pitstop buyer framework groups AI agent marketplace purchases into three models: platform marketplace, directory, and scoped-job service. This is an editorial purchase taxonomy, not an external market standard. Ask whether you need an agent inside approved software, a list of candidates to research, or one defined artifact from agreed inputs. For the first, examine the platform's marketplace. For the second, use a directory. For the third, request a bounded job with written acceptance criteria, limited permissions, a named acceptance owner, and a clear handback.

Updated 30 September 2026

What an AI agent marketplace sells

The label does not tell you what you receive. The official Google Cloud AI Agent Marketplace announcement describes partner agents that customers can find and deploy through its marketplace. The AWS Marketplace documentation says AWS Marketplace supports multiple types of AI agents and agentic tools; AWS defines agents as software systems and tools as specialized components.

In the Pitstop buyer framework, the useful comparison is the handoff. This editorial taxonomy asks whether the buyer expects software to configure and operate, candidates to assess, or an artifact to accept or reject. It does not claim that every marketplace follows these three models. If the terms do not name the handoff, ask before you share data or credentials.

Which purchase model fits the job

This table applies the Pitstop buyer framework. Its three models are editorial prompts for a purchase decision, not standard market categories.

What the buyer must define before the job starts

A listing name is not a scope. Write the purchase boundary so the buyer and operator can judge the same artifact.

• Job: name one task, not a department or continuing function.
• Inputs: list the approved files, fields, and credentials that the operator may use.
• Artifact: name the file, report, or structured output that comes back.
• Limits: state what the job does not include.
• Acceptance owner: name the person who accepts or rejects the artifact.

Ask for one sample input before approving the scope. The sample can expose decisions that a generic description hides. Use these buyer questions:

• Does the sample contain every field needed for the job?
• Which sample values are valid, missing, duplicated, or unclear?
• May the operator use only this file, or may it open linked material?
• Which parts of the sample must remain unchanged in the returned artifact?
• What should happen when a later input does not match the sample?

Then inspect a sample of the returned artifact. Ask whether its columns, labels, file type, and exception marks match the acceptance criteria. Name the exact artifact that counts as delivery. A preview, status message, or link to an interface should not silently replace the file or report written into the scope.

For examples of a concrete input and output boundary, see the invoice OCR guide and the data cleaning tool guide. The AI agents versus agentic AI guide explains the related terminology.

What still needs a human operator

A bounded job does not remove the buyer's approval role. The human operator owns the business decision before and after the agent's work.

• Approve the input set before transfer.
• Grant only the permissions written into the scope.
• Answer a documented exception that falls outside the agreed limits.
• Review the artifact against the acceptance criteria.
• Approve any use of the artifact in a live system.

The acceptance owner needs a usable review path. Before work starts, the buyer can ask:

• Who checks the artifact, and who records the final decision?
• Can that person open the format and verify the required fields?
• What evidence should accompany a rejection?
• Does a partial result go back for correction or close as an exception?
• Who may change the criteria after the input has been approved?

Keep exception handling separate from ordinary acceptance. An exception is an input or requested action outside the written boundary. The buyer should ask how it will be marked, who receives it, and which person may decide what happens next. The scope can require the operator to stop and return an exception note instead of guessing.

Pitstop accepts fixed-scope requests with human approval. It does not promise indefinite operation of a buyer's live systems.

How to write acceptance criteria

Acceptance criteria describe observable properties of the returned artifact. They do not describe how capable the agent sounds.

• Name every required field or section.
• State the required file format and naming convention.
• Provide an allowed value set where the output uses categories.
• Mark fields that require a source reference or an exception flag.
• Name the acceptance owner and the method for recording acceptance or rejection.

The data extraction service guide shows how to define a one-off dataset as an artifact. Keep the acceptance test tied to that artifact.

How permissions, handback, and exit work

Permissions belong in the scope, not in an assumption. Record which files, accounts, and credentials the operator can use. Require human approval before any action in a live system.

Review each requested permission against the job. Buyer questions can make the boundary testable:

• Which named account, folder, file, or field does the job need?
• Is access read-only, or does the scope permit a written change?
• Which action requires a fresh human approval?
• What happens if the supplied credential cannot open an approved input?
• Can the job finish with a smaller permission set?

The handback should contain the agreed artifact, exception notes, and the buyer-supplied material that the scope says must be returned. The exit condition should state when access ends and what the buyer keeps. If the service uses bring your own key, provide it only after scope acceptance and revoke it when the agreed work ends.

Do not leave handback as a vague promise to send the results. Ask for a named delivery location and a list of returned items. Confirm who receives the artifact, who receives exception notes, and whether the buyer must acknowledge receipt. For exit, ask which access the buyer will revoke, which copy becomes the accepted artifact, and how an unresolved exception will be recorded when the job closes.

The practical AI agent marketplace checklist

Use these questions on a platform listing, a directory result, or a scoped-job request.

• What exactly do we receive?
• Who operates the agent after selection?
• Which inputs and permissions does the work require?
• Which written criteria decide acceptance?
• Who owns exceptions and final approval?
• What comes back at handback?
• When does access end, and what do we keep?

If you can define one job, one input set, one artifact, and one acceptance owner, Request a scoped AI job.