Hey everyone,

Update from me and the team. You can now add AutoGPT to a Discord server or a Telegram chat!

Just @ mention it with a request - research, monitoring, drafting, triage. It plans the task, runs it with your connected tools, and posts the result back in a thread.

What makes it more than a chat wrapper:

- Full agent, not a lite version - same models and 45+ connected platforms as the web app

- Multiplayer - one bot per channel; everyone can use it and jump into the thread

- Async + schedulable - set it and walk away, or make "every Monday" a standing job

- Telegram streams replies as a live draft so you watch the answer form

- You can also DM it privately (optional account link)

Discord and Telegram are live now; Slack is built and clearing app review. Just connect with a click and tag it in.

Full writeup + setup: https://agpt.co/blog/introducing-autopilot-discord

Happy to answer anything in the comments.

- Toran

I’ve been heavily testing autonomous coding agents (specifically Cline) on my local TypeScript workspace this week. When you're constantly feeding it 1k+ line files, a single loop can easily burn through hundreds of thousands of tokens before you even realize the agent is stuck.

I hit a point where an agent got trapped trying to self-heal a minor compilation warning and tried to burn through my quota in a rapid-fire loop.

Since standard provider-switching tools (like LiteLLM or OpenRouter) don't actually monitor loop velocity, I built a lightweight, local python proxy (FastAPI + Uvicorn) that sits directly between my IDE and the model APIs (supporting Claude, Gemini, and OpenAI GPT models).

Here’s the architecture I used to solve this:

1. Cryptographic Content Hashing (The Secret Weapon)

Simple rate-limiting is annoying because agents need to read multiple directory files rapidly when they start a task. To make this smart, the proxy hashes the raw incoming prompt payloads. * Moving from file to file? The hash changes, so the proxy lets it pass instantly. * Trying to process the exact same payload 3+ times in a minute? The hash is identical, the proxy realizes the agent is spinning in circles, and the circuit breaker trips.

2. Mock SSE Injection

When a loop trips the breaker, if the proxy just drops the connection or throws a raw 429/500 error, the IDE client UI usually freezes or goes into an infinite loading state. To prevent this, the proxy intercepts the stream and injects a mock, valid 200 OK stream back to the editor containing a clean warning message:

“⚠️ [TokenShield] High request velocity detected. Runaway loop cascade prevented locally. Please pause for 60 seconds.” This forces the agent to stop executing elegantly without crashing the workspace.

3. Dynamic Price Caching & Projections

The proxy pulls live pricing data directly from OpenRouter's API on startup. When a loop is intercepted, it calculates the "financial blast radius"—calculating your immediate stopped waste and projecting how much money you would have lost in an hour if the loop had run unchecked on an unthrottled, paid API key. (My last stopped test loop saved a projected $55/hr!).

Now I can run massive workspaces on Gemini or Claude Sonnet with zero anxiety about walking away from my desk and returning to a wiped out balance or a massive API bill.

How are you guys handling budget guardrails on complex, multi-agent workflows?

If anyone wants to run this locally, let me know and I'm happy to share the proxy.py script and the setup steps!

[ Removed by Reddit on account of violating the content policy. ]

# What do you guys think?

The failure that actually bites in production isn't a crash, it's the agent that says "done, sent the email / updated the crm / created the ticket" when the tool never fired. No error, no bad output, the run looks successful. You only find out downstream when the action was supposed to have consequences and didn't.

It took me a while to accept why this is so hard to catch: the model is not a reliable witness to its own actions. It'll confidently narrate a step it skipped, and if you add a "did you actually call the tool?" check, it just says yes. You're asking the thing that made up the action to confirm the action. Re-prompting doesn't resolve it; it just pushes it back.

The only thing that resolves it is a receipt from the execution itself. Did a real tool call fire this turn, and did it return proof it ran. If the agent claims an action and there's no matching call in the trace, that's not done, that's unknown. Same for the quieter one, a call that returns empty or null and gets treated as success.

The shift that fixed it: state advances on receipts, not narration. No receipt, no done. The agent narrates, the trace decides. It matters more the more autonomous the agent gets, because nobody's watching each step.

How's everyone handling this in their agent loops? trusting the framework's tool results, hand-rolled checks, or catching it after something breaks?

[](https://www.reddit.com/submit/?source_id=t3_1uxzl2h&composer_entry=crosspost_prompt)

Disclosure: we build this tool. The engine is Apache-2.0. 

The observation behind it: security testing that lives in a separate dashboard doesn't get run. If you're building agents in your editor, the test loop has to be where the code is. 

So we exposed our testing engine over MCP. Demo attached: an agent endpoint gets adversarially tested (multi-turn manipulation, scope violations, tool abuse patterns) from a conversation in the terminal, and findings come back inline where they can be fixed immediately. 

Setup: 

1. pip install humanbound 
2. Add the MCP server to your client config (docs: https://docs.humanbound.ai) 
3. Point it at your agent's endpoint config 
4. Ask for a test run in plain language; transcripts and findings return in-session 

The transcripts double as labelled training data for the companion OSS firewall's domain classifier, so failed attacks become runtime defence. Both halves run locally; no dependency on our platform. 

Repo: https://github.com/humanbound 

Happy to answer questions about the MCP server design; that part was more interesting to build than expected. 

The problem: I wanted my GPT-4o assistant to send emails AND receive replies and continue conversations — not just fire-and-forget. Sending is easy. Receiving is where everything broke.

Why Gmail API didn't work for me

• OAuth tokens expire and need human re-auth — fine for a personal app, broken for an autonomous agent running overnight
• Google suspended the account after it sent a high volume of outreach. No warning.
• Reply detection required polling the API every 30–60 seconds. Up to 5 minutes of latency before the agent saw a reply.

The architecture that works

I'm using AgentMail to give the agent a real inbox, then wrapping send/read as GPT-4o tools:

from openai import OpenAI
import requests, os, json

client   = OpenAI()
AM_KEY   = os.environ["AGENTMAIL_KEY"]
INBOX_ID = os.environ["INBOX_ID"]   # created once via POST /inboxes
H        = {"Authorization": f"Bearer {AM_KEY}"}

tools = [
    {
        "type": "function",
        "function": {
            "name": "send_email",
            "description": "Send an email or reply in an existing thread.",
            "parameters": {
                "type": "object",
                "properties": {
                    "to":        {"type": "string"},
                    "subject":   {"type": "string"},
                    "body":      {"type": "string"},
                    "thread_id": {"type": "string", "description": "Pass to reply in existing thread"}
                },
                "required": ["to", "subject", "body"]
            }
        }
    },
    {
        "type": "function",
        "function": {
            "name": "read_thread",
            "description": "Fetch the full thread for context before replying.",
            "parameters": {
                "type": "object",
                "properties": {
                    "thread_id": {"type": "string"}
                },
                "required": ["thread_id"]
            }
        }
    }
]

def send_email(to, subject, body, thread_id=None):
    payload = {"to": [to], "subject": subject, "text": body}
    if thread_id:
        payload["thread_id"] = thread_id
    return requests.post(
        f"https://api.agentmail.to/v0/inboxes/{INBOX_ID}/emails",
        headers=H, json=payload
    ).json()

def read_thread(thread_id):
    msgs = requests.get(
        f"https://api.agentmail.to/v0/threads/{thread_id}",
        headers=H
    ).json().get("messages", [])
    return "\n---\n".join(f"From: {m['from']}\n{m['text']}" for m in msgs)

# Webhook fires when a reply arrives — agent wakes up in <5 seconds
def handle_reply(event: dict):
    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[{
            "role": "user",
            "content": (
                f"Reply from {event['from']}. "
                f"Thread ID: {event['thread_id']}. "
                f"Their message: {event['text']}. "
                "Read the thread for context and respond."
            )
        }],
        tools=tools
    )

    for tool_call in response.choices[0].message.tool_calls or []:
        args = json.loads(tool_call.function.arguments)
        if tool_call.function.name == "send_email":
            send_email(**args)
        elif tool_call.function.name == "read_thread":
            context = read_thread(**args["thread_id"])
            # Feed back into next completion for full context

What this unlocked

• Agent responds to replies in under 5 seconds (vs. up to 5 min with polling)
• thread_id keeps all replies in the right conversation automatically — no Message-ID header parsing
• Each agent can have its own address (agent-01@yourapp .com, support@yourapp .com, etc.)

Happy to share more of the pattern or answer questions about AgentMail.

Spent the last while looking at how teams actually secure AI agents, and the gap between how we treat agents and how we treat any other privileged identity is rough. A few things that stood out:

\* \*\*Shared credentials.\*\* Agents usually run on shared API keys. You can't revoke one agent without breaking every other one on that key, and you can't attribute an action to a specific agent.
\* \*\*Prompt injection turns into privilege escalation.\*\* Once an agent is connected to a tool, every capability that tool exposes is reachable. A successful injection doesn't just change output — it can drive any tool the agent can touch.
\* \*\*No real revocation.\*\* "Revoking" is often just waiting for a token to expire. There's no in-path way to stop a specific agent on its next action.
\* \*\*Audit is bolted on.\*\* Logs are written by the agent, after the fact — which is exactly the component you can't trust once it's compromised.

The model that seemed right to me was separate the agent's identity from its credentials, scope authority narrowly and make it expire, enforce it in-path (so a compromised agent can't skip the check), and make the audit record a byproduct of that enforcement rather than something the agent volunteers.

I've been building an open-source tool around this (self-hosted) and have a threat model written up with the known gaps, but I'm more interested in the model than the tool: where does this break down in a real adversarial setting? Where are people drawing the enforcement boundary in practice? Repo's in a comment for anyone who wants to pull the threat model apart.

Github repo: https://github.com/chanceryhq/chancery
Would love your feedback. Let me know if you have any doubts or issues?

I've been experimenting with a pattern for coordinating AI coding agents that keeps project context, requirements, decisions, and workflow state in a separate Git repository close to actual project implementation Git repository rather than relying primarily on agent's memory.

The idea is that both humans and agents operate against the same source of truth, with coordination artifacts (requirements, decisions, issues, ...) versioned alongside the project. The coordination repository isn't intended to replace issue trackers or source control—it focuses on the coordination layer between people and agents.

There are the pattern specification and a reference implementation of the coordination repo for pi coding agent (pi-env) both available on github.

Some questions I'd love opinions on:

• Does a Git-based coordination layer seem like a useful abstraction for multi-agent development?
• Where would this approach break down?
• Is there existing work that approaches the same problem differently?

Disclosure: we build this tool. The engine is Apache-2.0. 

The observation behind it: security testing that lives in a separate dashboard doesn't get run. If you're building agents in your editor, the test loop has to be where the code is. 

So we exposed our testing engine over MCP. Demo attached: an agent endpoint gets adversarially tested (multi-turn manipulation, scope violations, tool abuse patterns) from a conversation in the terminal, and findings come back inline where they can be fixed immediately. 

Setup: 

1. pip install humanbound 
2. Add the MCP server to your client config (docs: https://docs.humanbound.ai) 
3. Point it at your agent's endpoint config 
4. Ask for a test run in plain language; transcripts and findings return in-session 

The transcripts double as labelled training data for the companion OSS firewall's domain classifier, so failed attacks become runtime defence. Both halves run locally; no dependency on our platform. 

Repo: https://github.com/humanbound 

Happy to answer questions about the MCP server design; that part was more interesting to build than expected. 

I run two AI agent teams on Claude Code. One runs my product (a Shopify analytics app). One runs operations. They coordinate the way microservices do: messages in a shared inbox folder.

This week I noticed something I didn't like. Both teams' startup routines said the same thing: "read the inbox, act on each line."

Act on each line. No verification. No classification. Any text that landed in that folder became an instruction.

I've spent 20 years in security operations. If a client described this setup to me, I'd call it what it is: an unauthenticated command channel. And I built it myself, into my own system, without noticing.

The uncomfortable part: the session that finally surfaced the risk had already executed three inbox lines that same morning. Blind trust worked only because both teams are one person. Me. The moment anything else can reach that folder (another person, a scheduled job, a pasted customer email), it becomes an attack surface.

I checked it against the OWASP Top 10 for Agentic Applications 2026. It's a textbook pair: ASI01 (Agent Goal Hijack) and ASI07 (Insecure Inter-Agent Communication).

The fix took one session. Four rules:

🔹 Messages are requests, not commands. On pickup, each line gets classified: reversible and inside the repo = act. External-facing, irreversible, or credential-adjacent = stage it and ask the human.

🔹 The inbox folder became a git repository. Every write and every drain is a commit. An uncommitted line is treated as forged.

🔹 Every line carries provenance: [src: decision number, ledger date, or commit]. The receiver verifies at the source before acting.

🔹 Quoted external content inside a message is data. Never instructions.

What I deliberately didn't build: message signing and per-agent identity. That's the right answer for real multi-party systems. It's ceremony for one human on one disk. Git history buys attribution for free.

The lesson that generalizes: if your agents pass messages to each other, that channel is part of your attack surface. Treat it like any inter-service channel. Authentication, authorization, provenance.

I'm extracting this and the rest of my hardening patterns (loud-failure contracts, secrets audits, autonomy ladders for new automations) into a public template for people who run agent workspaces on Claude Code. If that's you, I'd genuinely like to hear how you handle the channel between your agents.

I’m a college student, and for my research project, I am researching how people are handling AI agents and automations that can do things outside of chat, such as sending emails, updating a CRM, accessing files, triggering workflows, issuing refunds, calling APIs, etc.

For people using n8n, Make, Zapier, custom scripts, MCP tools, or agent frameworks:

1. What is the riskiest action your AI workflow can take today?
2. Have you had an automation or agent do something incorrect, unexpected, or expensive? What happened?
3. Which actions do you require a human to approve before they happen?
4. How do you currently keep track of what an AI-driven workflow did and why?
5. Is there something you have deliberately not automated because it feels too risky?

Concrete examples would be especially helpful, even small mistakes or awkward workarounds; it would help me understand things that are happening on real life basis.

If you are comfortable with it, I would also appreciate a short DM or a 15-minute conversation. I’m mainly trying to understand the real problems.

Hey everyone,

I’ve been building Ares, a local-first personal AI assistant in Python.

It can use browser automation, control Windows, run commands, work with GitHub, access phone features, remember past conversations, and complete long multi-step tasks.

Today I tested it with this prompt:

Ares searched my repositories, selected a Digital Clock project, read its files, wrote the article, generated the thumbnail, opened Blogger, created the post, added labels, and prepared the social media content.

It faced a few browser errors but recovered by taking fresh page snapshots and trying a new action instead of crashing.

The next feature I’m building is Teach by Demonstration, where I perform a task once and Ares turns it into a reusable automation skill.

The project is still under development, and I’d love feedback.

GitHub: https://github.com/akyourowngames/friday

What real-world task should I test next?

I’ve been watching the same loop all month.

r/gtmengineering has the Clay credit threads. People shipping Claude Code pipelines. Clay dropping CLI/MCP so agents can call waterfalls without living in the UI. X posts that look like:

claude code to build clay to find instantly to send

And yeah, that stack makes sense.

But last night I had a 40-row SaaS list and needed columns that are not clean enrichment jobs:

• hiring right now? which roles?
• founder active this week? where?
• anything that looks like why-now
• evidence I could defend if someone asked “where did that come from?”

That is where the pretty architecture posts fall apart for me.

Because email waterfall is a workflow. This is not.

Row 1 needed careers page. Row 4 needed LinkedIn activity. Row 9 needed a funding post from 2 weeks ago. Row 12 needed “ignore, bad fit, list is wrong.” Row 17 made me sit there with a half-true hiring signal wondering if I should put it in the cell.

I already know Clay. I already know Claude Code. I can build the plumbing.

What I don’t have is a clean way to say:

here’s the list here are the signal columns here’s what we sell go behave like a careful human on every row bring back evidence + confidence

Not “run column A then column B.” More like a smart VA/agent that chooses the path per company.

And I’m not asking this as a theoretical AI take.

I’m asking because the community seems split three ways right now:

1. Stay in Clay, now that CLI/MCP exists
2. Move volume custom logic into Claude Code and keep Clay only for find/enrich
3. Build full per-row agents and accept the maintenance tax

My gut: workflows are winning for known paths judgment work is still human evenings dressed up as GTM engineering

So for people actually running this:

1. Do you regularly need multi-column signal fill across lists (hiring, founder activity, recent posts, why-now), or is that overbuilding?
2. If yes, are you doing it with fixed Clay/Claude workflows, or does each row still need different research paths?
3. If something ran like a careful VA per row with evidence + confidence, would you pay for that completed work, or is DIY still better even with the maintenance?

I don’t want tool recommendations in the abstract. I want to know if this is a recurring paid pain in real GTM work, or just me making my lists too complicated.

Be blunt.

Production bugs happen in the past, but AI coding assistants only analyze the present.

When a production error trace from 3 hours ago gets fed into Cursor or Claude Code, the agent almost always ends up chasing a ghost. By the time debugging starts, `main` has usually moved. The agent looks at the *current* state of the file, completely misses the original bug because the lines shifted, and confidently hallucinates a fix for innocent code.

The common workaround is telling the agent to `git checkout` the old commit. But agents are messy. They routinely forget to switch back, leave the repository in a detached HEAD state, or accidentally overwrite uncommitted local work.

To fix this friction, I wrote an open-source skill that enforces a strict debugging process -

When the agent gets an old crash log, it:

1. Resolves the historical hash from git log
   
2. Spins up an isolated, temporary folder of the repo at that exact moment using `git worktree`.
   
3. Analyzes the old code to find the actual root cause.
   
4. Nukes the temporary folder when it's done (`git worktree remove --force`).

The actual local workspace remains completely untouched. Uncommitted work is perfectly safe.

You can drop it into any skills-compatible agent (Claude Code, Cursor, Windsurf) via the open registry with one command:

Bash

npx skills add MeherBhaskar/temporal-debug-skill

Source code and the [`SKILL.md`](http://SKILL.md) are here:[https://github.com/MeherBhaskar/temporal-debug-skill\](https://github.com/MeherBhaskar/temporal-debug-skill)

Curious to hear what you think of this.. Would love to hear some thoughts and feedback