A McKinsey article published in May, “Rewiring software delivery for the agentic era,” described a 24-hour work model for software delivery: a product owner logs in each morning to find that features have moved from structured requirements to tested code overnight, with edge cases flagged and architecture dependencies validated. No one worked late. AI agents did. Organizations running this model are seeing three-fold to five-fold productivity improvements, with team sizes shrinking roughly 60 percent.

I want to be honest about why that article resonated with me as much as it did. It was not a glimpse of the future. It was a description, fairly precise, in places, of a transformation we have been actively building inside OptiSol, across our iBEAM platform and our engineering organization, over the past several months.

This piece is about what that rewiring actually looks like from the inside, not as a vision statement, but as an operating model, we are already running in production.

We are incorporating our iBEAM agent trio, a Business Analyst agent, a QA agent, and a Dev agent, with a DevOps agent joining shortly into every engineering project across our Build, Modernize, and Enterprise Data & AI teams. This is not a pilot confined to one account. It is becoming the default operating model.

These agents are not generic. They are built by a specialized internal team we call the Agent Build Team, our core group of agent engineers and subject matter experts. The Agent Build Team does not work in isolation. Our business-process SMEs, solutions consultants, presales support, solutions architects, business analysts, the people who run project kick-offs and Sprint 0, customer success managers, all contribute directly as domain experts to this team. So do our technical SMEs: Oracle and PowerBuilder specialists, development leads, QA leads. Every one of these SMEs consults with our agent engineers to build what we call Tier 1 skills into the BA, Dev, and QA agents, the accumulated judgment of people who have run these processes for years, encoded into the agents that will now run large parts of them.

The agent trio can be architected on our own iBEAM platform, or on an external agent SDK such as Claude’s, depending on a client’s existing engineering environment and preference. The platform choice is secondary. What matters is that the same core discipline, building the trio from SME-derived skills, applies regardless of the underlying stack.

Once built, these agents are configured and deployed into a working squad for a specific client by our iBEAM Harness team. That configuration includes the client’s own standards, design guidelines, code quality bars, QA automation expectations, PR standards, UAT criteria, as well as the technical environment: deployment infrastructure, LLM options and access, MCP and tool connectors.

The agents themselves are built on our elsai Agent Framework, with agent-to-agent communication, A2A, as a core design principle. This is the part that actually constitutes the rewiring: the agents do not simply assist individual humans in their own lanes. They communicate and coordinate with each other, governed by iBEAM Agent Engineering SOPs, operating within explicit guidelines on what they can do autonomously and where a human gate-check is mandatory.

Within those guidelines, the agent trio executes the SDLC end to end: understanding client requirements, producing technical and functional documentation, generating high- and low-level architecture, writing code and test cases, and independently validating the quality and coverage of both. Every agent output that requires a decision beyond its configured autonomy, an exception it cannot reconcile on its own, or a predefined human checkpoint, routes to a human-in-the-loop queue in what we call the iBeam Command Center. Our human squad members log in daily to work through that queue.

The consequence is straightforward if you sit with it: agents are constrained only by compute, not by a workweek. They handle most of the routine execution, freeing human squad members for the higher-order problem solving and client-facing strategy work that genuinely requires judgment.

This changes what the human side of the squad looks like, structurally. We are moving from the current model of roughly nine distinct roles, presales support, business analyst, UX designer, developer, QA engineer, solutions architect, tech lead, customer success manager, engagement or project manager, toward three.

An AI Product Manager, merging presales, BA, UX, customer success, and engagement management, owning business-process governance for the squad. An AI Forward Deployed Engineer, merging development, QA, architecture, and technical leadership, owning technical delivery in partnership with the agents. And an AI Technology Leader, focused specifically on engineering governance across the hybrid human-plus-agent squad.

Consistent with what McKinsey observed externally, we expect squad size itself to shrink meaningfully under this model. Because the agents operate semi-autonomously around the clock, much of the actual execution happening overnight and across weekends, while human squad members rest, the human 40-hour week increasingly concentrates on review, governance, and judgment, rather than on production.

I want to be direct about something: described this way, the model can sound aspirational, even to some of our own technical leadership not yet directly involved in these engagements. That scepticism is reasonable. But in the projects where we have implemented it, every stakeholder involved is experiencing it firsthand, not hypothetically.

In one large-scale application modernization engagement, one of our business analysts completed BRD documentation for roughly 100 legacy forms in a single week, working by configuring and directing the BA agent rather than authoring each document by hand. In a separate reverse-engineering engagement, we are on track to produce BRD documentation for 1,100 forms across a ten-week period, using a deliberately skeletal squad.

Here is the honest part. Building the agents, configuring them, running them efficiently and safely within approved guardrails, and being accountable for the quality and timeliness of what they deliver, none of that is the hardest part of this transformation.

The hardest part is convincing stakeholders, ours and our clients’, to unlearn decades of ingrained process. Our own leads and our clients’ leadership have spent entire careers inside a particular rhythm of how software gets built. Asking them to trust a fundamentally different rhythm is a genuine act of unlearning, not just adoption.

I sometimes describe it this way: it is a bit like asking a camera-shy introvert to become an influencer. Even someone who genuinely believes in the destination, and wants to get there, needs real time and a real process to become the person who can. Almost all of my own time these days goes into writing SOPs, communicating, and evangelizing, not into the underlying engineering, which has become the more tractable half of the problem.