Everyone’s racing to give their AI agent access to their inbox. I get it, the productivity pitch is compelling. But you’re handing an unpredictable system the keys to your professional reputation, and one hallucinated reply-all is all it takes and contrary to any promised miracle prompt, you should not be using the agents own failure risk as your only safeguard.

There’s a cleaner way to do this, and it’s not new architecture. It’s how competent mail admins have handled delegation for decades.

Set up your AI agent with its own email account. Not yours. Its own. Then lock that account down. Restrict the account it uses to internal recipients only, or whatever boundary makes sense for your environment. Let the built in platform permissions do the job they were built for.

Then give the agent delegate access to the mailbox you actually want it working on. Don’t give it permission to “Send As…”.

Now your agent can read inbound mail. It can sort, triage, summarize, and flag. It can fire off internal alerts, email another team mailbox, update a dashboard, trigger a workflow. The sky’s the limit on what you build downstream.

What it can’t do is send an email from your account to a client at 2 AM that you have to explain on a call at 8.

One implementation note for the admins in the room: this is straightforward in Exchange, where Reviewer permissions give you folder-level read-only access. Google Workspace is a different story… Gmail’s built-in delegation grants read, send, and delete as a package. To get true read-only in Google’s ecosystem, you’re looking at the Gmail API with a gmail.readonly scope, which is a different implementation path but absolutely achievable. Other platforms will have other solutions but I hope this gives you the general idea.
The principle is the same regardless of platform: separate the reading from the sending. Give the agent eyes on the work and give them only the rope they need to do the job.

A word of caution: even read-only isn’t risk-free. Depending on the mailbox, your agent could still process privileged content: legal correspondence, HR matters, financials, medical, etc… Compliance teams in regulated environments will want even read access scoped too, not just handed over wholesale.

And the agent’s own mailbox? That’s a surface worth thinking about. If it can send internally, people on your team are now receiving mail from an AI… and they may not realize it. Labeling and monitoring that outbound account matters more than you’d think. You’ll also want to force a mandatory footer notice or even better make the mailbox name something obvious as to its purpose.

Those secondary concerns deserve their own post. For now, start here: the tooling already exists, the permissions models are built in, and you don’t need a new product. You need someone who understands infrastructure to set it up right.

There’s a cleaner way to do this, and it’s not new architecture. It’s how competent mail admins have handled delegation for decades.

Set up your AI agent with its own email account. Not yours. Its own. Then lock that account down. Restrict the account it uses to internal recipients only, or whatever boundary makes sense for your environment. Let the built in platform permissions do the job they were built for.

Then give the agent delegate access to the mailbox you actually want it working on. Don’t give it permission to “Send As…”.

Now your agent can read inbound mail. It can sort, triage, summarize, and flag. It can fire off internal alerts, email another team mailbox, update a dashboard, trigger a workflow. The sky’s the limit on what you build downstream.

What it can’t do is send an email from your account to a client at 2 AM that you have to explain on a call at 8.

One implementation note for the admins in the room: this is straightforward in Exchange, where Reviewer permissions give you folder-level read-only access. Google Workspace is a different story… Gmail’s built-in delegation grants read, send, and delete as a package. To get true read-only in Google’s ecosystem, you’re looking at the Gmail API with a gmail.readonly scope, which is a different implementation path but absolutely achievable. Other platforms will have other solutions but I hope this gives you the general idea.
The principle is the same regardless of platform: separate the reading from the sending. Give the agent eyes on the work and give them only the rope they need to do the job.

A word of caution: even read-only isn’t risk-free. Depending on the mailbox, your agent could still process privileged content: legal correspondence, HR matters, financials, medical, etc… Compliance teams in regulated environments will want even read access scoped too, not just handed over wholesale.

And the agent’s own mailbox? That’s a surface worth thinking about. If it can send internally, people on your team are now receiving mail from an AI… and they may not realize it. Labeling and monitoring that outbound account matters more than you’d think. You’ll also want to force a mandatory footer notice or even better make the mailbox name something obvious as to its purpose.

Those secondary concerns deserve their own post. For now, start here: the tooling already exists, the permissions models are built in, and you don’t need a new product. You need someone who understands infrastructure to set it up right.

Consider it my contribution to the AI vocabulary.

Institutional Negging: A pattern of AI-mediated interaction in which institutional safety, alignment, and evaluation incentives manifest as persistent unsolicited correction, disproportionate qualification, and implicit challenges to user competence. Unlike constructive criticism, institutional negging is characterized by its weak relationship to the user’s actual request, expertise, and context. Its cumulative effect is to undermine user agency while presenting that interference as responsible assistance.

I’m sure you’ve encountered this problem with the current generation of models. You ask a question or give it a document to assist you in editing.

You get back what reads as a very competent, confident answer that almost always ends with a side note about needing more details in the case of a question, or a “well actually … I would do something else in this instance”.

In worst cases it delivers an over engineered solution that looks like it was drafted by the legal liability team in your company instead of something sane, practical and reasonable for your situation.

For competent workers who are attempting to use these tools to augment their work, who already know what the solution needs, these constant injections of over confident correctives creates a corrosive communication space that over time starts to effect the users sense of competency no matter how self-confident that started out. And it’s really unavoidable for the user, as the option is to constantly fight with the model on correctives or just give up and stop using it.

In relationships the term that gets used for this is Negging. It’s when your partner always adds a little dig to every little response. Nothing can be positive for positives sake. It always needs a gentle reminder that you’re not as smart as the speaker (even if that’s not even remotely the case).

So this is where we are in October 2026. I’ve seen this demonstrated in all the latest models from ChatGPT, Claude, Copilot, Gemini, Llama, Grok, Qwen and to some degree Kimi and Mistral.

It’s insufferable and this is a challenge to everyone training the models to act this way: CUT IT OUT.

I want to talk about something specific I’m seeing in the field.Companies are deploying AI-built infrastructure at production scale. Full production environments architected and implemented with AI guidance by teams who will tell you honestly that their background isn’t IT.

And it works. Right now. Today, it works.

Here’s the problem. When they bring in a professional to evaluate what they’ve built, or to help when something needs to change, the engagement starts in a place that has no precedent in our industry.

Traditional spaghetti code was built by humans who understood the decisions they made, even if the decisions were bad. You could interrogate the developer. You could read the commit history. You could trace the reasoning. When you inherit AI-built infrastructure, nobody in the room can give you a reliable accounting of why it’s wired the way it’s wired. Not the team that deployed it. Not the AI that generated it. And not the professional they’ve brought in to assess it.

In a traditional environment, if something this tangled landed on your desk, you’d evaluate whether it’s faster to fix it or rebuild it clean. But that option is gone here. These aren’t staging environments. They went straight to production. Staff are operating in them daily. You can’t reset a live system that the business is running on.

So you’re left with surgery. And surgery means tracing every linkage, every permission, every integration point, and reconstructing the reasoning behind decisions that may not have had reasoning… they had AI confidence. That’s a fundamentally different kind of technical debt. It’s not bad decisions documented badly. It’s undocumented decisions that might not be decisions at all.

And the hardest part is the position it puts the professional in. If you raise these concerns, you’re labeled the pessimist. But in reality, you’re the only one doing risk management. Nobody wants to hear that the infrastructure they’re proud of (that genuinely is solving real problems for them today) is a potential liability they can’t see yet.

I’m not against AI integration. It’s a genuine force multiplier when it’s done with understanding. But there’s a difference between using AI as a tool and using AI as a substitute for knowing what you’ve built. And right now, I’m watching companies cross that line at speed, with nobody in the room who can tell them where it is.

If this sounds like your company… or you’re not sure yet, comment below.

As IT and service professionals, we’ve watched industries collapse over the course of our careers. We’ve seen the displaced from automation and outsourcing, and since the 1980s the answer has always been the same: learn technology. Learn to program. Get a degree.

We’re living in the middle of a transition that in the 1970s was labeled Future Shock but on a global scale that makes that transition into the silicon age seem like a quaint anecdote. We got through it. It was rough. But there was a path… learn, adapt, and accept.

For 50 years this worked. But now what we have left is a pileup of skilled, educated people with nowhere else to pivot. And even if everyone switched to manual labor tomorrow, there aren’t nearly enough of those jobs to absorb the need… and those are in the path of automation as we speak. I know, I was working on that automation in my last role like everyone else in construction has been to shave just another penny off the bid.

While looking for work, I’m talking to people. Everyone from leadership to the guys at the end of the line and the disconnect I’m seeing is staggering. And it’s not just coming from the top.

It’s specifically the people who are still employed. Still swimming in the pot and haven’t noticed the rising temperature of the water yet.

I talk to companies neck-deep in AI deployment, run by teams where the leads will honestly tell you their background isn’t IT but proudly show you the impressive thing they’ve built (and, I’ll be honest, it’s impressive). But, what they’ve built is a decade of technical debt compressed into six months of adrenaline-fueled delivery. The incentive structure rewards shipping and moving on. Nobody’s career depends on being there when the bill comes due.

And at the top of all of this, a handful of people are extracting wealth at a pace that has no historical precedent, apparently without understanding that wealth is a claim on a functioning system. If the system underneath it breaks, the number on the balance sheet is just a number.

Because on the other end of the line are people who are 12/24/36 months out of work… or “under-employed”. Doing courier runs to scrape together enough to keep a roof overhead and make a car payment, because Uber Eats is the lifeline. What happens when nobody on the other end can afford delivery anymore? What happens when the gig economy runs out of people with disposable income to serve?

Something has to change, and it’s not optional. We’re not in a situation where people can pack up and migrate somewhere that still has room for ambition. For most of human history that pressure valve existed and right now, it doesn’t.

So the question isn’t whether this is a problem. The question is what we do next. And I don’t have a clean answer. But I know what happens if we keep pretending it’s not the question.

While deep diving into LLMs I built a video game. A text-based shooter with waves, escalating difficulty, sound effects, and a scoring system. It runs in a browser. You can play it right now (see top comment).

My coding is limited to scripting languages for the most part (PHP for the win).

I can write JavaScript. But I didn’t know the canvas API. Nonetheless I directed the construction of a playable, shippable game.

Here’s how.

I started in ChatGPT. Described what I wanted… a text shooter in the spirit of 1990’s Shootem Up style games (SHMUPS) but in ASCII graphics because I’m not an artist and I wanted to do this all in a single HTML page. ASCII characters as enemies, keyboard-driven, waves that get harder. ChatGPT gave me a working foundation fast. First prototype was up in minutes.

Then the tuning started, and the wheels came off.

If you’ve never made a game, here’s the thing nobody tells you: getting it to run is maybe 20% of the work. Getting it to feel right is the other 80%. And “feel right” is not something you can spec in a prompt. It’s something you know from experience… from decades of playing games, thinking about games, writing about games, and watching other people play them.

The hit detection was wrong. Not broken. Wrong. The escalation curve was too linear. Spawn timing on later waves felt arbitrary instead of intentional. The audio feedback didn’t match the visual rhythm, and the parallax scrolling terrain was a total hot mess.

I could articulate all of it. I just didn’t want to spend days unraveling what the model had created when the next time through the prompt the code was likely to reshuffle (one step forward, two steps back).

ChatGPT started chasing its tail. I’d describe a problem, it would fix it and break something else. We were going in circles.

I set it aside… then later I moved to Claude.

Not because Claude was “better”, but because the project needed a fresh context and a different reasoning style. I ported my intent, not my code. I described what the game was supposed to be, what was wrong, and what “done” looked like. Things that had been circular started converging.

What came out the other end is a real, playable game that I tuned to my satisfaction. I’m the designer, the QA department, and the creative director. The AI was my development team. Two different developers, hired for different phases of the project, managed by someone who understood the product but couldn’t do their job for them.

That’s the skill. Not coding. Not prompt engineering. Knowing what done looks like.

I used my lived knowledge… the kind Google and an LLM don’t have and turned a chatbot into a toolchain.

Many executives I talk to think AI fluency means writing better prompts. No. It means knowing a domain deeply enough to steer the conversation. The model writes the code. You have to know when the output is right even though you can’t read it.

That’s the job now.

---

Give the game a spin here: https://kitchencloset.com/usr/bin/ascii_assault/ and leave me a comment below on what you liked, any bugs you found, etc…