Runtime guardrails for Go Micro agents

[ishita-0301]

I've been experimenting with agentic services lately, and one pattern I've found useful is separating orchestration from execution safety.

As agents become capable of calling tools and other services automatically, failures like infinite retries or repeating the same action can quietly consume resources without making progress.

To explore this, I've been looking at FailproofAI, an open source project that adds runtime guardrails such as loop detection and execution policies for AI agents: https://github.com/FailproofAI/failproofai.

I think this could pair nicely with Go Micro's service and agent model. Go Micro provides the building blocks for communication and orchestration, while a runtime safety layer can help ensure autonomous agents recover gracefully instead of getting stuck.

Curious if anyone else here has built similar safeguards into their Go Micro services or agents.

[asim]

Very intriguing and thanks for suggesting that. What could we do to provide better integration or guardrails? Is there anything we need to expose or do on our side?

[ishita-0301]

Thanks! I think the biggest win would be exposing lightweight lifecycle hooks around execution. For example, callbacks before and after a tool call, retry events, and a way to inspect or intercept repeated failures. That would make it much easier to plug in policies like loop detection, retry limits, or circuit breakers without changing business logic.

Even simple execution metadata like step counts, retry counts, and correlation IDs would go a long way toward building robust guardrails on top of Go Micro. I think keeping these primitives generic would let the community experiment with different reliability layers while staying true to Go Micro's design.

[asim]

Ok sounds like a good idea. In the interim here's a limit loop feature to try stop endless loop calling of the same tool.

#2968