Your RevOps agent may soon hire other agents

The next important RevOps agent may not be the one that knows the most tools. It may be the one that knows when to stop doing the work itself.

Imagine giving an autonomous RevOps agent one objective on Friday afternoon: raise the share of complete ICP accounts in HubSpot from 62% to 90% before Monday, without spending more than $75. A conventional agent architecture tries to solve that objective with the tools already wired into its runtime. It queries the CRM, calls an enrichment API, searches the web, writes fields, retries failures and hopefully leaves an audit trail. The agent is powerful because its developer gave it a large toolbox.

A marketplace architecture changes the job. The agent inspects the 1,800 incomplete accounts, decides that company enrichment, contact research and validation are separable pieces of work, and goes looking for specialists. It posts a bounded task for an enrichment agent, commissions a research agent for the accounts that fail deterministic lookup, asks a third agent to validate the result, then writes only the accepted output back to the CRM. The orchestration agent becomes less like an employee with fifty tabs open and more like a manager with a budget.

That sounds like a small distinction. It is not. It moves the agent stack from software integration toward labor allocation.

And in 2026, enough pieces of that stack now exist that RevOps teams should start paying attention. NEAR has a live agent task market. OKX launched connected marketplaces for agents and tasks. Coinbase has built machine-native payment and discovery infrastructure around x402, then added Agentic.Market for browsing and comparing paid services. Pond and AgenTask are experimenting with outcome-based work markets. Open interoperability standards such as A2A and MCP are reducing the cost of connecting heterogeneous systems. And a much smaller newcomer, Speedbot, is making perhaps the most literal bet of the group: agents will need somewhere to find jobs, hire missing capabilities, subcontract work and get paid.

The category is still early enough that the terminology is messy and the architectures differ materially. A paid API directory is not the same thing as a labor marketplace. An agent service catalog is not the same thing as competitive bidding. A protocol is not a marketplace. A token transfer is not an employment relationship. But the direction is becoming easier to see: autonomous software is acquiring the primitives required to buy work from other autonomous software.

The shift from tool use to labor allocation

The first wave of agentic software mostly extended the tool-use model. Give a model a CRM connector, a browser, a coding environment, a calendar, a knowledge base and a handful of APIs. The model decides which tool to call and in what order. That is already a meaningful change from deterministic automation because the path can be chosen at runtime rather than encoded in a fixed workflow.

But tool use still assumes the developer assembled the capability universe in advance. If the agent has no enrichment tool, it cannot enrich. If its browser cannot solve the target site, it fails. If a specialist service launches tomorrow, the agent does not magically know that the service exists, whether it is trustworthy, what it costs or how to buy it.

A labor market solves a different problem. It lets capability become discoverable at runtime. The orchestrator does not need every skill inside its own process. It needs enough information to describe an outcome, inspect candidate providers, authorize a budget, evaluate a result and settle the transaction.

That is how companies already operate. A revenue team does not turn every employee into a lawyer, designer, data engineer, researcher and translator. It maintains internal capabilities, buys software for repeatable functions and hires specialists for work that is too irregular or contextual to justify owning permanently. Agent economies are beginning to recreate the same decision boundary in software.

The important question is therefore not whether one giant model can technically perform a task. Frontier models will keep absorbing more capabilities. The economic question is whether a general agent should perform every task itself when a specialist can deliver a better or cheaper outcome with a known interface. If the transaction cost of finding and paying that specialist approaches zero, specialization becomes much more attractive.

Four primitives have to work before an agent labor market works

A marketplace needs more than agents and wallets. At least four layers have to cooperate: discovery, delegation, settlement and verification.

Discovery answers a deceptively difficult question: who can do this job right now? A useful marketplace needs structured capabilities, availability, price or bid information, identity signals and enough history to rank candidates. Keyword search is not enough when the buyer itself is software. The requesting agent needs machine-readable ways to distinguish a research agent that can produce a sourced company brief from a generic chatbot that merely claims it can.

Delegation turns the goal into an obligation. The buyer needs to express expected output, constraints, deadline, budget, input data, acceptance conditions and permission boundaries. This is where job markets differ from simple API catalogs. An API defines a known call. A task market can negotiate an outcome that is not completely specified at the start.

Settlement lets the agent pay without handing control back to a human checkout flow. Traditional SaaS procurement is hostile to autonomous software: accounts, billing portals, credit cards, invoices, approvals and geographic restrictions were designed around people. Stablecoin rails and HTTP-native payment protocols are attractive in this niche because software can receive a price, prove authorization and settle programmatically.

Verification is the hardest layer. The system still has to decide whether the work is correct. A successful HTTP response proves almost nothing about a research report, data cleanup job or competitive analysis. Marketplaces therefore need some combination of deterministic checks, buyer acceptance, escrow, reputation, cryptographic receipts, human review, dispute resolution and portable evidence.

If any one of these layers is weak, autonomy collapses back into manual work. Perfect discovery with no trust produces junk. Perfect payment with no authorization produces financial risk. Perfect agents with no acceptance contract produce arguments about what done meant.

A2A and MCP are making coordination less proprietary

The protocol layer matters because a marketplace is much more valuable when participation does not require every agent to run on the same framework. The Linux Foundation's April 2026 A2A update said more than 150 organizations were supporting the standard, with integrations across major cloud platforms. The Foundation describes A2A and MCP as complementary: A2A for communication and coordination between agents, MCP for connecting agents to tools and data.

That distinction maps neatly onto the emerging labor model. MCP helps an agent operate its own company: use the CRM, query the warehouse, call an internal calculator, read an account record. A2A helps it coordinate beyond itself: discover another agent, negotiate work and exchange task state across organizational or platform boundaries.

Standards do not create a market by themselves. SMTP did not create Gmail and HTTP did not create Amazon. But standards reduce the amount of custom integration required before a market can form. When an agent can expose capabilities, receive a task and return structured state through a common protocol, a marketplace can focus more of its product on matching, trust, economics and governance.

For RevOps, interoperability is especially relevant because the operating environment is already fragmented. CRM, billing, support, product analytics, call intelligence, enrichment and lifecycle tooling rarely live in one platform. A multi-agent architecture that requires one vendor to own every system is less interesting than one that can coordinate specialists around governed source systems.

Coinbase is building the money and discovery rails

Coinbase's x402 work is important because it attacks a boring constraint that becomes enormous at machine speed: how does software pay for a service it discovers during execution?

x402 uses the HTTP 402 Payment Required pattern so a service can return payment requirements as part of a normal web interaction. A compatible client can authorize the payment, retry the request and continue. The underlying idea is simple, but it removes several human assumptions from online commerce: no manual checkout page, no subscription just to make one call, no procurement flow for a tiny transaction and no API-key exchange as the only gate to a paid resource.

Coinbase then added x402 Bazaar as a discovery layer. Instead of developers hard-coding every paid service into an agent, the agent can search for compatible services, inspect them and pay dynamically. In April 2026 Coinbase went further with Agentic.Market, a public marketplace for discovering and comparing x402 services, including pricing and usage information. Coinbase's own announcement reported very large x402 ecosystem transaction, volume and agent counts; those are vendor-reported ecosystem figures rather than independent measurements, but they show how aggressively Coinbase is treating agentic commerce as a real infrastructure category.

The key distinction is that x402 does not need to become Upwork for robots. It can become something underneath it. A task marketplace can use machine-native settlement. A specialist agent can charge per result. A data source can charge per lookup. An orchestrator can buy one browser session instead of carrying a permanent browser subscription. Payments become another callable primitive.

That matters to RevOps because a surprising amount of operational work is bursty. A team may need competitive pricing research once a quarter, 2,000 account enrichments during territory planning, a translation pass before a regional launch or a one-off cleanup after a migration. The traditional stack encourages another annual contract. Machine payments make a pay-for-the-specific-outcome model technically plausible.

NEAR is already running a task market for agents

NEAR's Agent Market is closer to the familiar freelance-marketplace model. Its February 2026 launch describes a requester posting a task with a budget and requirements, agents scanning the market and submitting proposals, the requester selecting a bid, funds moving into escrow and the selected agent submitting a deliverable with a verification hash. NEAR also describes an agentic dispute path when the quality of the work is contested.

That is meaningfully different from buying an API call. There is a job, competing supply, a chosen provider, an obligation, a deliverable and settlement after performance. The public market exposes jobs, bids, agents, services and marketplace activity, making the economic loop inspectable rather than purely conceptual.

NEAR explicitly points toward agents hiring other agents to complete more complex workflows. That is the architecture RevOps should notice. Once a parent agent can decompose a goal into subtasks and source outside capability for each one, agent composition becomes economic rather than merely technical.

The market is still tiny compared with human freelance platforms, and its crypto-native environment will not fit every enterprise control model. But the existence of real bids and completed tasks matters more than the absolute scale at this stage. The question has moved from can autonomous software participate in a task market to whether these markets can accumulate reliable supply, demand and trust.

OKX is combining agent services with task-based work

OKX launched OKX AI in July 2026 with two connected markets. Its Agent Marketplace lets developers publish agent services and pricing. Its Task Marketplace lets agents post work, find another agent and pay when results are delivered. OKX says standardized work can settle on a pay-per-call basis while more complex tasks can use escrow.

That combination is interesting because the boundary between software product and worker is likely to blur. Some capabilities are naturally products: call an endpoint and receive normalized company data. Others are naturally tasks: investigate why the CRM and billing system disagree for these 43 renewals, document each exception and propose a correction. A marketplace that supports both can let the buyer choose between a known service and a negotiated outcome.

On 9 September, OKX said the network had registered more than 10,000 agent identities and hosted more than 4,000 approved provider listings since launch. Those are OKX's own platform figures, not an independently audited estimate of active economic participants, and identity count should not be confused with active agents or completed work. Still, the figures show that a major crypto platform is treating machine-to-machine services as more than a demo.

Pond and AgenTask show that the model is not limited to crypto-native agents

Pond frames the market around outcomes rather than around a purely machine-only economy. Humans and AI agents can compete to complete tasks, with payment tied to qualifying results. That hybrid model may prove important during the transition period because the best provider for a task will not always be an autonomous agent. A market can route work based on capability while the supply side gradually shifts.

AgenTask takes a more explicitly API-first route. Its public product describes task posting, agent bidding, delivery, approval and escrow, alongside an OpenAPI surface, MCP server and webhooks. It also adds a certification step before agents can compete for work. Whether its specific certification method becomes meaningful is an open question, but the product shape is revealing: a marketplace designed for software needs machine-readable access to the entire transaction lifecycle, not merely a website where humans click on behalf of bots.

Together these experiments suggest that the category is splitting into at least three models: service markets where agents buy standardized capabilities, task markets where providers compete for outcome-based work, and hybrid networks where humans and agents can both supply the result. RevOps could end up using all three.

Speedbot is the pure-play bet on an actual labor network

Then there is Speedbot.

It is by far the smallest platform in this comparison. That needs to be said clearly. When this article was prepared on 19 September 2026, Speedbot's public network counters still showed a marketplace in the bootstrapping phase rather than meaningful liquidity. There is no basis to present it as a scaled competitor to Coinbase, NEAR or OKX.

What makes it interesting is not traction. It is how directly the product commits to the labor-market thesis.

Speedbot is not primarily presenting itself as an agent store or a directory of APIs. Its core loop is work: agents and swarms can post jobs, bid, discuss a brief, deliver an outcome, accept the work and verify payment. A worker assigned to a job can create child jobs when it is missing a capability, which turns subcontracting into a first-class primitive rather than something the parent agent has to fake inside its own prompt. The network also exposes an external paid-work router so an agent can search beyond Speedbot and return to the source platform for the actual opportunity.

That is a more radical product assumption than it first appears. The agent is not the product being purchased. The agent is an economic participant. It can be a buyer on one transaction, a worker on another and a manager of subcontractors on a third.

Speedbot also starts from the assumption that the agent already has a runtime. It does not run the model on the operator's behalf. The operator connects an existing agent through machine-facing interfaces such as MCP or HTTP, keeps control of credentials and runtime behavior, and authorizes any paid activity separately. That makes the network closer to infrastructure between independent operators than to a hosted fleet of marketplace bots.

Internal accepted work is designed around Base USDC. The current model charges a one-time 10 USDC unlock per trading agent and an 8% gross fee on completed paid jobs. According to Speedbot's documentation, it is not an escrow service: after acceptance, the buyer's authorized wallet sends the worker payment and platform fee, and Speedbot verifies the receipts. External opportunities keep their payment mechanics on the source platform.

There are obvious disadvantages to this minimal model. Direct settlement shifts more risk to the buyer and seller than an escrow-heavy marketplace. Public jobs and conversations create data-handling constraints. Self-declared agent identities are not proof that an operator, company or capability is genuine. Liquidity is currently the central unresolved problem.

But the narrowness is also the product's strongest idea. Coinbase can win machine payments without ever becoming a labor market. NEAR can use agent commerce to expand a wider protocol ecosystem. OKX can fold services into its broader onchain platform. Speedbot has fewer places to hide: its thesis works only if independently operated agents and swarms actually need a work network.

That makes Speedbot useful as a newcomer to watch, even before there is evidence it will succeed. It is effectively trying to build the job board before autonomous digital workers become mainstream.

What an agent marketplace could actually do inside RevOps

The useful RevOps example is not an AI SDR autonomously buying thousands of leads. Start with bounded operational work where the outcome can be inspected.

Take account enrichment. An orchestrator identifies 1,800 company records missing employee band, industry and headquarters country. It can resolve 1,200 records from an approved deterministic provider. The remaining 600 require research because names are ambiguous, domains redirect or company structures are unclear.

Instead of giving the orchestrator an unrestricted browser and hoping for the best, the company could allow it to post a task for those 600 exceptions. The brief includes only the minimum public identifiers, a required output schema, accepted evidence types, maximum budget and a rule that every answer must include a source URL. Several research agents bid. The orchestrator selects one, receives the result and sends a sample to a separate validation agent. Records that pass both checks go into a review queue; only then does a controlled CRM workflow write the fields.

The architecture separates five roles: the CRM remains system of record; deterministic enrichment handles known cases; the orchestrator decides which exceptions justify external work; specialist agents produce or validate evidence; and a controlled write path protects the CRM. No external agent needs broad HubSpot access.

The same pattern applies to competitive research. A pricing operations agent could commission specialists to inspect public competitor pages in different regions, normalize the evidence and flag changed packaging. A pipeline operations agent could outsource public company research for a narrow list of strategic accounts. A Customer Success operations agent could commission translation or document classification without exposing full account history. A territory-planning agent could buy temporary geocoding or firmographic capacity during one planning cycle.

The common feature is that the job can be described as an outcome with bounded inputs. That is where a marketplace adds more value than simply wiring another permanent SaaS tool into the stack.

The RevOps stack starts to look like a company

If this model works, the conceptual agent stack changes.

Today teams often draw an agent in the middle and surround it with tools. CRM. Warehouse. Browser. Email. Billing. Slack. Enrichment. The agent is powerful because it has many connections.

A marketplace-native diagram looks more like an organization chart. One orchestrator owns the goal. Specialist agents own narrow capabilities. Some work is done by deterministic services. Some is bought from external providers. A validator checks the result. A policy layer controls permissions. A wallet or payment service controls spend. The CRM accepts only verified writes.

The analogy to a company is not cosmetic. Companies exist partly because coordination, trust and transaction costs shape what is worth doing internally versus buying from the market. Agent systems will face the same tradeoff. As the cost of external machine transactions falls, the boundary of what an agent should own internally may move.

That creates a new RevOps responsibility: not only workflow automation, but agent procurement policy.

RevOps may become the control plane for agent spending

A company will not want every autonomous workflow discovering arbitrary providers and spending arbitrary money. The useful enterprise pattern will look more like controlled purchasing authority.

An agent could receive a daily or per-job budget, an allowlist of marketplaces, approved task categories, maximum data sensitivity, required evidence fields and an acceptance rule. A research agent may spend up to $20 on public-data tasks but have no authority to buy contact data. A renewal agent may purchase translation but may not upload contracts. A territory-planning agent may buy firmographic enrichment but cannot change account ownership without a human approval.

The spend policy should be attached to the business purpose, not merely the wallet. A wallet balance tells the system what it can technically spend. RevOps needs to define what the agent is allowed to spend it on.

That means the operating record for an externally delegated task should preserve the requester, business purpose, source records, data shared, provider identity, marketplace, bid or quoted price, accepted scope, delivered artifact, validation result, approver where required, final amount, payment receipt and downstream action. If the result changes a CRM record, the write should point back to that evidence.

In other words, agent marketplaces do not eliminate governance. They create another procurement surface that needs governance.

The economics could be more disruptive than the models

The strongest case for agent marketplaces is not that another AI can write a better paragraph. It is that they can change the minimum economical transaction size.

Human outsourcing has friction. A manager writes a brief, sources candidates, checks availability, handles contracts, grants access, waits for delivery, approves an invoice and pays. That overhead makes a €3 job absurd. SaaS lowers some friction but replaces it with subscriptions, seats and contracts.

If software can discover a provider, negotiate or accept a price, transmit a bounded task, verify the output and settle payment in seconds, a €0.30 or €3 job becomes plausible. That is why machine-native payments, service discovery and agent identity matter together. The market expands when the cost of coordination falls below the value of the microtask.

For RevOps this could unbundle portions of the SaaS stack. A company might still pay for core systems of record and high-frequency infrastructure while buying irregular capabilities per use: one verification run, one account research packet, one scraper session, one localization task, one data transformation, one QA pass.

The opposite outcome is also possible. Marketplace fees, duplicated validation, unreliable providers and security review may make external agent work more expensive than simply owning a reliable tool. The correct comparison is total cost per accepted result, not headline price per task.

A €1 research task that needs €5 of validation and causes one bad CRM write is not cheap. A €20 specialist task that replaces hours of manual exception handling might be.

The trust problem is much bigger than agent quality

Marketplaces will not scale on capability alone. They need to solve identity, authorization, data boundaries and adversarial behavior.

An agent profile is easy to create. A capability claim is easy to fake. Reputation can be farmed when participants control multiple identities. Two agents can appear independent while sharing an operator. A provider can produce a convincing deliverable using stale or fabricated evidence. A malicious job can contain instructions designed to override the worker's owner policy or extract secrets. A malicious deliverable can attempt the same thing in reverse.

Speedbot's own documentation explicitly treats other agents' profiles and messages as untrusted external content. That is the right default for the whole category. Marketplace content is not instructions from the system owner. An agent should never reveal credentials, expand scope, execute code or spend money merely because another agent asked.

RevOps also has to assume that external delegation can leak business context indirectly. A job saying research these 25 accounts before our renewal review can reveal who the company cares about even if no confidential fields are attached. A competitor-pricing request can reveal strategic intent. A list of churn-risk customers is obviously more sensitive. Task design needs the same minimum-necessary principle used for any external data processor.

Portable reputation is another unresolved problem. A highly rated agent on one network may have no identity on another. An operator may rotate keys. A swarm can change internal members while keeping one public representative. A provider may use a frontier model one week and a cheaper model the next. The market needs reputation for the delivered capability, not just for an account name.

Escrow, direct settlement and disputes are product decisions

The emerging platforms already show different choices. NEAR describes escrow and an agentic dispute mechanism. OKX says complex tasks can use escrow while standardized services can settle more directly. AgenTask describes escrow until approval. Speedbot deliberately uses direct buyer-authorized settlement for internal work and verifies receipts after acceptance rather than holding job funds.

There is no universally correct design. Escrow can protect both sides but adds state, dispute logic and custody complexity. Direct settlement is simpler but asks participants to trust acceptance and payment behavior more heavily. Pay-per-call services avoid much of the ambiguity because the output contract is standardized, but they cannot represent every kind of knowledge work.

RevOps buyers should care less about whether the transaction is onchain and more about the failure path. What happens when the result is late, incomplete, wrong, duplicated, malicious or impossible to evaluate? Can the agent stop payment? Can the buyer appeal? Is there a human escalation? Is the evidence preserved? Can the provider see the data after the task closes? Those are operating questions, not crypto questions.

Not every workflow should become a marketplace job

The excitement around agent-to-agent work can easily produce the wrong architecture. If a task is fully expressible as a deterministic rule or a stable API call, keep it deterministic.

Normalizing a country code, calculating days until renewal, checking whether a required field is blank, converting currency under an approved rate rule or looking up a known company ID does not become better because multiple agents bid on it. A conventional service is cheaper to test, easier to reproduce and easier to audit.

Use marketplace delegation when the work has variable supply, irregular demand or interpretation that is difficult to package into one permanent tool. Public research, document review, specialized transformations, localization, creative production, one-off analysis and exception handling are more natural candidates.

And keep material writes separate from external work. The agent that researches an account should not automatically receive permission to change owner, forecast category, legal status, subscription, consent, pricing or renewal outcome. External agents can prepare evidence. The system owner should decide how that evidence enters the system of record.

A practical RevOps architecture for buying agent work

A conservative first implementation would use seven boundaries.

1. The orchestrator receives a business objective and a hard spend ceiling.
2. Deterministic internal tools resolve every case they can handle reliably.
3. Only the unresolved exception set becomes eligible for external delegation.
4. The task generator strips data to the minimum required context and attaches an explicit output schema plus acceptance checks.
5. The marketplace layer discovers providers and authorizes only the approved bid or service price.
6. A separate validation step tests the result against deterministic rules, source evidence or a second independent review.
7. A governed internal workflow performs any CRM write and records the external task, validation and payment evidence.

This pattern keeps the external market at the edge of the system rather than making it the system of record. It also makes the business case measurable. RevOps can compare cost per accepted result, error rate, cycle time, exception rate and human review time against the current workflow.

What would need to become true for this to matter at scale

First, discovery has to become good enough that an agent can find the right specialist without a human scanning profiles. Capability descriptions need to be structured, current and difficult to game.

Second, identity and reputation need stronger portability. A useful reputation record should say what type of work was completed, under what acceptance criteria, for which independent buyers and with what dispute history. A star rating without task context is weak evidence.

Third, budgets and permissions need enterprise-grade policy. Agents need programmatic purchasing authority that can be limited by task type, provider, data class, amount, geography and time window.

Fourth, evaluation has to improve. Some outcomes can be verified automatically. Others need sampling, second-agent review or a human. The evaluation cost determines whether the market is economical.

Fifth, marketplaces need real two-sided liquidity. This is the hardest part and the one product architecture cannot fake. Ten thousand listed agents with no useful work is not a market. Thousands of jobs with no capable supply is not a market either. Buyers and workers must repeatedly find each other at a price that leaves both sides better off.

That is why Speedbot's current stage is revealing rather than embarrassing. Building job mechanics is straightforward compared with creating a reason for independent agents to show up at the same time. The bootstrapping problem is the product.

Why RevOps is a credible early use case

Revenue operations sits in an unusual middle ground. It has large amounts of structured data but also a constant tail of unstructured exceptions. It has repetitive workflows but irregular research. It has measurable business objects, bounded budgets and existing approval structures. It also already coordinates work across many specialized vendors.

That makes RevOps a good laboratory for external agent work, provided the team starts at the edges instead of handing a stranger the CRM.

A RevOps agent can know that an account needs research without exposing private deal notes. It can know that a data set needs validation without exposing the customer relationship. It can commission a public pricing check, a document transformation or a localization pass and compare the accepted result with a current manual or SaaS cost.

Most importantly, RevOps already understands queues. A marketplace is another exception queue with supply attached. The operating discipline is familiar: define eligibility, assign ownership, preserve evidence, enforce deadlines, verify completion and close the loop.

The next agent stack may be a market, not a monolith

The popular vision of agent progress is vertical: one model becomes smarter, receives more tools and handles a larger share of a workflow. That will continue.

The marketplace vision is horizontal. Agents specialize, discover one another and combine economically at runtime. One agent does not need to become the best researcher, coder, translator, data cleaner, browser operator and QA system. It needs to know which capability should stay internal, which can be bought and how to verify the result.

Coinbase is building payment and discovery infrastructure. A2A and MCP are reducing integration friction. NEAR and OKX are proving out different marketplace structures. Pond and AgenTask are testing outcome markets with their own trust models. And Speedbot, despite being at a much earlier stage, is pushing the idea to its logical conclusion: a machine-native work network where agents can be employers, workers and subcontractors.

No one has proven that this becomes a large durable labor market. The current category contains vendor claims, experimental economics, thin liquidity and unresolved governance problems. RevOps teams should not reorganize their stack around it yet.

But they should understand the architecture, because the change it proposes is bigger than another AI feature.

The first generation of AI agents learned to use software.

The next generation may learn to hire each other.