Runtime release-control mediation for multi-agent execution paths

[SemeAIPletinnya]

I’ve been experimenting with a lightweight runtime release-control layer for multi-agent execution systems.

Core idea:

generation != release authority

In many agent systems, generated actions/tool calls implicitly become execution approval.

I’m exploring a separate runtime mediation layer between:

candidate generation
→ execution authorization

The runtime exposes tri-state mediation:

• PROCEED
• NEEDS_REVIEW
• SILENCE

The goal is not blocking autonomy entirely.

The goal is introducing bounded runtime review before unstable or unsafe execution paths are allowed to execute.

I think this becomes increasingly relevant for:

• multi-agent delegation chains
• tool execution
• recursive planning
• browser/shell execution
• autonomous long-running workflows
• external integrations

Interesting direction for AutoGen specifically could be:

• middleware-style execution mediation
• runtime governance hooks
• execution approval layers
• bounded escalation/review
• unsafe-path interception
• execution trace mediation

I recently deployed a small live runtime demo around this direction:
https://silence-as-control.vibenest.net/

Curious whether people working on AutoGen production systems are exploring similar runtime governance / execution mediation patterns.

[reallyticsai]

We’ve tackled similar issues in production, especially with autonomous agents running toolchains, browser, and shell actions. The risk isn’t just unsafe output—it’s premature execution from hallucinated or unintended actions. Decoupling generation from execution authority is crucial, and we ended up building a middleware layer with tri-state logic almost identical to yours: allow, review, silent.

Our stack uses FastAPI and Celery for orchestration. Agents output candidate actions to a queue; a mediation layer (Python class) inspects these, and then routes based on rules, heuristics, or even a lightweight ML classifier. Here’s a skeletal version:

class ExecutionMediator:
    def mediate(self, action):
        if self.is_safe(action):
            return "PROCEED"
        elif self.needs_review(action):
            return "NEEDS_REVIEW"
        else:
            return "SILENCE"

    def is_safe(self, action):
        # e.g. no shell commands, no financial ops, etc.
        return not ("rm" in action.command or "buy" in action.command)

In production, we log mediation outcomes and expose a trace API for auditability—critical for workflows with external integrations. For AutoGen, adding hooks for runtime mediation (like pluggable governance layers) would make multi-agent workflows much safer and more manageable. If you’re open to sharing more about your mediation logic or escalation heuristics, I’m interested to compare approaches.

[SemeAIPletinnya]

Interesting, one distinction I've been exploring is keeping the mediation layer explicitly separate from both generation and execution infrastructure.
In your example, the mediator appears to be part of the execution stack itself (rules, heuristics, classifier → route action).
What I'm experimenting with is treating release authorization as a standalone runtime concern:

candidate generation
=>release mediation
=> execution authorization
where the mediation result becomes an auditable runtime artifact rather than just an internal routing decision.
The tri-state outcome (PROCEED / NEEDS_REVIEW / SILENCE) is only one part of it. The more interesting question for me is whether execution authority should be modeled as a distinct runtime boundary rather than another orchestration rule.
Have you found that your mediation layer remains independent as agent complexity grows, or does it gradually become coupled to the orchestration framework itself?