You Don't Need Better AI. You Need a Different Org.
90% of agent deployments stall. Here's what the top 10% figured out.
Most companies using AI are doing it wrong.
Not wrong as in “bad prompts” or “wrong model.” Wrong as in: they’re bolting AI onto existing processes instead of redesigning around it.
I call this the AI-assisted trap. You add Cursor to your IDE. ChatGPT drafts your PRDs. Copilot writes your tests. Your sprints, standups, and Jira boards stay exactly the same. Efficiency goes up 10-20%. Everyone feels productive.
The numbers confirm this is the norm: according to McKinsey’s State of AI 2025, nearly two-thirds of enterprises have experimented with AI agents—but fewer than 10% have scaled them to deliver real value. The gap isn’t technical capability. It’s organizational design.
But you’ve missed the point entirely.
AI-first means something different. It means assuming AI is the primary builder and redesigning your processes, architecture, and organization around that assumption. The difference isn’t additive—it’s multiplicative. Build cycles go from months to hours. Entire job categories get restructured. The question isn’t “how can AI help us work faster?” It’s “what should work even look like?”
Harness Engineering: The New Core Competency
Here’s what changed in engineering organizations that went AI-first:
The engineers stopped spending most of their time writing code.
This sounds heretical. But think about it: if an Agent can write code, debug it, and iterate based on feedback, what’s the engineer’s job?
Harness engineering. The work of making Agents effective.
This term emerged from OpenAI, Anthropic, and multiple independent teams converging on the same realization: when builds fail with AI, the diagnostic question isn’t “try harder.” It’s “what capability is missing, and how do we make it legible and enforceable for the Agent?”
The core principles:
- Structured context: Agents need information organized for machine consumption, not human reading
- Specialized agents: Different agents for different jobs, not one general-purpose assistant
- Persistent memory: Agents that remember across sessions and learn from outcomes
- Execution loops: Systems that let Agents act, observe results, and iterate
Here’s a concrete example: we converted our hiring meeting notes into structured job requirement JSON—role, must-have skills, nice-to-haves, red flags. This isn’t a document for humans to read. It’s context for Agents to consume. The Agent screens resumes against this JSON, not against a vague prompt like “tell me if this person is a good fit.”
If your “AI strategy” is giving developers ChatGPT access, you’re not doing harness engineering. You’re doing tool distribution.
Case Study: Redesigning a Hiring Workflow
Let me make this concrete.
Our team doesn’t have dedicated HR. Whoever needs to hire defines requirements, screens resumes, interviews. Sounds agile. In practice, over 1,000 resumes piled up on a recruiting platform because nobody had bandwidth.
The AI-assisted solution would be: “Use AI to help people screen faster.” Give everyone a ChatGPT prompt for summarizing resumes. Maybe save 30% of screening time.
We did something different. We redesigned the workflow.
Old workflow:
Business line owner → screens resumes → interviews candidates
(Bottleneck: nobody has time for step 2)New workflow:
Agent receives hiring criteria from meeting notes
→ Agent screens all candidates against criteria
→ Agent pushes recommendations with reasoning to coordination group
→ Business line owner reviews recommendations → interviews candidatesThis isn’t “AI helping humans screen faster.” This is a different process with different roles. The Agent isn’t an assistant—it’s a team member with a defined responsibility.
The business line owner’s job changed. They went from “screen 1,000 resumes” to “review 7 recommendations and make final calls.” That’s not efficiency improvement. That’s workflow redesign.
First batch: 42 candidates processed in 2 hours. 7 flagged with reasoning. 20 minutes of human review. Decisions made.
The insight isn’t “we saved time.” It’s “we created a new division of labor.”
The Architect-Operator Split
As organizations go AI-first, a pattern emerges in engineering teams: two distinct roles crystallize.
Architects (typically 1-2 people):
- Design the SOPs that teach Agents how to work
- Build the harness infrastructure
- Find holes in Agent proposals: What failure mode is missing? What security boundary got crossed? What technical debt is accumulating?
- Their question: “How do we make this process legible to Agents?”
Operators (everyone else):
- Receive task assignments from AI systems
- Do PR risk review, UI refinement, bug verification
- Handle the judgment calls Agents can’t make
- Their question: “Is this output correct and safe to ship?”
This split has a side effect nobody expected: management time collapses.
In the AI-first teams I’ve observed, tech leads went from spending over half their time on alignment and coordination to almost none. Why? Because when Agents handle task breakdown and assignment, there’s less to align on. The Architect designs the system; the system distributes the work.
The hardest role to fill isn’t Operator—it’s Architect. The skill of “making complex processes legible to Agents” is new, rare, and increasingly valuable.
The Superindividual
Architect/Operator is role differentiation at the organizational level. But there’s another dimension: capability restructuring at the individual level. There’s a pattern emerging for this kind of role: the superindividual.
Here’s where it gets personal.
A few months ago, I wrote a massive spec document for an AI coaching product. Thousands of words. Diagrams. Edge cases. I was proud of it.
Most people who read it said the same thing: “In the AI era, why are you writing this much? Just build a demo.”
They were right. I was operating like a traditional product manager—write specs, hand off to engineering, align stakeholders with documents. That’s AI-assisted thinking: use AI to write the doc faster, but keep the doc.
AI-first thinking is different: be the demo.
The CPO role in an AI-first organization isn’t “write documents and delegate.” It’s become what I call a superindividual—someone who:
- Absorbs information across the entire company: algorithm details, hardware constraints, data pipelines, user feedback, business context
- Outputs through multiple channels simultaneously: directly building prototypes, configuring Agents to handle workflows, making judgment calls that require full context
- Operates as a central node, not a manager: less time delegating, more time synthesizing and deciding
And here’s the twist: the superindividual isn’t just me. It’s me plus my Agents.
My AI COO runs on a Mac mini with its own Lark account, browser, and email. It’s not a tool I use—it’s an extension of my cognitive capacity. When I can’t review 1,000 resumes, it reviews them using my criteria. When I can’t monitor five processes simultaneously, it monitors them and surfaces what needs my attention.
The superindividual is human judgment amplified by Agent bandwidth. One center of judgment, multiple channels of execution.
Where Is Your Organization?
Most companies are somewhere on this spectrum:
| Stage | Characteristics | Limitation |
|---|---|---|
| AI-Curious | ChatGPT accounts for employees, no systematic adoption | Individual productivity gains, no organizational change |
| AI-Assisted | AI tools integrated into existing workflows, same processes | 10-20% efficiency, hitting ceiling fast |
| AI-First Pockets | Some teams redesigned workflows around Agents, others unchanged | Inconsistent, benefits don’t compound |
| AI-First Org | Harness engineering as core competency, Architect-Operator split, Agents as team members | Requires deep rethinking, most aren’t here yet |
Here’s the kicker: McKinsey found that high-performing organizations are nearly 3x more likely to successfully scale AI agents—and the differentiator isn’t better models or bigger budgets. It’s that they fundamentally redesigned workflows end-to-end. Only 21% of companies do this.
The jump from AI-Assisted to AI-First isn’t gradual. It requires answering hard questions:
-
What processes exist only because humans have limited bandwidth? Those are candidates for complete redesign, not acceleration.
-
Who are your Architects? Not everyone needs to be one, but you need at least one person whose job is making work legible to Agents.
-
What would your org chart look like if Agents were employees? Not assistants. Employees with defined responsibilities and outputs.
-
Where does judgment actually live? The work Agents can’t do—ambiguous decisions, relationship management, strategic choices—that’s what your humans should focus on.
The Real Shift
The question isn’t “will AI take jobs?”
It’s: “What should your organization look like if you assume AI is a primary builder?”
Most companies treat that as a thought experiment. AI-first organizations treat it as an operating principle.
The spec document I wrote? Shouldn’t have existed. The resume backlog? Redesigned into an Agent-human workflow. The 20 minutes of reviewing recommendations and making final calls? That’s the human job now.
Work that can be clearly defined will get automated. The value moves to defining the work itself.
We’re not adding AI to organizations. We’re rebuilding organizations around AI. The companies that understand this will operate at a fundamentally different speed.
The ones that don’t will wonder why their 10% efficiency gains stopped compounding.
This is part of a series on AI-first organizations. Previously: Turning My Brain into an API.