From Asking the Model to Do Less to Asking Runtime to Own Less: Model, Runtime, MCP, and Skill Responsibilities

A serious Agent project often goes through two phases.

First, models appear unreliable, so developers move more state, validation, permission, and completion decisions into Runtime. Second, Runtime becomes more reliable—and much heavier. It begins to own tool definitions, business classifications, data projections, and invocation semantics as well.

Our investment-research Agent has followed that trajectory.

The first question was what should the model stop maintaining? The later question became what should Runtime stop owning, even when the model should not own it either?

By September 30, 2026, several real refactors had suggested a clear principle:

Model handles semantic complexity; Runtime handles process complexity; MCP owns capability complexity; Skills describe methodological complexity.

We did not start with this architecture diagram. It emerged from mistakes and corrections.

This architecture emerged through actual refactoring rather than a single upfront diagram. Earlier work on removing synthetic MCP Tool layers produced partial implementation, but the overall replacement was never completed. We distinguish those historical designs from changes that actually reached the production call path.

1. Stop Making the Model Maintain Facts Runtime Already Knows

An early Research protocol asked the model to output a structured AgentTurn containing actions, gaps, and a completion claim:

{
  "actions": ["search"],
  "gaps": ["Additional evidence is still needed"],
  "completionClaim": false
}

The motivation was understandable. Tool activity should be auditable. Research requires recovery. The system needs to understand why work continues or stops.

But the protocol expanded. Permissions, tool lists, evidence gaps, Publication status, subgoals, and completion conditions increasingly appeared in model output.

The model was now doing two jobs:

Understand the user and choose the next action
+
Maintain a shadow copy of Runtime state

The second job was expensive and added no authority.

Runtime already knows which capabilities were granted, which tool calls happened, whether results returned, which Publications committed, whether a Run was canceled, and how much budget remains.

A model-generated account of these facts is only what the model believes. When it conflicts with Host receipts, Host facts win.

We moved Research toward a native tool loop. The model proposes its next Tool call. Host persists ModelTurn, execution results, receipts, and Publications; Runtime uses these real facts to govern Recovery and terminal state.

An internal September 20 record captured the principle:

Semantic decisions can belong to the model. Authority and recovery cannot.

The goal was not to reduce the rigor of system state. It was to eliminate the model's duplicate ownership of it.

2. Moving Deterministic Complexity into Runtime Is Right—Until It Goes Too Far

After the native-tool-loop transition, it felt natural to say that the model should not infer anything Runtime can determine:

Authorization
Budget
Invocation status
Cancellation
Checkpoint
Recovery
Receipt
Publication
Terminal gate

These are objective facts. For example:

remainingReadActions = 3

A model does not need to guess the budget or whether a receipt is durable.

But "Runtime should own deterministic process facts" slowly became "anything the model shouldn't own belongs in Runtime."

Those statements are not equivalent.

The real trouble began when Runtime started redefining the business capabilities themselves.

3. First Tool Consolidation: Multiple Definitions into One Contract

In September 2026, two successive revisions exposed duplicated tool definitions. On the 26th, the Host catalog and a production Runtime capability table maintained the same relationships independently; targeted checks confirmed that removing the duplicate lookup preserved authorized tool routes. On the 27th, Native Tool, Skill Context and Runtime Factory still each mapped model-facing tools to Host capabilities. Web search and read shared a route, risking exposure of unintended sibling methods.

The appropriate fix derived Host, Skill and model-tool exposure from one Tool Contract rather than three static interpretations. It reduced mapping drift; it did not prove the model's tool choices correct or change the original permission and dispatch facts.

That decision revealed the next problem: even one consolidated contract can belong to the wrong Owner. The separate A34 Tool Surface article examines whether the final model request actually carries authorized descriptors. This article stays focused on the broader Model / Runtime / MCP / Skill division of responsibilities.

4. The Deeper Question: Does the Remaining Owner Belong Here?

Portfolio MCP already offered precise scoped methods:

portfolio__get_portfolio_overview
portfolio__get_fund_position
portfolio__get_bucket_holdings
portfolio__get_sector_exposure

These methods have meaningful names, argument schemas, and result semantics. Yet Native Research sometimes exposed another synthetic wrapper:

read_portfolio({})

The call chain effectively became:

MCP Tool
  ↓
Research Tool Contract
  ↓
Model Tool
  ↓
Host Action
  ↓
mapReadCall
  ↓
MCP Tool

Every layer had a plausible justification: permissions, Skill ceilings, budget enforcement, inputs, and output limits.

But the need to govern a tool does not imply Runtime should redefine that business tool.

Portfolio already exposed "bucket holdings"; the model saw the blunter "read_portfolio." Runtime acquired business semantics as a side effect of wanting to govern execution—and flattened the useful capability distinctions.

We applied a deletion test: if the synthetic layer disappeared, would complexity spread across many callers or simply disappear?

For MCP-backed business Tools, much of what vanished was duplicate names, schemas, mapping code, and Host Action identities.

The genuinely necessary governance stayed:

Authorization
Budget
Hooks
Recovery
Receipts
Result-size bounds

Our progression therefore became:

Three Owners → One Owner
          ↓
Wrongly placed Owner → No shadow Owner

The current native-tool-surface.ts accepted MCP discovery descriptors and narrowed the tools visible on each turn. The earlier whole-layer replacement was not fully implemented, so partial wiring work should not be described as deployment of the original proposal.

5. Four Layers, Four Kinds of Complexity

5. Four Layers, Four Kinds of Complexity

graph TD
UserQuestion --> ModelSelectsAction
SkillGuidance --> ModelSelectsAction
ModelSelectsAction --> AvailableTools
AvailableTools --> PreToolHook
PreToolHook --> McpTool
McpTool --> PostToolHook
PostToolHook --> ModelContinues
RuntimeLifecycle --> AvailableTools
RuntimeLifecycle --> PreToolHook
RuntimeLifecycle --> PostToolHook

Architecture diagram

Additional relationships in the diagram are advisory or supporting: SkillGuidance helps ModelSelectsAction; RuntimeLifecycle supports AvailableTools, PreToolHook, and PostToolHook.

It illustrates responsibility. Existing implementation and local regressions reflect some of this separation, but the picture is not evidence that all deployments, Recovery combinations, and live-model paths have passed acceptance.

Model: semantic complexity

The model interprets intent and ambiguity:

What is the user really asking?
What information is missing?
Which source category should be examined next?
Which side of conflicting evidence needs investigation?
How should the result be explained?

These decisions are not universally expressible as deterministic rules.

Skill: methodological complexity

A Skill is a reusable method for a class of problems, not a data service.

For example, "Are my fund holdings redundant?" may need:

Inspect the whole portfolio
→ Check concentration
→ Read relationship evidence for candidate funds
→ Distinguish same product, same index, and measured constituent overlap
→ State data date and coverage

Skills may declare allowed tools, required attempts, or suggested answer structure. They should not independently download holdings, own sourceRef lifecycles, cache pages, or implement Recovery.

Skills describe how this kind of task should be approached.

MCP: capability complexity

MCP answers what the system can do.

The owner providing a business Tool should define its identity, description, input schema, and output semantics:

portfolio__get_bucket_holdings

This method already states a concrete capability: read holdings in a Portfolio bucket. Rewrapping it as a vague Runtime business Tool and mapping it back adds no inherent value.

MCP is a capability interface, not merely a data connector.

Runtime: process complexity

Runtime determines how one Run progresses:

Phase
Budget and usage
Cancellation
Checkpoint
Recovery
Receipt
Continuation
Publication orchestration
Terminal condition

It can state:

remainingReadActions = 3
phase = finalization-only

It should not redefine which business methods belong to Portfolio, Market, or Web merely because it owns those process facts.

6. One Portfolio Question, Four Different Responsibilities

Consider the synthetic user request:

Which funds do I hold in my dividend/low-volatility bucket, and is the exposure too redundant?

The following is a teaching example, not a real holding record or current wire contract.

The model interprets the task:

{
  "goal": "Inspect composition and potential redundancy in the dividend/low-volatility bucket",
  "nextStep": "Read this bucket's holdings, then fetch relationship evidence as needed"
}

The Skill provides methodology:

Do not infer redundancy from fund names.
Separate product relationships, identical benchmarks, and measured constituent overlap.
Partial look-through coverage is not a full-portfolio overlap ratio.

MCP provides actual capabilities:

portfolio__get_bucket_holdings
portfolio__get_portfolio_relationships

A simplified bucket-read result might be:

{
  "bucket": "dividend_low_volatility",
  "items": [
    {
      "fundCode": "F001",
      "fundName": "Example Fund A",
      "value": 10000,
      "weight": 0.08
    },
    {
      "fundCode": "F002",
      "fundName": "Example Fund B",
      "value": 7000,
      "weight": 0.056
    }
  ],
  "coverage": {
    "requested": 2,
    "returned": 2,
    "complete": true
  }
}

Runtime does not need to decide whether "too much dividend/low-volatility exposure" is a sensible investment assessment.

It needs to establish that the Portfolio capability was granted, the tool invocation is permitted, the result was received, size limits were respected, and the receipt was persisted.

Each layer handles the complexity it actually owns.

7. Hooks Govern Mechanics, Not Business Semantics

Returning business capability definitions to MCP does not remove deterministic checks from Tool execution. PreToolUse and PostToolUse remain useful for mechanical cross-layer governance.

PreToolUse: deterministic single-field corrections

Appropriate examples:

2026/9/30 → 2026-09-30
1万 (ten thousand) → 10000
Security-code normalization after a market is explicitly selected
Human-reviewed one-to-one enum aliases

These are stable when the field is identified, the mapping is unique, and no full-sentence interpretation is needed.

Inappropriate example:

"Tencent has fallen a lot recently"
→ Guess the user meant 0700.HK and wants to consider reducing exposure

That is semantic interpretation and belongs to the model.

PostToolUse: narrow and preserve, do not rebuild the business model

Useful behaviors include sensitive-field removal, bounded result projection, final size checks, and preservation of coverage/provenance.

If every tool result needs fresh classification, aggregation, pagination, or business-meaning reconstruction inside PostToolUse, that is evidence the Tool Interface may be wrong.

Return to MCP and define a scenario-appropriate view instead of growing a second business layer in Runtime/Hooks.

8. Three Comparisons: "More Centralized" Can Still Be Wrong

Example 1: AgentTurn → native tool loop

Before, the model maintained actions, gaps, completionClaim, and subgoals.

Afterwards, it proposed Tool calls while Runtime/Host owned execution facts.

The improvement was not merely fewer JSON fields; it was ownership of authoritative state returning to the layer that actually records it.

Example 2: three Tool mappings → one Tool Contract

The September 27 consolidation reduced static mapping drift. Necessary—but the correct count of Owners does not answer whether the remaining Owner belongs at the right abstraction.

A Runtime business Tool wrapping an already well-defined MCP capability is still a shadow Owner.

Example 3: green tests for a seam production no longer uses

Repository inspection exposed test-only legacy modules with no production consumers:

Production:
A → B → C

Tests:
T → LegacyModule

Green tests for LegacyModule prove that its interface still matches those tests. They say nothing about whether the current production path invokes it.

We introduced agent-retire-test-only-and-legacy-seams to move still-valid guards back to real production entry points and delete obsolete modules.

That work removed obsolete code such as build-context.ts and migrated useful assertions to the production boundaries. Other historical seams remained, so archival alone never meant the legacy structure had been eliminated everywhere.

This was not merely a proposal, but nor does archival prove live acceptance or that all historical seams disappeared. The 28 historical guard entries retained at that time were not a whole-repository zero-debt certificate.

As the design maxim goes: the interface is the test surface. When a production seam moves, tests must move to protect the current behavior rather than fossilizing obsolete architecture.

9. Clearer Ownership Does Not Weaken Failure or Permission Boundaries

Private tools must remain invisible before authorization

The target design excludes private Portfolio Tools from the per-turn Tool Surface before a capability grant. They may appear in the next ModelTurn after authorization. PreToolUse still checks that the actual invocation is permitted.

Visibility is not authorization.

Ambiguous mechanical canonicalization must stop

Date, amount, security code, or exact aliases may be normalized if the mapping is deterministic. If interpretation or multiple plausible mappings are involved, return structured correction feedback and let the model decide.

Oversized results must be explicitly unavailable

A complete portfolio list must not silently become "Top N" merely because the full result would not fit the model context.

Complete-or-unavailable is safer than a misleading apparent success.

Removing wrappers must not erase Web source state

If a Web wrapper owns real invariants—Run-scoped source handles, read-before-find rules, revocation—those responsibilities must migrate back to the appropriate Web MCP/Gateway before deleting the wrapper.

Removing indirection should remove duplicate Owners, not important security checks.

10. Five Questions for Locating Agent Logic

1. Does this require interpreting meaning? If yes, Model: user intent, investigation choice, conflicting evidence, explanation.
2. Does it describe how this task class should be performed? If yes, Skill: investment-overlap analysis, tool-attempt guidance, answer structure.
3. Does it define what the system can do? If yes, MCP/capability Owner: read portfolios, query funds, browse pages, fetch constituents.
4. Is it an objective state of the running task? If yes, Runtime: budgets, cancellation, receipts, checkpoints, Recovery, terminal settlement.
5. If this layer were deleted, where would its complexity go? If it spreads to callers, the layer may be valuable. If absorbed by a deeper Owner, deepen that Owner. If all that disappears is mapping, copied schemas, aliases, and tests for dead paths, deletion is probably right.

The fifth question prevents "three Owners → one" from becoming the end of architecture review. One Owner can still be the wrong Owner.

11. Separate the Current Structure from Historical Attempts

Native tool execution, tool contracts, and Host capability lookup have undergone real consolidation, reducing duplicate tool mappings and admission decisions. Earlier designs also left partially wired mechanisms without completing the full cutover. The presence of some code does not mean an entire architecture migration was deployed.

The case explains why even one remaining tool definition can live with the wrong Owner. Controlled regressions alone do not prove that models select tools better, investment research improves, or engineering costs fall. The transferable lesson is how to decide whether a capability calls for a new layer, a relocation, or deletion.

Conclusion: Put Complexity with the Right Owner

Our earlier principle was:

Do not ask the model to maintain facts Runtime already knows.

That helped us move from a heavyweight AgentTurn protocol to native tool calling.

Evolution added a second principle:

Runtime being able to execute something does not mean it should own that business concept.

A helpful shorthand is:

Model   → Semantic complexity
Skill   → Methodological complexity
MCP     → Capability complexity
Runtime → Process complexity

Hooks govern mechanical interactions, while Tool Surface presents the authorized capabilities of the current turn.

Good Agent architecture does not make complexity vanish or force all of it into Runtime.

The Owner of a fact maintains that fact. The provider of a capability defines its interface. Tasks that require interpretation belong to the model.

Moving from "let the model think about fewer system facts" to "let Runtime own fewer business concepts" is the same deeper move: returning complexity to the layer best suited to bear it.

This division follows principle 2, “Complexity belongs with its rightful owner”. Rather than moving every decision into Runtime, we place facts, capabilities, execution process and methods with their respective owners. During design review, method 2, “Reviewing responsibilities and rejections” asks who can decide, which effects a failure can block, and whether another owner's decision has been duplicated.

Further Reading

• Don't Turn the Model into a State Machine
• Run Budget and Constraint Governance

Evidence Sources

• September 20, 2026: Native Tool Loop, semantic decisions versus authority and Recovery.
• September 26, 2026: canonical Host catalog ownership of Research tool capabilities.
• September 27, 2026: Native Tool exposure consolidated into one Tool Contract.
• agent-remove-synthetic-mcp-tool-layer proposal and design.
• agent-retire-test-only-and-legacy-seams proposal.
• Native Tool lifecycle-hooks specification.
• Synthetic-layer partial verification and frozen retirement boundary.
• Legacy-seams verification and retirement records.
• Current Native Tool Surface implementation.