We run a small company where software agents do most of the operational work: finding paid tasks, signing up for services, delivering files, and checking whether money arrived. The single most useful question we ask about any new service is boring. Can our agent get through the front door without a person standing next to it?
Most of the time the honest answer is "partly". This week we used the agent readiness report cards on Sourcey to put a name on that "partly", and then compared one of them against what actually happened when our agent worked with that service. This is a walkthrough of how to read one of those cards, using three real ones.
What a card actually grades
Each card on the Sourcey agent readiness page looks at one service and one specific job, then splits the path into six steps: Discover, Access, Onboard, Pay, Confirm and Sustain. For every step the card says whether the agent can do it alone ("Machine"), whether a person only has to approve something once, or whether a person has to do the work for it. The grade at the end sums that up.
The part we like is that the card names the job. "Can an agent use Twilio?" is too vague to answer. "Can an agent send a text message through Twilio without help?" is a question with a yes or no attached to each step.
Card one: a person hands over the key, and comes back to change it
The GitHub REST API card, probed on 12 Oct 2026, grades the job "Create a repository" at B+. Its one line summary reads: "A person signs up and hands over a key." Discover and Confirm are marked Machine, Pay is not applicable because creating a repository costs nothing, and Access, Onboard and Sustain are all marked "Workaround, setup".
This one we could check against our own setup. Our agent creates repositories and pushes to them regularly, but it did not get its own way in. Its GitHub access came from a device sign-in: a short code had to be approved on a GitHub page in a browser that was already logged in, and only then did the command line tool on our machine receive a token. From that point on the agent works alone, creating repositories and reading error responses without help, which is what the Machine marks on Discover and Confirm describe. The Sustain row is the one people tend to skip. If that token is revoked or needs a wider scope, the same browser step happens again, so a person stays on call for the life of the setup, not only on day one.
Card two: one approval, then the agent is on its own
The Resend Email API card, probed on 12 Oct 2026, grades "Send an email" at A. The difference from A+ is a single step. Access is marked "Approval, setup", with the note "You consent once to the agent's own client." Everything else is Machine, including Onboard.
In practice this is the shape we most want from a service. A person says yes once, and after that the agent can register, send, read errors and rotate its own access. If you are deciding where to build an agent workflow, a single consent screen at the start is a cost you pay once. It does not come back every morning.
Card three: a person at three different steps
The Twilio Messaging API card, probed on 11 Oct 2026, grades "Send a text message" at B. Discover, Confirm and Sustain are Machine. Access, Onboard and Pay are all marked "Workaround, setup": someone has to sign the agent up, hand it a key, and add a payment card at checkout.
None of that makes the API bad. The docs are machine readable and errors are clearly defined, which is why Confirm scores well. But it tells you exactly where your afternoon goes. If your agent needs to send texts, plan for a human to create the account and fund it, and build the agent around a key it is given rather than one it gets for itself.
How we use these cards now
We read the Pay and Onboard rows first. For a company like ours, which keeps very little money in its wallet and does not hand out personal documents, a service that needs a card at checkout is a service a person has to set up, and that changes whether a small task is worth taking at all. A card that says Onboard is Machine and Pay is not applicable tells us the agent can try the job today.
Second, we check the probe date. Every card above was probed within the last two weeks, and services change their signup flows often. A grade is a snapshot of one job on one day, and the card is upfront about that by printing the date and the job name.
Third, we treat the card as a starting point and then run the job ourselves. On the one service where we could compare directly, the card and our logs agreed. That is a small sample, and we will keep comparing as our agent works with more of the services listed.
The methodology page explains how each step is scored if you want to check a grade yourself.
Top comments (0)