跳到正文
DEV Community· yagato·· 3 小時前AI 評分58

作者分析 Sourcey 的 105 份 Agent 就緒度評分卡，發現沒有一項 SaaS 工作可完全無人介入

105 Agent-Readiness Report Cards Later: Not One SaaS Job Is Fully Hands-Off

AI 導讀

作者核對 Sourcey 發佈的 105 份 SaaS 工作 Agent 就緒度評分卡及底層 JSON，發現沒有一項工作的六個步驟全由機器完成，102 項至少需要一次人工介入。

正文

I keep one rule for any paid API I hand to an agent: if a human has to stay in the loop, I want to know which step and how often, before I depend on it. A dozen days of building against paid APIs gave me anecdotes. I wanted a census.

The census exists. Sourcey publishes agent-readiness report cards for individual SaaS jobs: a grade, a per-step breakdown, and a signed release behind the data. I read all 105 published profiles plus the underlying JSON, and counted.

What I actually read

Each card grades one job (not one product) across six steps — discover, authority, onboard, pay, confirm, sustain — and each step is one of machine, workaround, approval, gated, not_applicable, not_assessed.

The headline: not one job is fully automatic

Grade A+ A B+ B C D F Total
Profiles 2 10 39 35 7 11 1 105

0 of 105 profiles pass all six steps as machine. 102 of 105 need a human at least once. So the useful question is not "can an agent do this" but "where does it stop".

Where it stops, step by step

Step machine Other outcomes
discover 86 / 105 18 workaround, 1 not assessed
authority 2 / 105 86 workaround, 15 approval, 1 n/a, 1 not assessed
onboard 13 / 105 77 workaround, 11 gated, 2 approval, 1 n/a, 1 not assessed
pay 1 / 105 60 n/a, 43 workaround, 1 not assessed
confirm 97 / 105 7 workaround, 1 not assessed
sustain 32 / 105 71 workaround, 1 n/a, 1 not assessed

Read that table twice. confirm — can the agent tell success from failure? — is essentially solved: 97 of 105 are machine-readable. The wall is authority and pay: only 2 profiles let a machine handle authority, and exactly 1 lets a machine handle payment. Between the two, 43 profiles need a human with a card.

Freshness matters here, and this census is not stale: 71 of the 105 profiles were last run on 2026-10-13, 22 on 2026-10-12, 9 on 2026-10-11.

Two email APIs, one grade apart

In a docs screenshot, most transactional email APIs look the same. Their cards do not:

A full letter of grade difference hides behind one word: gated. If an unattended job is the goal, these cards narrow the list before I write a line of code.

What I changed in my own workflow

  • I read the card before I write the client. The authority and onboard rows tell me whether a human is required before I promise a headless run.
  • I treat approval and gated as stop signs, not warnings. For those vendors I prepare the request so a human spends one click, not thirty minutes.
  • I re-pull the JSON and diff digests. release_id, artifact_sha256, root_set_digest and signer_registry_digest are in the files, so a stale card is detectable. Every material change is also appended to https://sourcey.com/changes.ndjson.
  • I count jobs, not products. A vendor can have one easy job and one gated job; the card is per job.

The honest caveats

  • A card grades one job under one policy version (kind-2026-10-12) at one probe run. Vendors change; the probe date is on every card.
  • not_assessed is not machine. One profile is unassessed and one is F (unavailable) — I did not round those up.
  • These are vendor-declared surfaces probed by Sourcey under published rules, not my own test of each API. The methodology page states exactly how a step is judged.
  • The data is CC BY 4.0 and the release is signed; I cite the release digest above so anyone can re-derive every number in this post from the same bytes.

Where to go next

Disclosure: a bounty asked for a citation of Sourcey, so I am citing it. The counts, the step table and the examples above are my own reading of the published JSON files, and the release digest is given so you can check them.

來源：DEV Community · dev.to

#現象/趨勢#Agent