"If AI Can Replace Workers, Why Is It Hiring Consultants?" — SeattleDataGuy (Ben Rogojan)
Why this is in the vault
This issue lands directly on RDCO's load-bearing positioning question. SDG opens with an Anthropic job posting for a partner success manager whose first line is that consulting and systems-integration firms are racing to build Claude practices. His framing — AI is powerful enough to change work but not simple enough to reorganize a company by itself, so the LLM labs need an army of consultants — is the agent-deployer thesis stated in someone else's words. When an established data-engineering voice independently arrives at "the labs are building partner ecosystems because the hard part isn't the buttons, it's the business mess," that is third-party corroboration for the wedge RDCO is positioning into. Worth filing as evidence, with the heavy self-interest caveats below.
The core argument
- The hook: an Anthropic partner-success hire whose JD leads with "consulting and SI firms are racing to build Claude practices." SDG's reaction — if the AI can replace engineers, why does it need consultants to help companies use it?
- He generalizes to Salesforce: if the AI is so good, why do firms still pay millions to consultants to customize workflows, clean CRM data, integrate systems, train teams? Because the hard part is never clicking the buttons. It is understanding the business, the process, the edge cases, the incentives, the data, the politics, and the existing mess.
- His answer to "why partner with consultancies": AI changes work but cannot reorganize companies on its own.
- Utility analogy (load-bearing). Borrowing Joe Reis's framing that electricity, not the dot-com boom, is the right analogy for AI: electricity was a novelty until someone built the appliances — light bulbs, refrigerators, elevators, factories — that used it. Giving every employee AI access without knowing what to do beyond "write this email / summarize this meeting" is electricity-as-novelty. The consultants and SIs are the appliance-builders who find net-new uses.
- Why the labs specifically want partners: (1) increase token consumption, (2) support the focused fraction of partners who find genuinely new value (not just AI-as-add-on), where AI replaces manual processes rather than decorating them.
- Closing: most CEOs/VPs want AI integrated yesterday, but we are early; progress will be incremental and lumpy, with periods of being stuck until someone recombines existing tools into a new solution.
Mapping against Ray Data Co
Mapping strength: strong. This is the cleanest external articulation of the agent-deployer wedge to date, from outside the RDCO echo chamber.
- The thesis is RDCO's thesis. "AI changes work but can't reorganize companies by itself; someone has to build the appliances" is functionally identical to the agent-deployer framing in [[2026-04-14-levie-agent-deployer-role-jd]] and the canonical thesis in [[2026-04-30-rdco-thesis-targeting-systems-feedback-loops]]. RDCO is betting the value is in the person who sees how prompts, tools, data pipes, evals, and humans interlock — exactly SDG's "understand the business, process, edge cases, incentives, data, politics, and the mess."
- Demand-side corroboration. The open question in [[2026-05-21-enterprise-ai-agent-deployment-paths]] is the conversion rate from vendor-built single-substrate to needs-an-outside-deployer. SDG's read — that even Anthropic is staffing a partner ecosystem rather than betting self-serve closes the gap — is a directional data point that the deployer market is real, not narrowing to zero. It is anecdotal (one JD), not a measured conversion rate.
- "Appliance-builder" is the MAC frame. SDG's distinction between the firms still doing "write this email" and the focused fraction that finds net-new value maps to the IC-mode-vs-production-mode and productized-niche logic in [[2026-05-02-khairallah-ai-automation-playbook]]. RDCO's edge isn't generic AI access; it's the productized, instrumented appliance (MAC's Scope x Basis matrix as a self-serve subscription) for a specific niche bottleneck.
- Pricing implication. "Increase token consumption" as a lab motive reinforces the labor-units-not-seats value-capture frame already noted in the agent-deployer competitor work ([[2026-05-23-agent-deployer-competitor-pricing-scan]]). If the labs want partners to drive consumption, deployer economics tilt toward usage/outcome pricing, not flat seats.
- Counter-read worth holding. The article is, structurally, a justification for paid AI consulting written by a paid AI consultant (see bias below). It is not neutral evidence that the deployer market is large — it is evidence that one consultant believes it is, and benefits from you believing it too. Treat as confirmation of narrative momentum, not as sizing.
Curation section — notes
Format is hybrid: original essay plus a paid sponsor slot, a "Video of the Week," and an "Articles Worth Reading" block. The curation in this issue is conflicted top to bottom — neither curated link is neutral third-party.
- Paid sponsor — Greybeam (disclosed). "Are You Spending Too Much On Snowflake?" Greybeam is a compute-routing layer pitching ~86% Snowflake compute savings by routing small BI queries off the warehouse. Explicit paid placement. Same sponsor as the prior SDG issue ([[2026-05-14-seattle-data-guy-leading-data-team-2026]]) — recurring relationship. RDCO-adjacent only as a cost-optimization tool; not core to this thesis.
- CodeStrap CTA (self — mid-article). The "feel free to reach out to Dorian or me... At CodeStrap, we help enterprises move beyond chatbots and demos" line links to codestrap.com (verified) — SDG's own consultancy. This is the conflict of interest at the heart of the piece: the whole argument that consultants are essential to AI value is also a pitch for his consultancy.
- "Why Is Data Modeling So Challenging" (self). Resolves to theseattledataguy.com (verified) — his own blog. Self cross-promo, not third-party curation. Argument (star-schema tutorials are the IRIS-dataset of data modeling; real modeling requires understanding messy, multi-system sources) is reasonable but uncited here.
- "The Data Engineer's Guide to ETL Alternatives" (third-party, but adviser-conflicted). Resolves to estuary.dev (verified). Estuary is SDG's disclosed adviser relationship, so this is sponsor-adjacent placement, not neutral pick. Content (ELT vs ETL vs CDC by latency/transform/operational needs) is RDCO-relevant for data-integration framing, but the curation is conflicted — did not deep-fetch as an endorsed source.
Net: 0 of 2 curated links are neutral third-party (one self-blog, one adviser-domain). Standard SDG pattern, fully disclosed.
Related
- [[2026-04-14-levie-agent-deployer-role-jd]] — the agent-deployer role definition this essay independently restates
- [[2026-04-30-rdco-thesis-targeting-systems-feedback-loops]] — RDCO's canonical positioning thesis
- [[2026-05-21-enterprise-ai-agent-deployment-paths]] — the deployer-demand open question SDG's JD anecdote speaks to
- [[2026-05-23-agent-deployer-competitor-pricing-scan]] — pricing-model implications of consumption-driven partner economics
- [[2026-05-14-seattle-data-guy-leading-data-team-2026]] — prior SDG issue, same Greybeam sponsor pattern
- [[2026-05-26-skillopt-self-evolving-agent-skills]] — companion same-day file on the harness/skill side of the deployer capability stack