Disclaimer: I have never worked in a digital agency and I am aware that the role of Project Manager in Digital Agencies can be somewhat different to that commonly accepted in other I.T. operations whether in-house or software development suppliers. Furthermore I am not clear on the exact differences.
Despite my disclaimer above, and taking the question and roles at face-value, I think there are a number of problems with the assumptions made here:
1. The Project/Accounts Manager isn't a developer
So what? These are very different roles with very different responsibilities. In my experience developers often think that the role of Project Manager is akin in some way to Team Lead, or Development Lead. Undoubtedly in some organisations that is the case in practise, but I assume it isn't here as you have already stated you have Dev Leads.
So this is a statement of fact rather than an actual problem. It can lead to significant project problems if the PM needs a technical appreciation in order to complete their PM work or if the development team use the PM's lack of technical experience against them by, say, over or under-estimating workload when the PM doesn't have the necessary skills to review and challenge estimates. But it is not, in itself, a problem. It would be worth thinking about why this is a problem to you or to the project as that will uncover issues that can be addressed.
2. Chinese whispers effect happens and requirements get lost/confused
This is a process problem. You don't have robust enough change management, requirements gathering and logging processes in place to ensure that requirements don't "get lost". The PM should recognise that, even if the organisation doesn't, and deploy something locally to the project. However the fact that you (and presumably by extension) the rest of the dev team knows this is a problem and you haven't deployed a solution speaks of other unwritten issues here. It is everyone's responsibility to ensure the requirements are managed properly.
3. The client wants to speak directly with the developers.
There is no inherent reason why this is a problem. It can be a problem if the developers are not able to communicate effectively with the client(s) and this is often the case in the wider I.T. world. Note, I (hope I) am not stereotyping here- developers are goal oriented detail-people in the main, and often clients wish to talk at a more conceptual level with other agendas that developers do not perceive. Conversely clients often cannot discern the true meaning and consequence behind developers' technical questions. There are always exceptions on both sides and I have seen it work well, but it doesn't always. If there is a real need for clients and developers to communicate then it should be facilitated and managed by the PM. I don't mean they have to be the postman in-between the dialogue or present at every meeting, but they should manage when and how it happens and provide oversight to ensure the outcomes from the communications are mutually beneficial.
4. The developers end up becoming project managers.
Do they though? Or do they become what developers think are project managers? Do the developers start actively managing the employers' and the clients' risks? Do they begin negotiating resource levels, contracts and expectations? Do they rearrange the project plan to take into account new dependencies and ensure regular clear communications goes out against the communications plan? etc. etc. etc. If they really do start being project managers then clearly you have an ineffective project manager. Or perhaps you have a PM that is inexperienced and doesn't communicate properly, or doesn't work with the development team to understand what is happening to the project?
Summary/TL:DR
It seems to me that all these "problems" are actually symptoms. None of them on their own is an actual problem (except for point 2. which is a group failure as far as I can see).
So what is the net result of these symptoms?
- Does the project get delivered late?
- Does the project go over budget?
- Is the deliverable quality poor?
- Is the client unsatisfied?
What you have described is, possibly, a dysfunctional team maybe with an inexperienced or just downright rubbish PM, but maybe not.
Start by defining what the actual material issues are, not what you or the developers or the PM thinks are local working practise issues. It sounds like some resentment has built up- try and see past that to the actual problems. Then when you know what is actually wrong you can begin, as a company, a team and an individual to think about what needs to change to correct the situation.