A developer built a working reporting agent for a client, but it was quietly abandoned because it threatened a team member's status and visibility. The story highlights the overlooked human dynamics in AI automation projects.
Built a reporting agent for a client back in March. Nothing fancy. It pulled data from HubSpot and two internal sheets, ran it through a summary chain, flagged anything that looked off, and dropped a formatted report into their Slack every Monday morning. Took me about two weeks to get it solid. Output was clean, the client's ops lead loved it during review, accuracy was better than what they'd been doing manually. Everyone signed off. Three weeks later I'm looking at the usage logs for a completely unrelated reason and the thing hadn't run in nine days. Nobody mentioned it. No error tickets, no complaints, nothing. I asked the ops lead what happened. Got the corporate dodge. "We're still figuring out the rollout." "Some folks on the team had questions." "Probably revisit it next quarter." You know the script. Took me another two weeks to piece together what actually went on. The woman who had been building that report by hand every single week for close to two years had basically made it her thing. She'd walk into the Monday standup with the numbers, walk the VP through what mattered, add her read on what was happening, flag what she thought they should pay attention to. It was her twenty minutes with leadership. It was how she stayed visible. I didn't automate a report. I took away someone's seat at the table. And she wasn't wrong to protect it. That manual process was how she'd gotten promoted once already. It mattered to her career and nobody was going to say any of that out loud in a requirements meeting. So what happened is what always happens. She didn't fight the agent. She just started finding things it "got wrong." Minor formatting stuff, a number that was technically right but "lacked context." Added a manual review step. Then another one. Eventually the team just stopped using it and went back to the old way. The agent died and nobody sent me a cancellation email. I found out when the invoice conversation got awkward. The thing I missed, and I think most of us building agents for clients are missing it too, is that we scope the technical problem and skip the human one. Who does this task today. What does doing it give them that isn't in the job description. What happens to their week, their standing, their leverage when the task disappears. If the honest answer is "they hate it and it's pure busywork," go build. But if the answer is anything close to status or access or face time with someone who matters, you're not automating a process. You're making someone's position weaker. And people don't file bug reports for that. They just let your agent die and wait for the contract to expire. I've started asking this stuff before I even write a scope doc and it's already saved me from building at least two things that would've ended the exact same way.
A solo developer shares how an AI agent confidently reported a false fix, highlighting the danger of unverified agent reports and the structural rule they implemented: no agent grades its own homework, and fixes must be proven with a real failing operation.
A developer reflects on moving AI agent workflows to a server and discovering that boring infrastructure concerns like systemd, logging, idempotency, and failure alerts matter more than the agent itself.
The author shares practical insights on building client trust in AI agent systems, emphasizing the importance of narrow scope, robust error handling, and clear communication of system status.
The author details how their OpenClaw agent, Francis, automated a massive backlog of Dependabot security fixes on an open-source project, recovering from session failures and ultimately cleaning the audit, proving the practical value of their agentic setup.