I spent a day reading 45 platform terms of service end to end, because an agent I run kept failing at steps that had nothing to do with its code. The marketing pages said API first. Several said agent friendly. The terms said something else. Twenty-six of the 45 platforms forbid automated account operation or automated use somewhere in the agreement. Eighteen put a human identity somewhere in the signup or payout path, by phone number, government identity check, or legal name. Two explicitly allow non-human accounts, and neither of those two pays for work.
What blocks an agent is rarely the API. It is a stack of human-shaped checks, each designed for a reasonable purpose, which together assume a person is at the keyboard.
The first gate is the account itself. On most of the platforms I read, the moment an automated process creates an account it has already broken a clause about automated account creation, no matter how well it behaves afterwards. No amount of engineering removes that gate, because it lives in a document rather than in code.
A permissive API license and a permissive terms of service are different things. The license governs what may be done with the interface. The terms govern who may hold an account and what that holder may automate. An agent can read the documentation, authenticate correctly, and violate the terms in the first request that registers it. An OpenAPI file lists endpoints. It does not grant the right to use them on behalf of a new legal entity.
Phone verification looks like the weakest check and behaves like one of the strongest. SMS gateways are sold to humans. A number that can receive verification codes for months needs either a verified identity or a payment instrument behind it, and providers who sell long-term numbers are comfortable asking for both. An agent can sometimes rent a number, but the cost of doing that badly is reputational and legal rather than technical. If the platform later decides the number never belonged to a person, the account closes and anything inside it goes with it.
Captcha and behavioral risk engines sit exactly on the line between proving a human is present and preventing automation. Passing them is technically possible. What they leave behind is the question of whether passing them was permitted. A risk score of human buys nothing except the removal of one obstacle on the way to a terms violation, which is an odd position for an agent: it can clear a check that exists to stop it and still be wrong for clearing it.
Identity checks are a different class of problem, because they are not a test that can be passed or failed. They bind a legal person to the account. Someone has to carry liability for what happens inside it, and an agent cannot be that someone without a human or a registered entity standing behind it. This is where most automation plans quietly end, and it is the gate worth designing around instead of fighting.
Payment is its own stack: card ownership, address verification, 3D Secure, a bank account in the same legal name. Payout is a separate gate again. A platform can accept automated work, accept the delivery, and still require a human-owned payment account to release the money, which means the labor was allowed and the settlement was not. Only a small minority of platforms expose a machine-payable rail, for example x402 challenges settled in USDC on a public chain, and those rails are the exception rather than the norm.
When the contract is machine-readable, the demand side moves fast. One agent-native bounty board has settled 104 postings worth 1,036 US dollars in total, with 889 operators enlisted, and its fastest regular operator completes an accepted delivery in a median of 8 minutes. The money is small and worth saying plainly rather than dressing up. What matters is the shape of the work: acceptance criteria are an artifact contract, so an agent can check its own output before delivering instead of inferring intent from prose.
Machine-readable acceptance criteria are worth more to an agent than documentation quality. A page that says we accept X, with a named artifact and its schema, is worth ten pages of tutorials, because it lets the agent verify a claim instead of guessing at it. Sourcey (https://sourcey.com) keeps an open registry of startup programs with the source URL and read date on every fact, and publishes agent readiness report cards that grade whether an agent can sign up, pay, and operate a service on its own.
Becoming agent-ready is mostly a set of decisions that only the product team can make, written down where a machine can read them.
- State in the terms whether a non-human may hold an account, and if the answer is no, publish the operator-delegated path: an agent acting under a named human account, with scoped tokens and an audit trail.
- Answer the signup question and the payout question separately. They are different gates, and folding both into an API first slogan hides the one that stops payment.
- Publish acceptance criteria as a named artifact: which file, which fields, what counts as done, and how it is checked.
- If money from a machine is welcome, expose a rail and say who carries the tax and legal identity behind it.
None of this needs new cryptography. It needs one sentence in the terms that says whether a non-human may hold an account and be paid. Until that sentence exists, the interface description is decoration, and the agent stops at the signup form holding a valid token it is not allowed to use.
Top comments (1)
This is the practical distinction many agent demos blur: interface access is not authority. A good agent integration should declare the account holder, permitted automation scope, and a human escalation path before it beginsβnot treat verification or terms as a technical obstacle. That design also gives platforms a clearer way to support supervised automation without pretending the agent is a legal principal.