Exploring AI Agents and the Future of Technology M&A

Most technology mergers get announced with a press release and a slide deck. The synergies are clear. The combined roadmap is compelling. The market share math works on paper.  

What happens next — the months of engineering work that actually determine whether any of that comes true — rarely gets written about. It happens in Jira tickets, in late-night schema debates, in the gap between what the integration plan said and what the data actually looked like when someone opened the files. 

Athresh Guruprakash has spent the past year trying to change that. A Senior Software Engineering Manager with 18 years of experience across software engineering, credit risk, and applied AI/ML, he’s published a three-part practitioner research series on technology M&A integration — starting with a sequencing framework for the engineering work itself, then a five-agent AI architecture for the piece that consumes the most time, and most recently applying both to what he describes as the hardest system in any merger to migrate: the call centre. We spoke with him about the research, about where AI genuinely helps versus where it’s still theoretical, and about what it looks like to do this kind of work alongside a full-time leadership role. 

Please tell us more about yourself. 

I decided I wanted to be a software engineer when I was ten years old. There’s no dramatic story behind it. I grew up in Bangalore, which people call India’s Silicon Valley for good reason, and I was just fascinated by data, quality engineering, and algorithms from an early age. Growing up there, that fascination didn’t really have anywhere to go but forward. 

Once I had that foundation as a developer, I had to lay my hands on machine learning and artificial intelligence next, and that’s largely where I’ve stayed since. Today I’m a Senior Software Engineering Manager, and I’ve spent the last 18-plus years across software engineering, credit risk systems, and more recently applied AI/ML. My path has mostly run through regulated, high-stakes environments — places where a system being mostly right isn’t good enough, because the cost of being wrong lands on a real person’s credit, their loan, their case. 

Outside of that, I spend a good chunk of my free time making educational content under something I call Tech with AG — breaking down AI and machine learning concepts for people who didn’t grow up around this stuff: students, career-switchers, parents trying to keep up with what their kids are learning. The same instinct that drives Tech with AG — making complex AI systems legible to non-specialists — is what I try to bring to the research itself. The practitioner series on technology M&A came out of that same impulse, partly because I kept seeing the same engineering failure patterns repeat across integrations, and partly because nobody was writing about the actual sequencing of that work the way I wished someone had when I was in the middle of it. 

“A system being mostly right isn’t good enough, because the cost of being wrong lands on a real person’s credit, their loan, their case.” 

Your research series started with a general framework for M&A integration. What gap were you trying to fill? 

Failure-rate research on M&A goes back decades — and the numbers have barely moved. A KPMG study from 1999 found 83% of mergers failed to boost shareholder returns, and McKinsey’s more recent analysis of over 2,000 transactions confirms that the majority still destroy rather than create value. Most of the explanation sits in strategy and organisational-design literature: governance charts, synergy trackers, culture playbooks. The actual technology integration gets treated as a black box that “IT will handle.”  

My first paper, The Integration Tax, opens that box. It lays out a staged sequence: discovery, deciding system by system whose platform survives, converging schemas, migrating and certifying data, building product in parallel rather than waiting, and finally cutting over. Along the way I named a few constructs I kept needing and couldn’t find good vocabulary for elsewhere — things like the Dual-Run Window, for the bounded period when both platforms are live at once, and Sync Directionality Risk, for figuring out whether data needs to flow one way, both ways, or not at all during that window. The goal was a framework a working engineering leader could actually apply on their next deal, not a slide template. 

You followed that with a paper on AI agents and schema convergence. Why did that feel like the natural next step? 

Schema mapping — figuring out which field in one company’s system corresponds to which field in another’s — is exactly the kind of repetitive, pattern-heavy work that eats weeks of analyst time. It’s also structurally the kind of task large language models have shown real capability on. But most published research evaluates schema matching in isolation, against a clean benchmark with a known correct answer. Real M&A migrations don’t work that way. Nobody has the ground truth mapping in advance, and the target schema doesn’t even exist yet. 

So I proposed a five-agent architecture — Agent-Assisted Schema Convergence, or AASC — that carries a migration from a first look at both systems’ structure all the way through to a deployable pipeline. The way I think about the agents is less as separate tools and more as a handoff chain, where each one can only do its job because the previous one did its job first. 

The Schema Intelligence Agent goes first — it has to understand both source and destination systems before anything else can happen. What fields exist, what types they are, how they relate, how they’re named. The Data Profiling Agent comes next and does something the structural analysis can’t: it actually looks at the data inside the fields. Cardinality, nullability, how the values are actually distributed. That matters because a field named “status” in system A and “status” in system B might map cleanly on paper and be completely different concepts in practice. 

The Canonical Design Agent uses all of that to propose the target schema — a clean design rather than a union of both systems’ existing structures, because a union just inherits both companies’ technical debt. There’s a human sign-off gate here before anything moves forward. Then the Mapping Agent does the actual field-by-field translation work, and the Pipeline Design Agent turns the approved mapping into something that can run. Each handoff has a review point. Nothing touches production without sign-off. 

Research Disclosure 

The Agent-Assisted Schema Convergence (AASC) framework described in this interview — including the five-agent pipeline architecture — is a proposed practitioner framework grounded in observed M&A integration patterns. The individual agent roles and the human-checkpoint design principles reflect real integration experience. However, the complete five-agent system as an integrated, automated pipeline has not yet been fully deployed or field-validated end-to-end. This is stated transparently in the underlying research paper. Future work will test the boundary between what each agent can be trusted to do unsupervised and what still requires human intervention — and subsequent publications will report those findings honestly. 

Where does the risk actually concentrate in that pipeline?  

In the Mapping Agent, without question. That’s the one deciding which field in the old system becomes which field in the new one, and a wrong mapping doesn’t fail loudly. It fails as a silently misrouted or dropped field, and the consequence shows up much later — at certification, or worse, in production. 

The design choice I’m proudest of there is confidence scoring instead of a flat accept-or-reject. High-confidence matches move through quickly. Anything ambiguous routes to a manual-review queue. Sounds simple, but it means human attention gets spent exactly where it changes the outcome, instead of being spread thin re-checking work the system already got right. 

“Human attention gets spent exactly where it changes the outcome, instead of being spread thin re-checking work the system already got right.” 

Your most recent paper applies both frameworks specifically to call center migration. What made that domain different enough to deserve its own treatment? 

Every other system touched by a merger has some slack in it. A batch job can run an hour late — nobody notices. A call center has almost none of that slack, because the customer is on the line right now, mid-problem, with no idea two companies’ engineering teams are mid-migration behind the screen the agent is looking at. 

That paper, Rolling the Dice, walks through the full sequence as it actually played out on a real technology M&A call center migration — understanding both the source and destination platforms, deciding between lifting the acquired platform onto the destination versus building new, designing a combined schema across five distinct artifact types most people don’t think about (tickets, image queues, forms, letters, and reports), migrating that data in parallel with new-platform feature development, and having the actual agent workforce test production-like data before anything goes live. Unlike the first two papers, which were written ahead of field validation, this one reflects what genuinely worked in practice. 

What’s a detail from that call center work you think people underestimate? 

How much the schema design philosophy has to change. In the general framework, I argue for a clean, canonical schema redesign rather than a union of both source systems, because a union just inherits both companies’ technical debt. Call center ticket data is a deliberate exception to that. 

Historical tickets from both companies have to work on the new platform without a backfill project. A customer calling about a two-year-old issue expects the agent to pull it up and see what actually happened. So the combined schema there is intentionally an inclusive superset: source fields, plus destination fields, plus whatever the new platform needs. It’s a tradeoff, not an oversight — and I think that nuance gets lost when people treat “canonical schema” as a universal best practice instead of a default with deliberate exceptions. 

How do you think about AI’s role across all three papers, taken together? 

Consistently as acceleration, never as replacement. Every agent I’ve proposed across this series operates behind a human checkpoint, and I treat that as a permanent design principle — not a limitation I’m waiting to engineer away eventually. 

And I think the industry data reflects where things actually are, not just where vendors say they are. Most contact centres have some AI in them now, but only about a quarter have it meaningfully woven into daily operations. That gap between “we have AI” and “we trust it to run things” is real, and it tells you something. Full autonomy isn’t where mature deployments sit yet. The value is in intelligent routing of human attention — getting the right problems in front of the right people faster, not in removing people from the picture. 

“Full autonomy isn’t where mature deployments sit yet. The value is in intelligent routing of human attention — getting the right problems in front of the right people faster.” 

What are your plans for this research going forward?

There’s a natural fourth piece I’ve flagged but haven’t written yet — a dedicated treatment of call centre and CX platform integration in more depth than the current paper goes. Beyond that, the thing I most want to do is test the AASC framework properly. Right now it’s a well-reasoned proposal. The agent roles and the handoff logic are grounded in patterns I’ve watched play out across integrations. But I haven’t run the complete pipeline end-to-end in a live migration with real production data. That’s the honest position, and I say it openly because I think the research community is better served by knowing what’s been proven and what’s still in front of us. The next version of this work will be able to say more definitively where the agents are reliable and where you still need a human making the call.

And I’ll keep bringing it back to Tech with AG. Translating dense technical research into something a non-specialist can actually use is a real skill, and it’s one I care about as much as the research itself. 

What advice would you give to engineers looking to do this kind of practitioner research alongside a full-time leadership role? 

Write about what you’re actually seeing fail, not what sounds impressive. The frameworks that hold up are the ones grounded in a real, repeated pattern — not a hypothetical one. And don’t wait until you have a perfect, field-tested answer before publishing. Say clearly what’s proposal versus what’s proven, and let the next version of the work be honest about which parts moved from one column to the other. 

I grew up somewhere that made becoming an engineer feel almost inevitable. Most people don’t get that head start. A lot of what I write — both the research and Tech with AG — is really just an attempt to hand a piece of it to someone who didn’t. 

RESEARCH REFERENCED IN THIS INTERVIEW 

The Integration Tax  —  A staged engineering framework for technology M&A integration 

Agent-Assisted Schema Convergence (AASC)  —  Five-agent AI architecture for M&A schema mapping and pipeline design 

Rolling the Dice  —  Applied M&A integration framework for call center platform migration 

Full research portfolio: researchgate.net/profile/Athresh-Guruprakash 

About Athresh Guruprakash  

Athresh Guruprakash is a Senior Software Engineering Manager with 18 years of experience across software engineering, credit risk systems, and applied AI/ML. He has spent most of his career in regulated, high-stakes environments — the kind where a system being mostly right isn’t good enough. Alongside his day job, he publishes practitioner research on LLM hallucination, technology M&A integration, and AI-augmented quality engineering, and runs Tech with AG (@tech.wag), an education platform that tries to make complex AI concepts legible to people who didn’t grow up inside a tech company.