A squad of five engineers and four AI agents missed its sprint, despite producing more work than ever. Overnight, the agents had turned a customer call into 12 user stories, run 1,200 regression tests, fixed three bugs, and reviewed every pull request. Yet reviews piled up, two stories were built perfectly against the wrong requirement, and a bug the agent passed reached a customer. When leadership asked who owned it, no one had an answer.
That squad is not an outlier. In McKinsey’s May 2026 survey of 334 product and engineering leaders, 25 percent of director-level and above respondents said more than a quarter of their teams had doubled productivity with AI, while 30 percent said productivity had fallen. Both groups had access to largely the same tools. What separated them was whether they changed how work was defined, checked, and owned once agents joined the team.
A human-agent squad is a delivery team in which AI agents plan, build, test, and review work alongside engineers, with people accountable for the outcomes. This blog looks at what organizations on the right side of that divide do differently: how they define intent so agents build the right thing, verify agent output without creating a review backlog, assign ownership that lasts after release, staff teams for judgment, and measure whether the redesign is working. These practices were the focus of Harbinger’s Power Hour, From Agile Squads to Human-Agent Squads: How AI Agents Are Redesigning Software Delivery, hosted by Shweta Kulkarni, Vice President and Head of AI at Harbinger Group, with Ken Levy, CTO at The Ohana Way, and Nikita Jain, Founder and CEO at Eubrics AI. Watch the complete recording below.
Defining Intent Before Agents Start Building
The two stories built against the wrong requirement point to a problem that starts before any code is written. People fill gaps in a requirement through conversation and shared context. Agents fill them with assumptions, quickly and at scale. Teams that get consistent results address this in two ways.
Write the Plan Agents Will Build From
One effective workflow moves each feature from product requirements to technical documentation, wireframes, and a development plan that is itself a sequence of agent-ready prompts. People review that plan before anything is built, which places their attention where a correction costs the least. Because agents work from written plans, they can also keep documentation current with every change, along with a short log of why each decision was made. On an early healthcare chatbot built under strict data residency rules, Harbinger documented requirements in full and tested thousands of prompts in staging before launch. The project started more slowly and finished faster overall.
Keep Tasks Narrow
How work is divided matters as much as how clearly it is written. Large, open-ended tasks give agents room to improvise.
“As soon as you start complicating tasks for AI, it starts taking its own judgment calls, and reliability of output becomes much lower,” said Nikita Jain. “So the more granular pieces you can create, and make AI run them, and then orchestrate them as a human being, the more precise your output would be.”
Narrow tasks also force a decision about context. A sales coaching product serving retail, insurance, and banking cannot rely on AI to infer what good selling looks like in each industry. People have to choose the playbooks and data it draws on.
Verifying Agent Output Without Becoming the Bottleneck
A clear plan explains what agents should build, but it does not explain why reviews piled up. When agents produce work faster than people can check it, unverified output accumulates like technical debt. McKinsey’s survey shows average time savings of 11.8 percent against an average rework reduction of only 6.2 percent. Google’s 2025 DORA research, based on a survey of nearly 5,000 technology professionals, explains why: AI acts as a mirror and a multiplier, boosting efficiency in cohesive organizations and highlighting weaknesses in fragmented ones.
The answer is to change who does the first rounds of review, not to ask people to review more. Effective teams borrow a principle finance and audit teams have long relied on: whoever produces the work should not approve it. Code is built with one model and reviewed with another, in layers, by agents configured as a security expert, a quality assurance expert, a code quality expert, and a senior developer. Because each reviewer role is a short written definition, quality no longer depends on which engineers happen to be on the team that sprint.
Exploratory testing then follows a simple escalation rule: the agent fixes the findings it is confident about and raises everything else as questions. Leaders can widen or narrow that boundary as trust grows, while a person still tests before anything goes live.
AI-Powered Payroll Decision Support: Building Trustworthy, Auditable AI for Federal Payroll Decision-Making
AI accelerated requirements, code, and testing for a federal payroll technology provider, while each artifact was audited separately so AI did not sign off on its own output.
| Agents added to an existing squad | Squad redesigned around agents | |
|---|---|---|
| Requirements | Narratives interpreted in conversation | Development plan of narrow, agent-ready tasks |
| Review | The same tool builds and checks | A different model reviews, in role-based layers |
| Agent authority | Undefined | Escalation rule for what agents fix and what they raise |
| Documentation | Written once, then outdated | Updated with every change, with a decision log |
| Senior time | Spent catching up on reviews | Spent on architecture, judgment, and outcome testing |
| Manual recommendations | Knowledge + experience-centric | Context-aware recommendations |
| Periodic/manual lifecycle management | Knowledge + experience-centric | Governed, ongoing lifecycle management |
Assigning Ownership That Lasts Beyond Release
Once agents handle line-by-line checks, people no longer read every change. That leaves the question the squad could not answer: if no person reviewed the code that failed, who is accountable? In a human-only team, accountability follows whoever wrote or approved the code. When agents do both, ownership has to be assigned deliberately, and it has to outlast release.
“Nobody changed any code or wrote any bad line of code, but the data moved,” said Shweta Kulkarni. “That taught me something: in the AI world, someone has to own the outcome over time. It is not just about the code.”
What the Senior Role Owns Now
Owning outcomes redefines the senior engineering role. The person leading a human-agent team owns the architecture, security, business requirement, and whether the product works for the people using it, rather than individual lines of code.
“You don’t have to know how to implement,” said Ken Levy. “You don’t have to know the syntax, you have to know the semantics.”
Practitioners still differ on structure. Some argue each person should lead a team of agents, while others favor orchestrated teams with defined roles for people and agents. Either way, every outcome needs a named human owner, and that ownership does not have to slow delivery.
Human in the Loop Testing: Improving QA Performance with Agentic AI and Freeing QA Teams to Focus on Higher-Value Work
QA experts approved every agent output before execution for a global background-screening enterprise, and test-script effort still fell by about 49 percent, from 180 minutes to about 92 minutes including human validation.
Building the Evidence Trail
Ownership also needs evidence. Gartner predicts that more than 40 percent of agentic AI projects will be canceled by the end of 2027, partly because of inadequate risk controls. Compliance standards may eventually accept AI review under defined checks, overseen by people, in place of a person reading every line. Teams that already record what each agent checked and who approved the result will be ready when they do.
| SDLC stage | Agents execute | Humans own | Evidence produced |
|---|---|---|---|
| Requirements | Draft stories, acceptance criteria, documentation | Intent, priorities, trade-offs | Reviewed development plan |
| Build | Generate code to defined standards | Architecture and security decisions | Layered review findings by role |
| Test | Author and run tests, escalate open questions | Risk tolerance and the release decision | Human test sign-off |
| Run | Monitor behavior and flag drift | The outcome over time | Named owner and decision log |
Staffing Human-Agent Squads for Judgment
Every row in that table assigns people the work that depends on judgment, which makes judgment the scarcest resource on the team. Squads are already shrinking: among top-performing organizations in McKinsey’s survey, the median squad fell from about ten people to seven after AI implementation. Each person now reads and decides more than they write, and teams can shift agent capacity toward testing in a release-heavy quarter or requirements in a backlog-heavy one.
The harder question is where future judgment will come from. Stanford Digital Economy Lab’s 2025 study found a 13 percent relative decline in employment for US workers aged 22 to 25 in the occupations most exposed to AI, including software development. Entry-level work was where engineers built judgment, so organizations need a deliberate substitute: smaller projects led by experienced engineers, with early grounding in architecture, security, and managing AI.
Measuring Outcomes and Raising the Baseline
A team staffed for judgment still needs a signal that the redesign is working. Stories drafted and tests run say little about whether a sprint will deliver. An engineer who spends two days solving a problem in 12 elegant lines of code delivers less than one who solves the business problem in six hours. Release quality, time to value, and issue resolution time say far more.
Outcome measures also reveal something activity metrics hide. Because each iteration now costs so little, teams do not have to stop once a target is met. The more ambitious ones aim for twice and then five times the original outcome.
These practices work as a single system. Written intent makes independent review possible, review makes ownership practical, ownership defines the judgment teams need, and outcome measures show whether it is all working. For engineering leaders, the question is direct: if agents doubled your team’s output tomorrow, could your organization verify, own, and stand behind all of it? A practical first step is to choose one high-value workflow, map it from requirement to production, and identify where intent, review, or ownership is still implicit. Contact us to discuss where to begin.
