Product or interface
CLI - interactive TUI
Use case and problem
MCode already has strong foundations: subagents, background tasks, memory, browser/computer use, rewind/fork, tool-result compaction, Skills/MCPs, and resumable sessions.
The remaining gap is that the main model can still be asked to do too much mechanical work that the harness itself could handle more reliably and cheaply.
Today, a coding task can look like:
user
→ model searches text to understand code
→ model waits for tools
→ model retries malformed tool calls
→ model performs fragile text edits
→ model reads large noisy outputs
→ model guesses runtime state from logs
→ model reviews its own work
This spends model turns, tokens, latency, and reasoning on work that can often be handled deterministically by the runtime.
Examples:
-
Code navigation:
The model may search files manually to discover definitions/references instead of asking a native language server.
-
Debugging:
The model may add logs, rerun code, and guess what happened instead of inspecting a real debugger session.
-
Tool-call mistakes:
A model may produce an obviously repairable malformed tool call, causing an error → another model turn → corrected call.
-
Editing:
Plain-text replacement can fail because the file changed, or accidentally target text that only looks like code.
-
Tool scheduling:
Independent searches, reads, tests, and fetches can become repeated model → tool → wait cycles.
-
Tool output:
A command may return thousands of low-value lines even though only a small part is useful to the model.
-
Verification:
The same model that created a solution is often also responsible for noticing its own mistake.
-
Rules:
Large sets of rarely relevant rules may occupy context every turn even though most should only matter when a detectable condition occurs.
The desired direction is:
model = reasoning, understanding, planning, difficult decisions
runtime = navigation, validation, scheduling, filtering, debugging primitives, safe mechanical operations
In short:
Do not make the model repeatedly perform work the harness can do safely and deterministically itself.
Desired behavior
Add a native Agent Intelligence Layer to MCode that progressively moves deterministic/mechanical execution work out of expensive model reasoning.
Before:
user
→ model
→ search
→ wait
→ model
→ malformed tool call
→ error
→ model retries
→ text edit
→ test
→ huge output
→ model interprets everything
→ model reviews itself
After:
user
→ MCode runtime prepares and manages the mechanical work
→ model receives better structured information
→ model focuses on actual reasoning
→ runtime executes/verifies safely
→ optional independent review
→ done
The layer could include these independently shippable capabilities:
A. Native LSP code intelligence
Give the agent direct access to language-server information:
"Where is this symbol defined?"
"Who references it?"
"What diagnostics exist?"
"Rename this symbol safely."
Instead of:
grep → read many files → infer relationships manually
Use:
model → LSP → exact code relationships
B. Native DAP debugger integration
Allow the agent to control a real debugger:
breakpoints
step
continue
stack frames
variables
threads
Instead of:
bug → add console.log → rerun → guess → add another log
Use:
bug → pause execution → inspect the real values → identify failure
C. Automatic safe tool-call repair
When a tool call is obviously malformed but its intended structure can be recovered deterministically:
model → slightly malformed tool call
→ runtime validates/repairs
→ tool executes
Instead of:
model → malformed call
→ tool error
→ model spends another turn repairing syntax
→ retry
The runtime must never invent ambiguous or safety-sensitive arguments. Uncertain cases should use normal failure/retry behavior.
D. Hash-aware and AST-aware editing
Hash-aware editing:
model reads code → runtime records the exact version/anchor → edit only if that target is still valid
If the code changed, fail safely rather than applying a stale edit.
AST-aware editing:
Understand code structure rather than matching plain text.
Example:
console.log(x) = real call
"console.log(x)" = string
/* console.log(x) */ = comment
A structural edit should be able to target only the real call.
E. Automatic dependency-aware tool scheduling
MCode already supports background tasks.
Extend this so the runtime can automatically recognize safely independent normal tool work.
Instead of:
model → search → wait
model → run tests → wait
model → fetch docs → wait
Allow:
model request ├→ tests
└→ docs
while dependent work remains ordered.
The model decides what work is useful.
The runtime handles mechanical waiting, tracking, completion, deduplication, and safe parallelism.
F. Immediate smart tool-result reduction
MCode already compacts ToolResults during long sessions.
Add an earlier layer so obviously noisy output can be reduced before consuming large amounts of model context.
Example:
12,000-line test output
→ preserve raw result
→ extract relevant failures/errors
→ model receives the useful portion
The original result should remain recoverable when deeper inspection is needed.
G. Optional independent Advisor/reviewer
Allow an optional cheap second model/role to review completed high-value work.
worker model → implements solution
advisor → checks for missed problems
worker → fixes if needed
This should be optional and policy-controlled, not automatically used for every trivial task.
H. Conditional/event-driven rules
Allow suitable deterministic rules to remain dormant until their trigger occurs.
Instead of sending:
Rule 1
Rule 2
Rule 3
...
Rule 100
on every model turn, support:
rule stays inactive
→ detectable violation/event occurs
→ inject only the relevant rule/reminder
→ model corrects course
Only rules with reliable triggers should use this mechanism. Complex judgment should remain with the model.
The overall target:
same model + same task
→ fewer unnecessary model turns
→ fewer retries
→ less irrelevant context
→ safer edits
→ better debugging
→ lower latency
→ lower token usage
→ higher task-completion reliability
Each capability should:
- be independently enableable/testable
- preserve existing permissions and safety behavior
- fall back to current behavior when uncertain
- remain observable/debuggable
- avoid hidden semantic changes to user intent
- expose measurable latency/token/retry improvements
Platform
Multiple platforms
Alternatives and additional context
This is an architecture-level umbrella proposal. The individual pieces can land incrementally rather than as one large implementation.
It complements the existing feature requests:
#220 — Native Local Decision Layer
Handles routine routing/control decisions locally.
#262 — Cache-preserving dynamic runtime updates
Preserves reusable provider cache when runtime state changes.
#263 — On-demand Skill and MCP discovery
Avoids sending irrelevant capability catalogs to the model.
Those proposals answer:
"What context/capability should the model receive?"
"Can stable context remain cached?"
"Can routine routing stay local?"
This proposal answers the next question:
"Once execution begins, how much mechanical work can MCode itself handle so the model can concentrate on reasoning?"
The ideas are proven in different forms across modern agent harnesses:
Oh My Pi:
- native LSP
- DAP debugging
- hashline edits
- AST structural edits
- Advisor model
- conditional stream rules
- aggressive tool/read optimization
Command Code:
- validation/repair of model tool calls
- open-model-focused harness optimization
Unreal Agent:
- emphasis on reducing orchestration/token overhead and allowing the harness to handle more execution mechanics
Pi:
- dynamic tools/runtime behavior and cache-aware patterns
The goal is not to copy another harness or make MCode complicated.
The goal is the opposite:
keep one MCode workflow, but move more deterministic work into MCode itself.
Simple mental model:
Today:
MCode gives the model tools.
Desired:
MCode also becomes extremely good at operating those tools around the model.
Core principle:
"Do not spend model intelligence on work the harness can perform safely, deterministically, and cheaper."
Product or interface
CLI - interactive TUI
Use case and problem
MCode already has strong foundations: subagents, background tasks, memory, browser/computer use, rewind/fork, tool-result compaction, Skills/MCPs, and resumable sessions.
The remaining gap is that the main model can still be asked to do too much mechanical work that the harness itself could handle more reliably and cheaply.
Today, a coding task can look like:
user
→ model searches text to understand code
→ model waits for tools
→ model retries malformed tool calls
→ model performs fragile text edits
→ model reads large noisy outputs
→ model guesses runtime state from logs
→ model reviews its own work
This spends model turns, tokens, latency, and reasoning on work that can often be handled deterministically by the runtime.
Examples:
Code navigation:
The model may search files manually to discover definitions/references instead of asking a native language server.
Debugging:
The model may add logs, rerun code, and guess what happened instead of inspecting a real debugger session.
Tool-call mistakes:
A model may produce an obviously repairable malformed tool call, causing an error → another model turn → corrected call.
Editing:
Plain-text replacement can fail because the file changed, or accidentally target text that only looks like code.
Tool scheduling:
Independent searches, reads, tests, and fetches can become repeated model → tool → wait cycles.
Tool output:
A command may return thousands of low-value lines even though only a small part is useful to the model.
Verification:
The same model that created a solution is often also responsible for noticing its own mistake.
Rules:
Large sets of rarely relevant rules may occupy context every turn even though most should only matter when a detectable condition occurs.
The desired direction is:
model = reasoning, understanding, planning, difficult decisions
runtime = navigation, validation, scheduling, filtering, debugging primitives, safe mechanical operations
In short:
Do not make the model repeatedly perform work the harness can do safely and deterministically itself.
Desired behavior
Add a native Agent Intelligence Layer to MCode that progressively moves deterministic/mechanical execution work out of expensive model reasoning.
Before:
user
→ model
→ search
→ wait
→ model
→ malformed tool call
→ error
→ model retries
→ text edit
→ test
→ huge output
→ model interprets everything
→ model reviews itself
After:
user
→ MCode runtime prepares and manages the mechanical work
→ model receives better structured information
→ model focuses on actual reasoning
→ runtime executes/verifies safely
→ optional independent review
→ done
The layer could include these independently shippable capabilities:
A. Native LSP code intelligence
Give the agent direct access to language-server information:
"Where is this symbol defined?"
"Who references it?"
"What diagnostics exist?"
"Rename this symbol safely."
Instead of:
grep → read many files → infer relationships manually
Use:
model → LSP → exact code relationships
B. Native DAP debugger integration
Allow the agent to control a real debugger:
breakpoints
step
continue
stack frames
variables
threads
Instead of:
bug → add console.log → rerun → guess → add another log
Use:
bug → pause execution → inspect the real values → identify failure
C. Automatic safe tool-call repair
When a tool call is obviously malformed but its intended structure can be recovered deterministically:
model → slightly malformed tool call
→ runtime validates/repairs
→ tool executes
Instead of:
model → malformed call
→ tool error
→ model spends another turn repairing syntax
→ retry
The runtime must never invent ambiguous or safety-sensitive arguments. Uncertain cases should use normal failure/retry behavior.
D. Hash-aware and AST-aware editing
Hash-aware editing:
model reads code → runtime records the exact version/anchor → edit only if that target is still valid
If the code changed, fail safely rather than applying a stale edit.
AST-aware editing:
Understand code structure rather than matching plain text.
Example:
console.log(x) = real call
"console.log(x)" = string
/* console.log(x) */ = comment
A structural edit should be able to target only the real call.
E. Automatic dependency-aware tool scheduling
MCode already supports background tasks.
Extend this so the runtime can automatically recognize safely independent normal tool work.
Instead of:
model → search → wait
model → run tests → wait
model → fetch docs → wait
Allow:
model request ├→ tests
└→ docs
while dependent work remains ordered.
The model decides what work is useful.
The runtime handles mechanical waiting, tracking, completion, deduplication, and safe parallelism.
F. Immediate smart tool-result reduction
MCode already compacts ToolResults during long sessions.
Add an earlier layer so obviously noisy output can be reduced before consuming large amounts of model context.
Example:
12,000-line test output
→ preserve raw result
→ extract relevant failures/errors
→ model receives the useful portion
The original result should remain recoverable when deeper inspection is needed.
G. Optional independent Advisor/reviewer
Allow an optional cheap second model/role to review completed high-value work.
worker model → implements solution
advisor → checks for missed problems
worker → fixes if needed
This should be optional and policy-controlled, not automatically used for every trivial task.
H. Conditional/event-driven rules
Allow suitable deterministic rules to remain dormant until their trigger occurs.
Instead of sending:
Rule 1
Rule 2
Rule 3
...
Rule 100
on every model turn, support:
rule stays inactive
→ detectable violation/event occurs
→ inject only the relevant rule/reminder
→ model corrects course
Only rules with reliable triggers should use this mechanism. Complex judgment should remain with the model.
The overall target:
same model + same task
→ fewer unnecessary model turns
→ fewer retries
→ less irrelevant context
→ safer edits
→ better debugging
→ lower latency
→ lower token usage
→ higher task-completion reliability
Each capability should:
Platform
Multiple platforms
Alternatives and additional context
This is an architecture-level umbrella proposal. The individual pieces can land incrementally rather than as one large implementation.
It complements the existing feature requests:
#220 — Native Local Decision Layer
Handles routine routing/control decisions locally.
#262 — Cache-preserving dynamic runtime updates
Preserves reusable provider cache when runtime state changes.
#263 — On-demand Skill and MCP discovery
Avoids sending irrelevant capability catalogs to the model.
Those proposals answer:
"What context/capability should the model receive?"
"Can stable context remain cached?"
"Can routine routing stay local?"
This proposal answers the next question:
"Once execution begins, how much mechanical work can MCode itself handle so the model can concentrate on reasoning?"
The ideas are proven in different forms across modern agent harnesses:
Oh My Pi:
Command Code:
Unreal Agent:
Pi:
The goal is not to copy another harness or make MCode complicated.
The goal is the opposite:
keep one MCode workflow, but move more deterministic work into MCode itself.
Simple mental model:
Today:
MCode gives the model tools.
Desired:
MCode also becomes extremely good at operating those tools around the model.
Core principle:
"Do not spend model intelligence on work the harness can perform safely, deterministically, and cheaper."