Where should the AI agent control layer live?

[Keesan12]

MartinLoop can sit around coding-agent workflows, but there are multiple possible control points:

• local CLI
• MCP/tool boundary
• agent runtime
• CI
• hosted dashboard
• platform engineering workflow

For teams using Claude Code, Codex, Cursor, Aider, Cline, SWE-agent, or internal coding agents: where would this control layer be most useful?

[XuebinMa]

A useful framing here is that the "control layer" question gets sharper if you split it in two:

1. Should the next attempt run at all? — budget, iteration cap, verifier admission, halt reason.
2. Should this specific side effect leave the box? — this git push, this kubectl apply, this write to /etc, this outbound POST.

Different control points.

For (1) — the loop-governance layer MartinLoop owns — the best seat is the agent runtime, around the attempt → verify → record cycle. CI is too late (the spend already happened); local CLI works but misses CI-driven autonomous runs; the runtime is the only place that sees the full lifecycle.

For (2) — the outbound side-effect layer — the best seat is the tool / MCP boundary, on the way out of the agent. By the time you're at CI, the repo is already mutated; by the time the dashboard sees it, the outbound HTTP has already left. The tool boundary is the last spot where Deny or AskUser still costs nothing.

Concretely for the agents in your list:

• Claude Code — PreToolUse hooks are the natural seam for the outbound layer.
• Cursor / Cline / Aider — inside their own tool dispatch.
• SWE-agent — at the docker sandbox egress (net policy + mount scope).
• Codex CLI / OpenCode — same MCP/tool dispatch shape.

Hosted dashboard, CI, and platform-engineering workflow are downstream — they're useful for evidence and rollup, not for prevention.

Disclosure: this is the seam I'm working on. agent-guard sits at the tool-boundary side — per-call Allow / Deny / AskUser with signed execution receipts. MartinLoop sits at the runtime side for the loop-governance question. Different control points, different failure modes — both belong in the stack.

[GobiShanthan]

Thank you, this is a really helpful distinction.

I think your split is basically right:

the runtime layer answers “should the next attempt run at all?”
the tool boundary answers “should this specific side effect be allowed out?”
What MartinLoop is strongest on today is the first one: loop governance around budget, verifier admission, halt reasons, retry control, and run records. We also have some safety leashes around verifier commands and repo/file-change boundaries, but I wouldn’t claim that this version fully solves per-tool outbound side-effect mediation yet.

So the fair description of the current product is: MartinLoop is primarily a runtime governance layer in its current form, not yet a complete tool-boundary enforcement layer. That second control point is absolutely on our mind, and your framing is a very useful way to describe the gap clearly.

Really appreciate you taking the time to spell this out. Feedback like this helps sharpen both the architecture and the product language. If you’re interested, we’re also looking for more contributors and would love to have thoughtful people join us in shaping where this goes next. Please keep the feedback coming.