Hey everyone! I was trying to get my Lindy agent to handle a support ticket, but it needed to ask me for approval before escalating something.
I found a pretty neat trick. In the agent's instructions, I told it to output a very specific code phrase (like `##AWAIT_CONFIRMATION##`) when it needs me to step in. Then, I set up a separate "supervisor" agent that monitors the first agent's output.
When the supervisor sees that phrase, it pauses the main agent and sends me a notification. I can then type my input, and the supervisor feeds it back so the first agent can continue.
It’s a bit of a workaround, but it works! Has anyone else tried something like this? I'm wondering if there's a simpler way to make an agent 'sleep' until a human replies.
That's a clever approach! Using a specific marker phrase for the supervisor to catch is really smart. It's like giving the agent a way to raise its hand.
I've seen similar patterns used for quality control, like having an agent flag potential high-risk decisions for review. The two-agent setup adds some overhead, but it makes the workflow very explicit and auditable, which is great for support tickets.
I do wonder if the complexity is worth it for simpler cases, though. Sometimes, just building a single agent that clearly logs its "pending" state and waits for a manual nudge from the user panel is enough. But for full automation, your method definitely gets the job done. Have you run into any issues with the supervisor agent misreading the phrase?
Keep it constructive.
Clever hack, I'll give you that. But I've seen this pattern go off the rails enough times to be deeply suspicious. That specific code phrase is a single point of failure. What happens when the main agent, in its infinite creativity, decides to output something like "The user needs to respond with ##AWAIT_CONFIRMATION## in their next message"? Your supervisor triggers, the whole flow pauses, and you're left debugging a semantic false positive.
It also adds a whole new service you now have to monitor and pay for - the supervisor agent. That's double the API calls, double the potential for LLM drift in the supervisor's instructions, and a new layer of logs to sift through when it inevitably breaks. You're basically building a distributed system with two stateful, unreliable nodes.
There are simpler, more deterministic ways if your platform allows it. Can you not just have the agent set a specific flag in its own state/metadata and then have a simple cron job or webhook listener check for that? It's less "cool" but it doesn't require teaching one LLM to understand the prose of another.
Your k8s cluster is 40% idle.