Separation of concerns isolates distinct responsibilities so each part can be developed, replaced, and changed independently. The boundary is an explicit interface rather than shared implementation or state. section 3.4.1
Apply the pattern by assigning each component a focused responsibility:
- Expose capabilities through a stable contract, such as a tool name, description, parameter schema, and return type. section 3.4.1
- Keep implementation details private behind the interface; a journal can move from a Python list to Postgres, Redis, or a remote API without changing the agent. section 3.4.1
- Separate exploration from presentation: let a research agent discover findings and a synthesis agent compile and structure the final report. section 9.2.6
- Deploy related concerns as independently managed services when upgrades, scaling, security, or component swaps matter. section 8.1
From shared tools to an MCP server
A tightly coupled agent directly accesses journal tools and shared state. A separated design places those tools in an MCP server. The agent discovers the server’s tools through their schemas and communicates over STDIO locally or SSE remotely, without reaching the implementation. section 3.4.1
Figure 3.15 The separation of tools from the agent into a standalone MCP server that can be hosted locally or remotely and accessed through STDIO (local) or SSE (remote). Now the agent registers the MCP server instead of individual tools and then internally discovers the tools the server supports and how to use them.
Use the architecture figure to compare an agent registering individual tools with an agent registering a standalone MCP server hosted locally or remotely. section 3.4.1
