An agent-heavy supplier needs a capacity story you can question

TechCrunch reports a $410 million compute agreement between Recursive Superintelligence and AWS. That is enough to make me add a page to an AI supplier review: the capacity assumptions behind the service we are buying.

The contract amount is not a measurement of useful work. It does not tell a customer how many tasks will finish, how much supervision they require, or which service commitments remain feasible under load. Yet it points to a dependency that a founder biography and an employee count cannot explain.

My bet is that diligence for an agent-heavy supplier will increasingly resemble a capacity review. People still matter. So do the resources the people and their agents can actually use, on the terms the company has accepted.

Ask what the commitment makes possible

A large compute commitment can secure resources and improve commercial terms. It can also create obligations before demand or product performance is fully known. Which interpretation fits a particular agreement depends on provisions a public announcement rarely supplies.

I would not infer cash already spent from a multiyear headline, or assume the entire amount is immediately available capacity. Nor would I divide the contract value by a token price and call the result productive agent labour. That calculation skips utilisation, retries, development work and the quality threshold for a completed task.

For an enterprise buyer, the more useful question is narrower: what delivery assumption does the supplier make that could affect our workload? If its promise depends on obtaining a certain class of compute, the buyer should understand how access, substitution and reduced capacity are handled at the service boundary.

That does not require demanding an unredacted commercial contract. A scoped explanation of dependencies, a capacity test and a clear service commitment may be more appropriate than access to confidential pricing.

Put accepted work into the conversation

Consider a hypothetical document-analysis supplier promising to process a customer’s weekly intake overnight. I would ask it to demonstrate the agreed workload at representative volume and document complexity, with a fixed acceptance standard. Record accepted outputs, review backlog, elapsed time and the resources consumed.

Then reduce the available capacity in a controlled exercise. Which jobs wait? Does the service preserve work already completed? Can the customer see the revised delivery expectation? A supplier that explains the degraded mode clearly gives the buyer something concrete to plan around.

The exercise would not establish the supplier’s solvency or validate its whole business model. It would test one operational promise. Financial health, contractual remedies and technical resilience require their own evidence and their own owners.

The employee metaphor can obscure this separation. A person assigned a job brings an employment relationship, judgement and organisational responsibilities. An agent label may describe anything from a short scripted task to a persistent system using several services. Counting those labels does not reveal the bottleneck.

I would therefore keep the job map and add the dependency map. Who owns the outcome? What resource makes the work possible? What happens when that resource is constrained? Those questions connect the operating model to what the customer experiences.

The announcement is a prompt for that inquiry, not proof that a cloud agreement has replaced a company’s organisation. The useful diligence remains stubbornly specific: show the work you can sustain and the assumptions that make the promise hold.

Treat a compute commitment as a dependency to understand, and ask the supplier to demonstrate the customer outcome it can sustain.