What Works, What Doesn’t, and What to Look For
Nearshoring has been around long enough that most of its advantages no longer need much introduction.
In simple terms, it gives U.S. companies access to new pools of remote technical resources that work within nearly the same time zones as their internal teams, often at more competitive rates. That makes distributed delivery easier without introducing the communication gaps that usually come with larger time-zone differences.
Those advantages are still valuable for many companies that need to scale their teams. But if you are choosing a partner today for projects around AI and agents, there may be other engagement models that are better suited to the way this kind of work is now being done than traditional staff augmentation or dedicated teams.
The reason is fairly simple: the way developers and engineers ship software is not the same as it was five years ago.
Teams can now produce more in less time, with AI taking on a growing share of execution. Engineers are still in control, but more of their time is shifting toward review, architecture, context, and decision-making.
This is already happening inside some of the biggest tech companies.
Satya Nadella has said that roughly 20% to 30% of the code in some Microsoft repositories and projects is already written by AI, and that share is growing. Google has reported similar numbers, while Shopify has gone as far as asking teams to show why AI cannot handle a need before requesting more headcount.
The important takeaway is not that engineers are going away. It is that the way their time is being used is changing.
What this means for consulting
The traditional nearshore model still tends to be built around people and hours. A client needs more capacity, a vendor adds resources, and the engagement scales largely with the amount of time those people spend on the project.
For many types of work, that remains perfectly reasonable.
AI projects, however, introduce a different dynamic.
A company might be building an AI product from scratch, creating an agent with Claude, automating part of a business process, or trying to make better use of the AI capabilities now appearing inside big platforms such as SAP or Oracle.
The details can change depending on the project, but the idea is usually the same: automate more of the work, reduce repetitive tasks, and help developers get more done in less time. In the end, it comes down to productivity.
This is where we start to see some friction with the hourly billing model.
If better tooling, reusable accelerators, or agents allow a team to complete in 500 hours what might previously have required 1,000, that is a huge productivity gain. The client may benefit from fewer hours billed, but the commercial model itself is still tied to time consumed rather than to what was accomplished.
That is where outcome-based delivery starts to become more interesting.
Instead of buying a block of hours, the client buys a defined piece of work: a workflow implemented, an agent deployed, a milestone reached, or a capability delivered.
The incentives shift with it.
If the provider finds a better way to execute the work, the client gets the result sooner and the team can move on to the next initiative. Automation stops being something that simply compresses billable time and becomes part of the delivery model itself.
It can be a win-win for both sides: the client gets the desired outcome faster, potentially at a lower overall cost, while the partner can work with a leaner, more focused team.
For AI projects, that feels like a much more natural fit.
What Works: The Nearshore Advantage Is Still There
There is a reason nearshoring became such a common delivery model in the first place.
Working in roughly the same time zone makes day-to-day collaboration easier, particularly when projects involve several business and technical stakeholders. A SAP engineer can join a call with finance. An integration specialist can work through an issue with a U.S.-based architect in real time. Requirements can be clarified during the same working day rather than disappearing into an overnight handoff.
That matters for global companies, where the difficult part is often not writing code but understanding how a process actually works across teams, systems, approvals, data, and exceptions.
Latin America (or LATAM) also offers a broad pool of resources across software engineering, SAP, Oracle, cloud, data, integrations, and AI. English proficiency, experience with U.S. organizations, and cultural proximity all help external teams operate more like an extension of the client organization.
There is also room to mix delivery models. Some initiatives benefit from having certain roles onshore while the broader engineering work happens nearshore. The point is not to force every role into the same geography, but to assemble the right combination for the project.
That flexibility remains one of nearshoring’s biggest strengths.
Big Consulting vs. Boutique Nearshore Partners: What Actually Changes?
Not all nearshore consulting engagements offer the same experience. And when it comes to choosing a partner, size can make a difference.
Large consulting firms bring global resources, established delivery structures, and the capacity to manage complex SAP and AI transformations across multiple countries and business units.
But there’s also a strong case for working with a boutique firm, especially when you have a specific project in mind.
Boutique partners typically offer a more direct, less bureaucratic way of working. With smaller teams and fewer layers of management, service managers can maintain closer relationships with both the consultants doing the work and the client’s internal team. This means faster communication, more direct access to senior engineers, greater flexibility, and less time spent on coordination.
1. Accenture | Global Consulting
- Key strengths: SAP transformations, enterprise AI, global delivery capacity.
- Best suited for: Large, complex transformation programs.
2. TCS | Global IT Services
- Key strengths: SAP, offshore and nearshore delivery, AI platforms.
- Best suited for: Enterprise-scale implementations and ongoing operations.
3. Globant | Digital Engineering
- Key strengths: AI-native development, AI Pods, distributed engineering.
- Best suited for: Digital products and AI engineering.
4. Infosys | Global IT Consulting
- Key strengths: SAP consulting, Infosys Topaz, AI-powered transformation.
- Best suited for: Enterprise modernization, SAP implementations, and AI adoption.
5. Inclusion Cloud | Boutique Enterprise Technology Partner
- Key strengths: SAP, Oracle, certified engineers, AI Pods, and accelerators.
- Best suited for: Flexible enterprise AI delivery, platform optimization, and team scaling.
What Doesn’t: Scaling Delivery Only by Adding More Hours
In the traditional model, the relationship is fairly direct: more work usually means more people, which means more billable hours.
AI is starting to weaken that connection.
Anthropic offers a pretty striking example. In the second quarter of 2026, the typical engineer there was merging 8x as much code per day as in 2024, with more than 80% of the code merged into its codebase authored by Claude. Of course, the same report cautions that lines of code are not a perfect measure of productivity. But still, it gives a pretty clear picture of where software development is heading.
That is also changing where their time goes. As more of the execution is handled by AI, engineering work shifts further toward architecture, enterprise context, quality, security, business rules, edge cases, and judgment. In fact, Anthropic says human code review is already becoming a new bottleneck as AI increases the amount of code moving through the organization.
The result is a delivery unit that can potentially handle much more without growing at the same pace.
And this is where hourly billing can start to feel misaligned. If the delivery system becomes significantly more productive, the commercial model should be able to recognize that gain rather than continue measuring value primarily through time consumed.
How Are Leading Consulting Firms Adapting Their AI Engagement Models?
AI is changing more than the technologies consulting firms implement. It’s also changing how they structure delivery, organize engineering teams, and charge for their services.
Here are five examples of how consulting providers are approaching this shift.
1. Accenture | AI Refinery & AI Factories
- Engagement approach: Enterprise AI transformation and platform-led delivery.
- Best suited for: Organizations deploying and governing AI across complex enterprise environments.
2. TCS | AI WisdomNext & Enterprise AI Factories
- Engagement approach: AI Factory implementations and large-scale enterprise transformation programs.
- Best suited for: Organizations building shared infrastructure and capabilities to scale AI across the business.
3. Globant | AI Pods & Glob.AI
- Engagement approach: Subscription and consumption-based AI services, with agents supervised by specialists and pricing aligned to outputs.
- Best suited for: AI-powered software engineering and repeatable business workflows.
4. Infosys | Infosys Topaz
- Engagement approach: AI-first consulting and delivery combining enterprise AI services, reusable solutions, and AI-powered engineering.
- Best suited for: Large-scale AI adoption, enterprise modernization, and intelligent automation.
5. Inclusion Cloud | AI Pods (NEW) & Enterprise AI Accelerators
- Engagement approach: Lean teams of senior AI-native engineers combining agentic workflows, reusable accelerators, and human supervision to deliver defined outcomes.
- Best suited for: Enterprise AI initiatives, SAP and Oracle workflows, AI product development, and moving pilots into production.
Where AI Pods Fit
This is the thinking behind our AI Pods at Inclusion Cloud.
An AI Pod is a compact team of senior specialists working with AI agents and reusable accelerators around a defined initiative.
Senior engineers set the direction and design how the agents will work. That includes looking closely at the economics of the system through an AI FinOps lens: choosing the right models when that decision has not already been made through procurement, monitoring usage and token costs, and reviewing the workflow itself.
That last part matters more than it may seem. An inefficient process does not become efficient just because AI is added to it. In many cases, those inefficiencies simply show up later in the monthly AI bill.
Once the workflow is defined, agents handle more of the execution. Domain specialists then supervise the outputs, review exceptions, and help identify where the same approach could be extended to other processes if the client wants to keep scaling.
The idea is to keep the team lean, but not for the sake of simply having fewer people. The goal is to create a delivery unit with enough seniority and context to own a meaningful piece of work without adding unnecessary coordination or execution overhead.
This structure also fits naturally with the outcome-based model we discussed earlier. As the Pod improves the workflow, automates more of the execution, or finds more efficient ways to use models and agents, those gains can translate into faster delivery and better economics for the client.
And What Happens When the Project Is Finished?
This is another area we think buyers should pay attention to.
A consulting engagement should leave the client with something useful after the team is gone.
If the work produces an agent, a workflow, a product, or another enterprise capability, the client should be able to own it and continue from there.
That leaves two sensible paths.
- One is to keep the Pod and apply the model to another process.
- The other is to take what has been built and continue internally.
The important part is that the choice belongs to the client.
So What Makes a Strong Nearshore SAP and AI Partner?
The answer is becoming broader than geography or hourly rates.
Time-zone alignment still matters. So do strong resources, cultural proximity, enterprise platform expertise, and the flexibility to combine nearshore and onshore delivery.
But for AI projects, there is another layer.
The partner should be able to use AI to improve the delivery system itself.
That means knowing where agents can execute, where engineers need to stay in control, how to reuse what already works, how to measure what is being delivered, and how to structure the engagement so productivity gains are useful to both sides.
That is the direction we see nearshoring moving.
The fundamentals are still good.
The delivery model is simply starting to catch up with the technology.
And if you want to explore the AI opportunities inside your company, learn more about inMOVE by Inclusion Cloud, our AI-driven recruiting method for identifying top consultants in the market, or discuss where one of these models could fit, you can schedule a quick call with one of our specialists.
