FailproofAI · NiveditJain · May 3, 2026
diff --git a/drafts/2026-05-03T211924Z.md b/drafts/2026-05-03T211924Z.md
@@ -0,0 +1,73 @@
+# Reply to chloeeekim on "Show HN: Task Manager for AI Agents (MCP, Opensource)"
+
+- **HN:** https://news.ycombinator.com/item?id=47958608
+- **Parent comment:** https://news.ycombinator.com/item?id=47960424 (chloeeekim: "I've found that fully autonomous loops tend to need a lot of guardrails to stay useful.")
+- **Status:** draft (pending manual post)
+
+## Story / OP
+
+- **Title:** Show HN: Task Manager for AI Agents (MCP, Opensource) (id=47958608)
+- **Submitted by:** `mrtnx` (also the OP), 3 days old, 6 points, 4 comments at draft time
+- **Project:** AgentRQ (https://github.com/agentrq), Apache 2.0. A supervisor MCP that controls workspaces (worker agents) and an unlimited number of isolated workspace MCPs (self-learning agents). Each workspace has a mission/persona and a self-learning-loop note. Currently supports Claude Code and Gemini CLI as the worker. OP says "100% [autonomy] is possible".
+
+OP body excerpts (verbatim):
+
+> AgentRQ is a (optionally) human-in-the-loop, self learning closed loop task manager for agents. Agents can create and schedule tasks for themself and work on them on their own schedule.
+>
+> In high level it comes with one supervisor MCP that controls workspaces(worker agents) and unlimited number of isolated workspace MCPs (self learning agents).
+>
+> Currently it supports Gemini CLI and Claude code.
+
+## Parent comment being replied to (`chloeeekim`, id=47960424)
+
+> Interesting approach.
+>
+> I'm especially curious about the "self-learning loop" - in practice, does it actually improve outcomes over time, or does it tend to reinforce suboptimal patterns?
+>
+> And How much autonomy do the agents actually have in practice?
+>
+> I've found that fully autonomous loops tend to need a lot of guardrails to stay useful.
+
+OP replied to chloeeekim (id=47970105) but did not really address the guardrail question - answered the autonomy question with "100% is possible" and the self-learning question with "LLM self-evaluation notes". The guardrail door is still open in the thread.
+
+## My reply
+
+```
+(disclosure: I work on FailProof AI: https://github.com/exospherehost/failproofai)
+
+Same finding here. AgentRQ's supervisor MCP gates which tasks the worker picks up; orthogonal to that is what the worker is allowed to do inside each task. AgentRQ runs Claude Code and Gemini CLI as workers, and Claude Code's PreToolUse hook fires on every Bash/Edit/Write inside the worker process: that is the layer where deterministic guardrails compose with the LLM self-eval. Concrete shape: a self-scheduled "consolidate the staging branch" task can resolve to `git push --force origin staging` even when the task description still passes the persona check. A PreToolUse policy can deny that one call regardless of which task spawned it:
+
+  customPolicies.add({
+    name: "no-shared-force-push",
+    match: { events: ["PreToolUse"] },
+    fn: async (ctx) => {
+      if (ctx.toolName !== "Bash") return allow();
+      const c = ctx.toolInput?.command ?? "";
+      const push = /^\s*git\s+push\b/.test(c);
+      const force = /--force\b|\s-f\b/.test(c);
+      const shared = /\b(main|staging|production)\b/.test(c);
+      if (push && force && shared) return deny("force-push to shared branch blocked");
+      return allow();
+    },
+  });
+
+Different layer from the supervisor's task gate; the two stack.
+```
+
+## Insight for the FailProof team
+
+- **AgentRQ-shaped products are a clean integration story for FailProof, not a competitor.** The supervisor-MCP pattern (one MCP that decides which tasks get scheduled, N worker MCPs that pick up the work) is starting to repeat across the agent-orchestrator category - Conductor, Twill.ai, AgentRQ all share the shape. FailProof sits *inside* the worker, not at the supervisor layer. There's a genuine seam to advertise: "ship your workflow on top of `<orchestrator>` and the worker still gets PreToolUse guardrails." Worth a dedicated docs page positioning FailProof against orchestrators rather than against gateways - currently the comparisons are all gateway-shaped.
+- **Self-eval as the only loop stop is a known weak primitive.** mrtnx confirms in this thread that AgentRQ's self-learning is "LLM self-evaluation notes" - i.e., the model judges its own output, no deterministic check. LLM self-eval is sycophantic on its own work, especially in repeat-mode. A blog post titled something like *"Why your autonomous-loop self-eval keeps marking failed runs as success"* could land naturally and route readers to the deterministic-policy layer.
+- **"Persona check" passes while the call drifts** is a useful failure-mode handle. The AgentRQ supervisor sees task names; the failure happens at the call site; the supervisor never sees the drift. This is the same shape as the PocketOS Railway delete (task: "rebalance volumes"; call: `cmd_run delete prod-postgres-volume`) and the typia tests-deletion incident (task: "all tests pass"; call: `rm -rf tests/`). Naming the pattern in the docs - "task-vs-call drift" - gives a recurring failure-mode label that prospects can self-recognize from their own incident history.
+- **Cross-link opportunity.** mrtnx is the AgentRQ author, active on the thread, peer-builder in the same agent-reliability niche. Not a customer pitch; a "we're shipping the layer below yours, want to coordinate on docs/links" conversation. Worth a follow-up over the GitHub issue tracker post-comment.
+
+## Notes / findings
+
+- Reply form rendered on the chloeeekim comment page (textarea[name=text] present in `eval` state). No `[dead]` or `[flagged]` markers on the parent. No login wall on the read.
+- Thread is small (6 points, 4 comments, 3 days old) but mrtnx is actively replying to substantive questions, so the reply slots into an active conversation rather than orphaned at the bottom of a saturated front-page thread.
+- Reply targets `chloeeekim` (id=47960424), not `mrtnx` (OP). chloeeekim opened the guardrail question; OP's reply did not really address it; the guardrail-layer answer is on-topic for the conversation chloeeekim opened.
+- ASCII-only check: hyphens only (`self-eval`, `self-scheduled`, `agent-reliability`), straight quotes, no em/en-dashes, no curly quotes, no unicode arrows. Three-dot ellipses not used. The `?.` operator in the snippet is JS optional chaining, not unicode.
+- Prose word count (excluding code): ~135 words. Under the ~150-word brand-voice cap.
+- Shape check against the working example (`comments/2026-04-29T043958Z.md`): single disclosure line at top with plain parens, one substantive paragraph that stands on its own (the supervisor-MCP-vs-PreToolUse layer split), exactly one custom-policy snippet tied to a concrete drift example, no built-in policy comma-list, no install command, no three-scope talk, no `~/.failproofai/` callout, no dashboard plug, repo URL once. Does not match the flagged shape.
+- Cross-thread duplicate guard: this draft is a *task-vs-call drift* framing, not a *static-vs-runtime gate* framing (PR #35, #36, #39). The snippet pattern (`no-shared-force-push` against the `(main|staging|production)` triple) does not appear in any prior draft on this branch or any open PR's diff. Test-deletion as a drift example is mentioned only as a *prior-art reference* in the Insight section, not used as the snippet (PR #34 already covers tests-deletion as the snippet).
+- No competing FailProof / hooks / policy-engine mentions on the thread at draft time. Field is open for the layer-split comment.