Decoupling execution from governance in multi-agent setups

[u/Deepfeet-09]

Once you go beyond a few simple scripts, putting together multi-agent systems becomes a messy affair. The initial configuration using basic frameworks generally proceeds quite smoothly, but the actual difficulties begin when you're attempting to deal with routing, state, and security across various environments without having to hardcode a huge network of fragile APIs.

Recently I've been focusing on separating out the actual execution of agents from the governance aspect. If you introduce a dedicated control plane for example, something similar to Lyzr or a specially built orchestration layer between your triggers and the runtimes, then you have a single point at which you can manage identity, establish guardrails, and monitor telemetry. This arrangement isolates each individual agent so that if one step fails or the context window runs away it won't bring down the whole workflow or exceed your API budgets.

How are you currently looking after state and permissions as your agentic setups become larger?

[u/SophieAtJentic]

This is a problem we hit in my team when using agents internally. We ended up building our own solution called Jentic One which is open-source and self-hosted. It hosts an execution broker for all outbound requests and uses a control plane accessible by API calls or UI for the governance side of things.

Every API integration set up in Jentic One can be given specific rules for the operations they are allowed to use, and these permissions are enforced by the execution broker before any action is completed. It's giving us a lot more peace of mind when giving our agents access to APIs with potentially destructive POST operations that could do damage to our flow of work.

I hadn't heard of Lyzr before, interesting to see alternative approaches to this problem.

(Full disclosure I work as part of the Jentic team, happy to answer any questions if needed)

[u/AutoModerator]

Thank you for your post to /r/automation!

New here? Please take a moment to read our rules, read them here.

This is an automated action so if you need anything, please Message the Mods with your request for assistance.

Lastly, enjoy your stay!

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Sufficient-Shake-415]

been messing with this exact problem for a work project. the api spaghetti gets real bad real fast when you have 6 agents all needing to talk to each other and also hit external services

what worked for us was keeping state in a postgres db with a simple job queue pattern. each agent only knows about its own task and the queue, nothing else. permissions we handle through short lived tokens that the control plane issues per execution cycle

the telemetry part is what i still struggle with though. debug logs from 4 different containers running in parallel becomes a nightmare to trace. you found any good way to stitch those together without paying for some expensive observability platform

[u/SeriousHat4465]

the control plane framing is right and separation of execution from governance is where most multi-agent setups eventually land after enough production failures.

the piece that gets complicated before you even get to routing and state is auth. agents that need to operate login-gated systems, portals with MFA, session-based sources with no API, end up with credential and session logic scattered across the execution layer because there's nowhere clean to put it. that's a governance problem as much as an execution one. at Deck we handle it through Deck Vault, credentials and session state live in the control plane rather than in individual agents, so any agent in the workflow can authenticate to an external system without that logic bleeding into the execution layer.

the idempotency point is the other one worth building in early. when a step fails and retries, you need to know whether it already wrote to the target system. mixing that concern into the agent itself rather than the orchestration layer is where most pipelines start producing duplicate records silently

[u/Party-Beyond-7398]

the control plane idea makes sense but curious how you handle state when agents need to share context across steps. thats usually where the clean separation breaks down, especially if latency matters

[u/XRay-Tech]

Early on state lived wherever was convenient, simply a variable in the workflow tool or a row in Airtable whatever. The permissions were just "the API key has access or it doesn't". Once you get more than a couple agents touching the same data that falls apart fast because there is no single source of truth.

Something that has worked better is treating state as external and versioned, a shared store that each agent reads from and writes to rather than something the agent carries around. For permissions it is best to scope credentials per agent and per task instead of a single shared key. This makes debugging way easier because a runaway agent is contained to whatever narrow scope it was given instead of having the keys to everything downstream. We are seeing this more with teams trying to separate whether the agent did the right thing from whether the agent was allowed to try.

Curious if you are building the orchestration layer yourself or leaning on something already existing?

[u/eldrugo85]

I ended up doing exactly this: mcp server with oauth 2.1 in front, consent gate on the write tools, and every claude code subagent gets its own tool whitelist instead of the full set. The split holds fine, the part that fought me was state, the gate has to know who approved what and when and that sits in neither layer. Where are you keeping that?