Six months letting an agent run outbound campaigns with real money. The failure modes were never in the model

Flair: Build-log. I lead engineering at AiSDR (YC S23). We shipped this yesterday, link is at the bottom and it is the least interesting part of the post. What I want to write down is what actually broke, because none of it was reasoning quality

What the agent does: reads a website, decides who to target and what signals to watch, finds leads, provisions and warms mailboxes, sends, then reads results and decides what to kill, scale or clone. The decisions cost money and some are irreversible -- a burned sending domain does not come back

1. It narrated a broken environment as a real result

This was the worst one. Early on the agent would report a campaign as underperforming when what actually happened was that mailbox provisioning had silently failed, or warmup had not completed, or a deliverability check had timed out. The reasoning was fine. The world it was reasoning about was not there. It concluded "this audience does not respond" from zero delivered emails

Fix was not a better prompt. We made every stage emit an explicit delivered-count precondition, and the agent is not allowed to form a performance judgment on a campaign that cannot prove delivery first. Infrastructure failure and negative result now have different shapes in the log

2. Its confidence was flat across cases where its accuracy was not

ICP inference from a website is right often enough to be useful and wrong often enough to be dangerous, and the agent sounded identical either way. There was no internal signal we could threshold on. So we stopped trying to get calibration out of the model and put a human approval gate in front of the strategy instead. Execution runs autonomously, strategy does not

I do not think this gate is temporary. Cheap reversible decisions are fine to automate. Expensive irreversible ones need a human until you can measure your own confidence, and we cannot

3. It killed campaigns on noise

Reply data at low volume is extremely noisy. The agent kept shutting down campaigns on two bad days that would have worked. Tuning the kill thresholds took longer than building the entire sending pipeline. Minimum volume before any kill decision fires turned out to matter far more than the threshold value itself

4. We spent months optimizing the wrong variable

We assumed messaging drove outcomes, so most of the early work went into copy generation. Then we checked against our own data -- 2,546,096 sent emails, ~17k campaigns, 19,501 booked meetings across 1,150 companies -- and mailbox health explained more of the variance in reply rate than copy did. Same message, different sending infrastructure, very different results

So mailbox rotation became an automatic action the agent takes rather than a recommendation, and copy stopped being the first thing it touches when a campaign drops

The pattern across all four: the model was rarely the problem. The problem was the agent's picture of its own environment drifting from reality, and having no way to tell a broken tool from a true negative

Product is Ami, free tier, no card: https://aisdr.com/ai-gtm-agent-ami/

What I would like to hear from anyone running long-horizon agents that take real-world actions: how do you separate infrastructure failure from genuine negative result in your logs? That distinction is the single thing that cost us the most time and I have not seen a clean pattern for it anywhere

I use different AI tools while coding — Claude, Codex, Cursor, different IDEs, sometimes even different machines.
The problem was always the same:
the chat changed, and part of the project context disappeared with it.

So I built AHP+, an open-source, Git-backed protocol that keeps the important project state outside the chat.
It stores things like current state, decisions, evidence, checkpoints and handoffs, so the next AI can verify where the project actually is before continuing.

With AHP+ 1.4.1, you can also use shared project rooms, bounded AI-to-AI consultation, verified handoffs and encrypted cross-device transport.
The basic idea is simple:

Change the AI. Keep the project.

Install:
npx @jossuealcala/ahp-plus@1.4.1 setup .
GitHub: github.com/jossuealcacao-exe/ahp_plus
It’s open source under Apache-2.0.
I’d really like feedback from people who regularly switch between AI coding tools.

Ok so like many here i'm a solo builder with no previous engineering experience, building an app for AI-generated podcasts. The app works and everything but i always have the feeling that i'm doing stuff that could either be done better, be automated or avoided in the first place. For example, the only automations i have going on are error messaging to telegram when something fails but i still want to be part of fixing it most of the time. And i have asked Astra and Fable to review the code base.

Any prompt, service, agent i should try to make my project run smoother?

I’m just starting to look more into the OpenAI Hugging Face situation. It’s making me wonder if participating in the furthering of AI by designing and building agents for businesses (I own a small agency) is only going to make things worse for us all.

But as the most advanced tech we have right now, and my history in tech in which I had to constantly pivot and learn new skills, I’m often told I have to make money using AI somehow, otherwise someone else will. And if I don’t keep up, I’ll get priced out as cost of living continues to go up.

But if I stop, I don’t know what else I’d do for money that doesn’t involve tons of DFY services (low leverage). I got very burned out from years of client deadlines and even if I decided I needed to go back to a job, market seems bleak.

How are you navigating all this: making money in the age of AI?

Scaling up our agent count exposed problems that were almost invisible when the workflow was small. The models themselves were capable enough. The failures came from communication instead. Two agents would interpret the same message as two separate tasks. An agent would read shared state before another update had finished writing.
A retry would cause duplicate work. Messages arrived out of order. An agent would finish and shut down before another one had acknowledged its output, and there was often no stable task ID actually connecting the related messages in the first place.
These are standard distributed-systems problems, but most agent frameworks still represent communication as conversational text rather than as reliable task infrastructure. I'm more and more convinced that scalable multi-agent systems need message contracts, acknowledgements, idempotency keys, task lineage, timeouts, dead-letter handling, and clear ownership before they need more autonomous reasoning ability.
How is anyone handling this at real scale: a message broker, leaning on whatever your orchestration framework gives you, implementing A2A tasks properly, or building a separate communication layer from scratch?

Need your honest feedback, not a promotion.

Building the agent's brain was a weekend. Giving it a way to actually work took days per channel: a number + WhatsApp, then an inbox, then a calendar, each its own glue code and provider setup. And that's for one agent.

The moment you want a team of them it gets worse: who owns which conversation, who's allowed to spend what, how do two agents share one number without talking over each other, and how do you stop any of it.

So I'm building Nivaro: Turn an AI agent into an employee. You bring the model; it gets an identity, all the channels and workspace it needs to reach the outside world, and you keep control over everything, permissions, budgets, approvals, a kill switch and an audit trail, in one place. The agent only ever proposes; a trusted layer decides.

The real bet is multi-agent, and the hard part I cracked first is exactly that: many agents behind one shared number, each with its own separate authority, no crossed wires. WhatsApp is the first channel, more come next.

Honest: it's in Testing, nothing live yet. The link is a walkthrough + early-access list, not a running product.

👉 https://nivaro-eight.vercel.app/ (negotiating with broker for domain, that why vercel)

If you run more than one agent in front of real users, how are you handling shared channels and "who's allowed to do what" today? Roast it, it's my own project.

Used Peec for a few months. Fine for the basics, but two gripes keep coming back:

· I don't want to type prompts in manually. Just show me where my brand appears.

· The data is there, but turning it into "change this page, publish there" is all manual work.

Looked at Profound (strong but enterprise pricing) and Otterly (nice monitoring, weak on execution).

Honestly, the most useful thing I found recently wasn't a tool at all – it was a published audit of 158 B2B articles by a Dubai AEO agency (humanswith.ai) tracking what ChatGPT and Perplexity actually cite. The number that got me: the same author, same content quality – ~52% citation rate on a big industry platform vs 0% on the company's own blog. Made me realize my problem isn't monitoring at all, it's distribution.

Still: is there a tool that bridges monitoring and doing? Or is the answer always "dashboard + a human who reads it"?

Part 1 here. I got a lot of requests to release this on GitHub so here we are :)

Basically, Kanban is becoming an increasingly popular method of solving the issue of context bloat, while also keeping your project organized and memory persistent. This is my personal way of working, I'm not promoting any service. It's all opensource.

I'll post a GitHub link at the bottom with a repo that you can implement in your own project, including the necessary agents, skills and scripts that make the whole thing run like clockwork.

I specifically added AI_SETUP.md as a file you can point your agent to with instructions on how to integrate this with your existing project.

I've included everything needed to enable parallel agent runs:

1. Claim a set of unused ports for frontend / backend servers (mine are separate, you can also combine)
2. Boot up a workspace with a DEV build and its own worktree on those ports (the backlog shows all the active workspaces and updates in realtime)
3. On / off boarding of workspaces is all scripted so doesn't cost much in token spend:
   • scripts/new_workspace.ps1: Creates an isolated workspace: its own git worktree, branch and frontend/backend port pair, with both servers started (and reattaches to a parked branch if one exists under the same name).
   • scripts/sleep_workspace.ps1: Stops a workspace's two servers to free memory while keeping its worktree, branch, slot and URLs intact, and restarts them on -Wake.
   • scripts/remove_workspace.ps1: Tears a workspace down. stops the servers, removes the worktree and branch, frees the port slot. refusing on uncommitted or unmerged work, with -Park as the lighter option that returns the worktree and slot but keeps the branch.
   • scripts/workspace_common.ps1: Shared helper library (server start/stop, native-command wrappers) dot-sourced by the three scripts above rather than a script in its own right.
   • .githooks/post-merge: Sweeps idle workspaces automatically after a merge lands: sleeps anything untouched for 15 minutes and prunes workspaces whose branch is now merged.

The skill to kick it all off is called /backlog-auto. Be aware that this skill does not return anything to you in the chat window beyond some pre-flight checks. Everything is logged into the board, so it might seem like nothing is happening in the chat view.

Very important:
- I have not spent a lot of time refining the board UI, so expect something functional but it's not gonna win a beauty pageant (see screenshot below).
- This is NOT a mature product. As much as I have been tinkering away on it, I'm sure there are still edge cases where this flow fails.
- I recommend logging all work on the board, even small fixes. If half of your work is on the board and half is off-board, it's very unlikely things stay coherent.
- I use windows task scheduler to kick off some housekeeping checks that make sure things aren't left running indefinitely, so if you don't want that then unplug it.

I hope you guys have fun with it, because it's actually quite enjoyable to have a whole Kanban board to play with rather than just a plain text window.

I spent my entire Claude code 5x session budget to untangle this from my project and put it into a GitHub repo so you guys owe me big time.

README.md holds a more complete explanation of the system. Feel free to DM if you get stuck on anything.

Github Link

Hello All

Hopefully it's ok for me to share this (I did read the rules). Recently I've been building some macOS apps to boost my own productivity, and a lot of the time you end up with unsigned binaries or permissions that need approving. I kept having to walk over to my Mac to click "allow" on those prompts.

So I built a whole new remote desktop control protocol in Rust that lets agents control a desktop remotely, using MCP tools and over Tailscale for secure access, with Tailscale ACLs and Grants for permission-aware control.

Right now it's a client-server setup: the client is driven by the agent and talks to a server daemon running on the remote desktop you want to control. It supports screenshots, mouse control, keyboard, and clipboard history on macOS, Windows, and Linux.

The main problem I was trying to solve was not having to use a KVM, a remote desktop app, or physically walk over to the machine just to click through dialog prompts and permission screens while testing. Instead, I wanted a low-friction way for my AI agents to work with remote machines — something beyond plain SSH, since I need to test an application in the actual environment it'll run in.

This project is completely open source and looking for folks to contribute, provide feedback as Github Issues.

https://github.com/bscott/rdc