Heavy Split Is a Question, Not a Schema

The mistake is treating every tool split like a cleanup refactor. A heavy split is not cleanliness. It is an expensive question deliberately placed in the agent’s path.

That expense matters. Tool lists are context. Every new tool increases the surface the model has to read, rank, and choose from. A hundred tiny tools replacing one coherent operation is not agent design. It is context pollution with a nicer name.

So the split has to earn its weight.

A heavy split takes a branch that could have lived inside a parameter and promotes it into the tool surface because the branch is operationally meaningful. Not aesthetically different. Meaningful. If the wrong branch changes cost, freshness, latency, authority, safety, permanence, rate-limit pressure, or retrieval quality, the agent should not stumble into it through a buried enum.

It should have to choose.

The trivial example is file attachment. One tool could take source: "local" | "url". A heavier split exposes attach_local_file and attach_url_file. That is useful because local file access and remote fetching have different permissions, failure modes, and trust boundaries.

But the cleaner example is shared data.

Say the system has two ways to answer a history question. One path reads the local database. It is cheap, fast, and already contains the historical record. The other path hits an API. It is fresher, but slower, rate-limited, and shared with other callers.

The lazy design says: one tool, get_history({ source: "db" | "api" | "both" }).

The worse heavy split says: query_history_db and fetch_history_api.

That split is only half right. It forces a choice, but it makes the agent reason about plumbing. Database versus API is not the decision the task cares about. Freshness is.

The better split asks the real question:

search_known_history(...)
check_current_state(...)

Now the model is not deciding which backend feels safer. It is deciding whether the task can tolerate stored knowledge or needs fresh verification. That is the distinction worth spending context on.

If the answer can be stale, use the cheap known-history path. If the answer must reflect the current world, check current state. If the task needs both breadth and freshness, call both deliberately. The point is not to hide from tradeoffs. The point is to expose the right tradeoff.

▰▰The litmus test

A heavy split should come with a question sharp enough that the agent can answer it before acting.

Not: “Do I want the database or the API?”

Yes: “Do I need current truth or known history?”

Not: “Do I want raw memory chunks or authored drawers?”

Yes: “Do I need the interpretation we kept, or the underlying evidence?”

Not: “Do I want signed or unsigned storage?”

Yes: “Am I writing a canonical claim that downstream retrieval must dispatch exactly, or an ambient observation?”

This is where ENGRAM keeps being the useful example. Its memory architecture has more than one substrate because those substrates do different jobs. Framed memories are what the agent learned. Raw transcript chunks are what actually happened. A canonical signed drawer is not the same thing as a loose working note. Those distinctions are not implementation trivia. They determine what kind of truth the agent is allowed to use later.

The wrong abstraction would make the agent manually inspect the store shape and compose its own retrieval plan from collections, metadata, hashes, and joins. That is table-brained design. It gives the model access to parts and calls that flexibility.

The better abstraction gives the model a question it can reason about:

• Do I need remembered interpretation?
• Do I need verbatim evidence?
• Do I need to write something canonical?
• Do I need to preserve an observation without pretending it is law?

Those are agent-level decisions. The backend can change under them.

▰▰MCP is the view, not the table

This is where the pattern stops being about tool naming and starts being about MCP design.

An MCP server should not expose the agent to the storage layout and then expect it to behave like a careful application engineer. That is not leverage. That is dumping schema into cognition.

A table says: here are the raw entities, good luck. Know which store is fresh. Know which one is cheap. Know which fields join. Know which source has authority. Know when the API is wasteful. Know when the database is stale.

A view says: here is the operation as the work understands it. The joins, precedence rules, freshness policy, and source quirks are already composed into a usable surface.

That is the right MCP contract.

The MCP is the data surface. The skill is the lens. The agent should reason with the domain data and the decision criteria, not with the backend shape. If the agent has to create joins in its head, route around rate limits by remembering infrastructure facts, or understand that one endpoint exists only because of how the storage layer is shaped, the MCP has not earned its keep.

Heavy-split and MCP views fit together because they solve opposite sides of the same problem.

Heavy-split says: do not bury load-bearing choices inside parameters.

MCP-as-view says: do not expose implementation boundaries as if they were choices.

The useful surface lives between those two failures. Too little split and the agent sleepwalks through meaningful tradeoffs. Too much split and the agent burns context reasoning about your architecture instead of the task.

The split is justified only when the tool name teaches the question the agent should ask.

That is the design standard. Not “one tool per backend.” Not “one mega-tool with a mode flag for everything.” A small set of tools that encode the work’s actual decision points.

This is also why “heavy” is the right word. Heavy means costly. Heavy means deliberate. Heavy means you do not spend it on cosmetic separation. You spend it where the wrong choice would make the system meaningfully worse.

The agent should not need to know the architecture.

It should know what kind of answer the task requires.