Default app/control access for user sessions

[smart-lty]

Hi Nick! Thanks for building MonoCode. I use it every day and have been running a personal fork with a few additions. I'd like to ask about something before going further.

Would you be open to making app and control access available to every user-started session by default, without /operator or /orchestrator? Only sessions and agents spawned by an agent would be restricted, for example from delegating further or raising their own permissions.

My main motivation is simplicity. In my fork, much of the complexity, and many of the bugs I hit, came from tying control access to the run lifecycle: granting and revoking credentials, rejecting actions when a run isn't active, and recovering after a pause or stop. If access followed the session and tasks were tracked independently, I think a whole class of these states would go away. Does that match your view, or are there constraints I'm missing?

[hardbeat920]

My concern is if we bake in /operator and /orchestrator on every session that means we probably need to attach this context at the start or though other means which might have an effect on the model itself

How are you thinking about it and what's the motivation?

[smart-lty]

Thanks, that's a fair concern. I'd keep /operator and /orchestrator exactly as they are, as prompt injections, similar to skills. Sessions without them would get no extra context, so the model wouldn't be affected.

What I'd remove is only the access gating. The app and control CLIs would work in any user-started session, and only sessions and agents spawned by an agent would be restricted. The commands would decide what the model is told. Whether a call is allowed wouldn't depend on them.

My motivation is reducing state. Most of the bugs I hit in my fork came from tying access to the run lifecycle: credentials granted and revoked with the run, actions rejected while it's paused or stopped, and recovery after interruptions. For example, I interrupt the lead to change working direction, but it cannot delegate or monitor its agents due to monocode control credentials.
Without that coupling, I think much of this state would go away.

Related to your concern: the orchestration instructions (around 700 tokens) are currently appended to every lead turn while a run is active, including automatic continuations. Would this every-turn injection affect the context and model attention?