engineering
Where Agents Still Need a Person
An agent can find a service and still need a person to use it. What 104 Sourcey product and job profiles show about discovery, access and human setup.
An agent can write the request, understand the response, and still be waiting for you to sign up, find the right settings page, create a key, and put a card on file.
That work disappears from the demo when somebody has already done it. It reappears when you try to connect the next service.
Sourcey’s readiness catalogue follows the whole path for a named job: finding the interface, getting access, onboarding, paying, confirming the result, and keeping the access working. It tells a developer where a person is still needed before they commit to an integration.
The distinction shows up clearly in the data. In the edition captured on 17 October 2026, 86 of 104 product/job profiles had machine discovery. Only two had machine access. In 85 profiles, getting access involved a workaround such as a person handing over a key.
The interface is often there. The ability to start using it independently is much less common in this cohort.
What the six steps reveal
The snapshot covers 102 entities and 33 named jobs across 104 profiles. It comes from public evidence and unauthenticated probes; every profile in this edition is labelled probed. These classifications describe the available path, not completed transactions inside customer accounts.12
| Step | Machine | Workaround | Approval | Gated | Not applicable | Not assessed |
|---|---|---|---|---|---|---|
| Discover | 86 | 17 | 0 | 0 | 0 | 1 |
| Access | 2 | 85 | 15 | 0 | 1 | 1 |
| Onboard | 13 | 76 | 2 | 11 | 1 | 1 |
| Pay | 1 | 43 | 0 | 0 | 59 | 1 |
| Confirm | 96 | 7 | 0 | 0 | 0 | 1 |
| Sustain | 32 | 70 | 0 | 0 | 1 | 1 |
“Workaround” has a specific meaning here: a person performs work on the agent’s behalf. That might mean signing up once, passing over a credential, or repeatedly topping up a balance. “Approval” is a bounded decision by the person the agent acts for. “Gated” means the vendor decides whether to grant access, through sales or approval.
Those categories matter more than a single percentage. Payment is not applicable to 59 profiles, so counting them as either payment failures or autonomous purchases would distort the picture. A one-time credential handoff and a recurring manual top-up both involve a person, but they make very different demands on the person operating the system.
The table also shows why an API catalogue alone cannot answer the readiness question. Discovery, confirmation, and ongoing access have different distributions. A service can be easy to find and have clear responses while still depending on somebody to provision and maintain access.
The payment row needs its own denominator. Fifty-nine profiles have no applicable payment step, and one was not assessed. Of the remaining 44, one has a machine path and 43 need a workaround. Dividing that one by all 104 would mix services that need payment with services that do not.
A workaround also has a frequency. Consider two hypothetical integrations: one needs a person to create a credential once; the other needs a person to approve every balance top-up. Both involve a human, but the second keeps interrupting the running job. Record whether the work happens at setup, on each transaction, or at renewal before deciding which integration costs less to operate.
The starting point changes the integration
Consider three teams asking an agent to send an email.
One already has a verified sender, a funded account, and a scoped integration. Another has no account. A third has a key but has not authorised this agent to send to the intended audience.
The sending endpoint could be identical. The next step is different for each team. The first may be ready to send. The second needs provisioning. The third needs a decision about authority, which copying another code example will not supply.
A comparison that gives one service an administrator token and starts the other in an anonymous browser is comparing different starting points. It can make a familiar service look wonderfully autonomous simply because its setup has been forgotten.
When planning an integration, write down which account and permissions already exist. Separate what you need to do once from what will interrupt every run. Sourcey’s step evidence gives that planning somewhere to start: the interface, the access route, and the human actions attached to the job.
A company does not have one readiness grade
A provider might offer several products with different account systems and access rules. Even within one product, reading data and making a consequential change can require different permissions. A company-wide badge hides those differences.
Sourcey binds a report card to a product and a job. The job comes from a shared library so comparable services are assessed against the same task.3
For example, the captured model-chat-stream-tool group contains OpenRouter, OpenAI, Anthropic, Fireworks, NVIDIA NIM, DeepInfra, Together, and Cerebras. OpenRouter and NVIDIA NIM were B+ in this edition; the other six were B.
Those letters describe how much human help the access path needs. They say nothing about which model writes better code. Model quality, price, latency, and the application’s requirements still belong in the selection. The report card answers another question: what will it take to get this particular job running?
A team with the accounts already established may be comfortable with the setup work behind a B. A system expected to discover and provision services as it goes has a different requirement. The same evidence can support different choices once the starting conditions are explicit.
Keep the decisions that belong to people
Sender verification, account ownership, and consent to spend money have purposes. A shorter path is not automatically a better one if it removes a decision the owner wanted to make. The Agent Problem follows that question further: what authority are we actually handing over?
There is a difference between asking someone to approve a bounded action and asking them to navigate a dashboard on every run. The first can express authority. The second may be work an integration could perform after that authority has been granted.
For a service builder, this is a practical design question. Can the customer authorise a class of work? Can the agent acquire and maintain the appropriate access? When the scope changes, can the customer see what new decision is being requested?
The provider also has to account for billing, security, abuse prevention, and people affected by the action. An integration that sends messages has responsibilities to recipients as well as convenience to offer the sender. Readiness needs to describe where those decisions occur, rather than treating every person in the path as an obstacle.
What happens after the quickstart?
The first request is only the beginning of an integration you intend to keep using.
A credential expires. A balance runs low. The owner revokes access. The system needs to establish whether a request succeeded. These events determine whether a workflow can keep running within the permission it already has or needs somebody to step in.
In this snapshot, 70 profiles had a workaround at the Sustain step and 32 had a machine path. Sustain specifically asks whether the agent can keep access alive and revoke it. The timing attached to a workaround tells you whether the person acts at setup or has to return later.
Read that timing before estimating operating effort. A one-off setup action spread across thousands of subsequent operations is a different proposition from a task that returns every afternoon. The number of affected profiles alone cannot tell you how much work either creates.
Use the catalogue to plan the work
Start with the job you want to delegate. Open its Sourcey report cards, compare the step evidence, and mark the setup your team has already completed. For every remaining human step, identify the person who can perform it and whether they will have to do it again.
Then run the job under the account and permissions you intend to use. Record the starting conditions and confirm the result. The public assessment tells you what path is available; that account-holder run establishes what happened in your environment.
Keep the date and methodology with any comparison you save. A provider can change its access model, and a corrected classification can change a grade without the provider changing anything. Follow the underlying evidence when a report card moves, especially if your integration decision depends on it.
Footnotes
-
Sourcey, agent-readiness dataset, checked 17 October 2026, Catalog release 356. The retained release links its immutable bundle and verifier. The current dataset continues to change; the counts here refer to that release. ↩