Like many folks these days, and certainly many industry analysts, I’ve set an AI agent loose on a recurring research task. Each week, it searches for new papers, standards work, and substantive analysis connected to Opus Research’s ongoing work on AI agent control planes for customer experience. Obviously, I don’t treat the output as gospel (I do cover this technology after all!), but it’s a useful way to spot developments I might otherwise miss. This is especially true for academic papers and work submitted to standards bodies—not digital spaces in which I usually hang out.

This week’s results included something that immediately caught my eye: a paper from Hesham Moussa and Arashmid Akhavain, two Huawei researchers in Canada, titled Context and Correlation Management Architecture for Distributed Agentic Activities. Huawei Canada definitely was not the source I expected to send me down a multi-agent observability rabbit hole, but, hey, research is more interesting when it comes from unexpected directions.

Anyway, the paper proposes a way to connect the scattered pieces of work performed by agents, tools, and services across different vendors and protocols. That sounded remarkably close to one of the problems Opus Research keeps homing in on in our work on the AI agent control plane: how do you understand and govern a customer journey when no single agent or platform can see the whole thing? This is especially true in journeys that include actions from multiple AI agents, something that’s becoming much more common as brands aim AI agents at more complex problems.

So, I started tugging on that thread. The paper isn’t proposing a complete observability solution. But it may offer part of the common grammar a control plane will need.

One Journey, Many Partial Views

That common grammar starts with a pretty simple and common-sense idea: observability needs to follow the customer outcome, not just the individual protocol or interaction.

Most observability tools we’ve seen at Opus Research are very good at showing what happened within a particular system. An MCP server may record a tool request and response. An A2A platform may trace a task handed from one agent to another. A contact center platform likely records and preserves the customer conversation. So, each record can be 100% accurate while telling only a fraction of the story.

Moussa and Akhavain propose treating the broader objective as an “Activity.” That Activity might be resolving a billing dispute, changing a reservation, or replacing a damaged product. It can contain multiple dialogs and tasks, involve several agents and tools, and produce resources that another agent uses later. The diagram below illustrates the basic idea. A billing-dispute Activity connects the customer-agent dialog, the brand-agent dialog, the refund task, the policy result, and the resulting refund record. Those components may sit in different systems and carry completely different local identifiers. The guys from Huawei propose a model that uses typed relationships such as “delegated from,” “uses,” and “produces” to connect them into one logical journey.

That connection seems really bog standard but, in reality, it is the really useful bit. A platform-level trace might show that an agent successfully called a refund tool. It may not show that the amount came from another agent, that the policy evidence was outdated, or that the refund record didn’t match what the customer requested.

This is where the proposal begins to overlap with the our control plane ideas. A control plane needs visibility across the entire journey before it can meaningfully govern it. It has to connect customer intent, agent handoffs, tool activity, policy decisions, and resulting effects. Otherwise, enterprises end up with a tidy collection of individually observable systems and no reliable view of whether the customer’s actual problem was resolved.

A Common Grammar Isn’t a Control Plane

Useful as that model may be, it obviously won’t  solve the whole multi-agent observability problem. Moussa and Akhavain are, to their endless credit, careful about this. They’re proposing an information model, not a wire protocol like A2A or even HTTP or a deployable observability platform. In other words, they describe the pieces that need to be connected and the relationships among them. They don’t specify exactly how different systems should exchange that information, where it should be stored, who can query it, or how conflicting accounts of the same Activity should be resolved.

There are also some fairly large governance questions sitting outside the model. Who creates the authoritative Activity identifier? Which agent can add a task or resource to the record? How do we know an agent hasn’t hidden, either inadvertently or deliberately, a downstream delegation? What happens when a customer withdraws consent or corrects something that an earlier agent recorded incorrectly?

The paper also deliberately leaves agent memory and knowledge content outside its scope. So, it could show that an agent used a particular policy result to approve a refund. But it wouldn’t tell us whether that policy was current, authoritative, or poisoned by information from some untrusted source. Nor would or could it prove that the refund actually reached the customer’s account.

Work addressing other small pieces of this broader control problem is popping up all over the place. Researchers and standards groups are separately tackling things like agent identity, delegated authority, consent, policy enforcement, audit records, tool security, and cross-agent communication. Somehow, smart people will have to assemble those disparate parts into a workable whole. As much as the standards process can be a dispiriting quagmire of competing interests, standards bodies may still be the best place to hammer out at least some of those connections.

That’s where the rest of the control plane should come in. This common information model would need to sit alongside identity, authorization, consent, policy enforcement, knowledge governance, testing, and verification of external effects. It would also need data showing what the journey cost to complete including the tokens, tool calls, latency, retries, escalation, and rework consumed along the way. So, while I don’t see this proposal as a ready-made control plane, I do see it as a promising grammar for one. Without that shared grammar, every platform can produce its own perfectly tidy record while the enterprise still cannot reconstruct what happened across the complete customer journey.

The next step is turning that common grammar, along with all those other promising pieces, into something enterprises can exchange, enforce, and verify across organizational boundaries.

Categories: Intelligent Assistants, Articles

Tags: AI agent control plane, AI agent governance, control plane, huawei, observability