Multi-Agent Orchestration: Why Testing Agents Need to Share Context

Here is a mismatch that has been sitting in plain sight for about twenty years.

Testing tools are organized by technology. There is a web tool, a mobile tool, an API tool, a security scanner, a performance suite. Each is excellent at its layer and each was built by people who understood that layer deeply.

Users are organized by journeys. Someone opens a mobile app, taps checkout, the app calls an API, the API writes to an ERP, and a confirmation comes back. That person does not experience five layers. They experience one thing that either worked or did not.

Your tools are shaped like your architecture. Your users move through something shaped like a journey. Almost every integration bug lives in the gap.

For most of that twenty years there was no alternative, so the mismatch was simply absorbed, you ran the tools, collected the reports, and did the correlation in your head or in a spreadsheet. What has changed is that agents can now share context with each other, which makes it possible to organize testing around the journey instead of around the stack.

This piece is about what that actually changes, why the handoffs between layers matter more than the layers themselves, and what “sharing context” means concretely rather than as a marketing phrase.

Why Testing Fragmented by Layer

The fragmentation was not a mistake, and it is worth saying so before criticizing it.

Each layer genuinely requires different expertise. Driving a browser is a different problem from driving a mobile OS, which is different again from exercising an API contract or reasoning about a vulnerability class. The tools specialized because the problems are specialized, and the specialists who built them produced better results within their layer than any generalist would have.

What made it work was that a human sat above the tools and did the integration. A QA lead read the web report, the mobile report and the security scan, noticed that the slow API call in one report explained the timeout in another, and assembled a picture. The tools were fragmented; the understanding was not, because a person held it.

That arrangement degrades under two conditions, both of which are now normal. It degrades when release frequency outpaces the human correlation step, nobody assembles the picture between a Tuesday deploy and a Wednesday one. And it degrades when the number of layers grows past what one person can hold, which for most teams happened somewhere around the time mobile, API and cloud infrastructure all became independent testing concerns.

The Handoff Problem

Here is the part that makes fragmentation genuinely expensive rather than merely inconvenient.

Defects concentrate at boundaries. The mobile app works, the API works, the ERP works, and the thing that fails is the contract between them: a field the app sends in one format and the API expects in another, a timeout the app does not handle, a state the backend enters that the client has no representation for. Anyone who has debugged production incidents knows integration points are where the difficult ones live.

Now consider what siloed tooling does at exactly those points. The mobile tool tests up to the boundary of the mobile app and stops. The API tool tests from its own boundary outward. Neither one owns the handoff, because the handoff is not inside either tool’s definition of its layer.

We organised our tooling to be blind precisely where the defects concentrate. Not deliberately, but consistently.

This is why teams with high coverage in every individual layer still ship integration bugs. The coverage numbers are real; they are just measuring the wrong geography. Ninety percent of the mobile app and ninety percent of the API can both be covered while zero percent of the contract between them has been exercised end to end.

Four Things That Break Without Shared Context

1. Every agent redoes the setup

If the API agent has already authenticated, created a customer and seeded an order, the mobile agent should be able to start from that state. Without shared context it cannot, so it authenticates again, creates its own customer, seeds its own order. Multiply that across a suite and a meaningful share of total execution time is spent re-establishing conditions another component already established.

2. Failures cannot be attributed

A mobile checkout test fails. Was it the app, the network, the API, or the backend? With separate tools, the mobile report says the element did not appear and stops there, that is the limit of what it can see. Someone opens three other systems and starts correlating timestamps.

With shared context, the answer is often already present: the agent that observed a four-second latency on the same call, in the same session, on the same build, has information the mobile agent needs, and passing it along is trivial once there is a channel for it.

3. Signals arrive uncorrelated

A performance degradation observed by one tool on Monday and a functional failure observed by another on Tuesday become two tickets, assigned to two people, investigated separately. Observed in the same session by coordinated agents, they are one finding with a plausible causal relationship.

This matters more than it sounds. Most performance regressions manifest first as intermittent functional failures, and the two get triaged as unrelated or failures engineers miss for weeks because nothing connects them.

4. Execution order follows tools, not business processes

Some validations only make sense in sequence. You cannot meaningfully validate that an ERP posting is correct until the checkout that produced it completed. Tool-scheduled execution runs the web suite at midnight and the ERP suite at two, and whether the second is validating the output of the first is a matter of timing luck rather than design.

Orchestrated execution follows the process: the journey runs in the order a user would experience it, and each stage validates against the state the previous stage actually produced.

What “Sharing Context” Actually Means

The phrase is doing a lot of work in vendor marketing at the moment, so it is worth being concrete about what is being shared.

In practical terms, coordinated agents need access to four things about each other:

• State. What exists right now as a result of prior steps, the authenticated session, the created order, the identifiers other agents will need to reference.
• Observations. What each agent noticed while acting, including things outside its own assertion set: latency figures, console errors, unexpected responses. The observation that matters to another agent is frequently one the observing agent did not consider notable.
• Intent. What the overall journey is trying to establish, so an agent handling one leg knows what the destination is rather than only its own segment.
• Verdicts. What each agent concluded, so a coordinating layer can produce one answer about the journey rather than five answers about layers.

Where MCP comes in

The Model Context Protocol is an open standard for giving AI systems structured access to tools and context. It was not created for testing specifically, it is a general mechanism for supplying context to models in a consistent, interoperable way.

Its relevance here is architectural rather than magical. Using MCP as the substrate for inter-agent context means the sharing mechanism is a standard rather than a proprietary coupling invented per vendor. Practically, that means agents can be added to a coordinated system without rewiring the ones already there, and context is a first-class part of the architecture rather than an integration bolted on afterwards.

That is a design choice with real consequences at scale, and it is the difference between a platform that coordinates agents and a collection of tools with an integration layer stapled across them.

What Orchestration Changes

The last row is the one that compounds. In a fragmented model, each additional layer you need to test adds an integration burden proportional to how many other tools it must relate to. In a shared-context model, an agent joins the existing context and gets the benefit of everything already there, which is why adding security or performance validation to a functional journey stops being a project.

Where Sofy Fits

This is the architecture Sofy’s platform is built on rather than a capability added to it.

Specialist agents cover different layers, web, mobile, security, data, and enterprise ERP including SAP and Dynamics 365, and coordinate through a shared MCP hub. They exchange state, observations and verdicts, execute in the order the business process requires, and produce a single answer about whether the journey works rather than five answers about layers.

The practical shape of that: a mobile agent validating a checkout can hand off to an ERP agent that confirms the resulting posting hit the right accounts, while a security agent observes the same session for insecure storage or exposed endpoints and a performance agent records latency at each hop. One run, one execution path, one verdict, rather than four schedules and a reconciliation meeting.

For teams whose product genuinely spans layers, a mobile app front-ending an SAP process, a web portal calling APIs into Dynamics 365, that is the difference between testing the pieces and testing the thing customers actually use.

What This Doesn’t Solve

Three honest limits.

• Orchestration does not improve any individual layer. A coordinated mobile agent is not better at mobile than a good standalone mobile tool. The gain is at the boundaries and in correlation, not within a layer, so if your problem is genuinely confined to one layer, this architecture is solving something you do not have.
• Shared context adds a coordination surface. Anything that coordinates can mis-coordinate. Sequencing errors, stale shared state and agents acting on observations that have since changed are real failure modes, and they are new ones that siloed tools do not have.
• Specialist depth still matters. A security agent participating in a functional journey is not a replacement for dedicated penetration testing, and a performance observation during a functional run is not a load test. Orchestration widens what a single run covers; it does not substitute for depth where depth is genuinely required.

Frequently Asked Questions

What is multi-agent testing?

Multi-agent testing uses several specialist AI agents, covering layers such as web, mobile, API, security and ERP, that coordinate rather than run independently. They share state, observations and verdicts so a user journey crossing multiple layers is validated as one thing, rather than as separate tests in separate tools whose results a human has to reconcile.

What is MCP and why does it matter for testing?

The Model Context Protocol is an open standard for giving AI systems structured access to tools and context. It was not designed for testing specifically. Its relevance is architectural: using a standard as the substrate for inter-agent context means agents can join a coordinated system without bespoke wiring to every other agent, and context becomes part of the architecture rather than an integration layer added later.

Why can’t separate testing tools just be integrated?

They can be, and many teams do it, usually through a reporting layer that aggregates results. What integration at that level cannot provide is context during execution. Aggregating four reports afterwards tells you four things happened; it does not let the mobile agent know, at the moment it fails, that another agent observed a four-second latency on the same call in the same session.

Does orchestration make individual layer testing better?

No, and it is worth being clear about that. A coordinated mobile agent is not inherently better at mobile testing than a strong standalone mobile tool. The benefit is at the boundaries between layers, where defects concentrate and where siloed tooling structurally stops, and in correlating signals that would otherwise become unrelated tickets.

What new risks does multi-agent orchestration introduce?

Coordination creates its own failure modes: sequencing errors where an agent acts before the state it depends on exists, stale shared context where an agent reasons from an observation that has since changed, and conflicting conclusions between agents examining the same behaviour. These are genuinely new problems that siloed tools do not have, and they need their own validation.

The Bottom Line

Testing fragmented by layer for good reasons, and it worked for as long as a human could sit above the tools and assemble the picture. Release frequency and stack complexity have both outrun that arrangement.

The cost is not primarily inefficiency. It is that we organized tooling to stop exactly where defects concentrate, at the handoffs between layers, and then measured coverage in a way that made the gap invisible. High coverage in every layer and no coverage of the contracts between them is a normal and dangerous state.

Agents sharing context is what makes it possible to organize testing around journeys instead of around the stack. Which is, if you step back, how testing should probably have been organized in the first place, it just was not technically achievable until now.