You're right that there are relationships between the process areas. For example, the activities that occur in Project Planning inform Project Monitoring and Control as to what needs to be monitored and controlled, and based on the monitoring, replanning may be done in accordance with Project Planning. There are also relationships between the Categories. For example, the Project Management process areas feed the Requirements Development and Requirements Management process areas, which inform Technical Solution as to what needs to be designed and implemented, and the outputs of Technical Solution are verified in accordance with Verification.
There's an entire chapter of CMMI-DEV 1.3 devoted to relationships among the process areas.
However, all activities that you can do on a project can fit neatly into one of the process areas. For example, you mention coding in your question. Coding is part of the Technical Solution process area. However, other things are also part of Technical Solution - writing support documentation (training materials, user's manuals, help), performing make/buy/reuse analysis, select solutions. Some of these are related to other process areas. For example, you Decision Resolution & Analysis (DAR) processes can be used in selecting a solution.
Now, you may realize that some related processes are at different levels. For example, Configuration Management and Requirements Management are at Maturity Level 2, while Technical Solution and Requirements Development are at Maturity Level 3. Clearly, if you are managing the configuration, you must have a solution that you are managing. However, it refers to what processes you need to have defined and have objective evidence of performing. It is expected that you have a defined and consistently implemented process for establishing baselines, tracking and controlling changes, and ensuring the integrity of your product before you have a defined and consistently implemented process for implementing a technical solution.
Something else to consider is that your processes may not may 1:1 with the CMMI Process Areas. Again, looking at Technical Solution, there are three specific goals - select product component solutions, develop the design, and implement the product design. Each of these could be three separate processes in your organization (as defined in Organizational Process Definition). You may be better served by looking at the General Goals and Specific Goals and grouping them appropriately in how you.
I think that Generic Goal 2: Institutionalize a Managed Process is most relevant to you. The first Generic Practice is to Establish an Organizational Policy. Here, the guidance is to simply elaborate on the process areas. There is no rules on how you go about elaborating. I also think that Generic Goal 1: Achieve the Specific Goals is something that you need to consider. You do this by implementing Generic Practice 1.1: Perform Specific Practices.
When designing a process or process framework for CMMI, the goals and practices are far more important than the process areas. These goals and practices are the things that are essential for a successful software project. There are countless ways to achieve them, and it will depend on your organization, your industry, your product, and more.
Also, since you mentioned the agile methods, you may be interested in information about embracing both agile and the CMMI and how the agile methods and CMMI complement each other.
