For Agile to work best, there must be a single "product owner", a single person or team that is responsible for the generation and prioritization of requirements.
On my last Agile project, we had two product owners; two different companies who came to us as a pair and said they wanted new software to replace an application they were literally paying their competitors to use (we're talking hundreds of thousands of dollars a month in licensing fees). It worked as well as three corporate entities can work, primarily because there was a spirit of cooperation among all participants. Even then, there were problems; the requirements responsibilities were split between POs, and yet both companies needed to contribute to many of them. This resulted in differing quality of requirements depending on the PO that generated them, and often a long back-and-forth between the POs and BAs to iron out inconsistencies. The two POs also used the licensed application differently, with different configurations, and thus they had different expectations of how the same piece of functionality was supposed to work, based on settings they had long ago forgotten about from the original software.
You and your company face an even more difficult situation, in which the various stakeholders may be flat-out competing with each other day-to-day, and are biting and clawing beneath the surface for any relative advantage they can get. For one company to get a company-specific piece of functionality placed above another company's bit in the backlog is just such an advantage, and I wouldn't be surprised if one member of the organization tried to use this process to bury another member.
I would approach this situation in one of two ways:
Be the product owner for the group of companies. This means being the mediator, and possibly arbitrator, of disputes between the stakeholders with regard to prioritizing the backlog and creation of requirements. This would have significant value to both the stakeholders and the development firms you worked with; you become a "buffer" between the two sides, taking on the unenviable position of insulating the development effort from the politics of the requirements generation. To the stakeholders, you're a consultant and guide through the Agile process, smoothing out the bumps in the road so they don't derail the whole effort.
Arrange the development effort according to the stakeholders themselves. If there is a "common" set of functionality that most or all of the stakeholders can agree on, set up a large "core" team to build the basic software. Then, if one company, or even two or three, need it to work a different way for them and the group as a whole is unwilling to support the effort, you can set up or spin off smaller teams that can attack these additional pieces of functionality according to a separate backlog. These customer-specific teams are still subject to the critical path of the core backlog; creating company-specific functionality that is a change to the core feature will always be dependent on the core feature being implemented first. Definitely make sure the additional functionality is integrated in such a way that the project still passes the core ATs; those are the ones for which you and the developers will be getting the lions' share of the contract price.