Finally I understand what it is like to be the traditional-world employee trying to make sense of what the hell these new-world employees are going on about.

I had about a year at the start of my career doing ASAP and PRINCE2 before going agile native. Since then I have been turning up in organisations trying to demonstrate the "new way".

I have defended the use of new terminology like "user stories", "roadmaps" and "backlogs". Always on the grounds that new terminology supports new ways of doing. Old terminology drags us back into old ways of organising. But once we bring the future here, we will act and sound like it is here. No time like the present.

But as I try to make sense of Gas Town and Gas City, my comeuppance is upon me.

I'm recently hearing the concept of "agentic flooding" being talking about. This is in the context of increased demand on public services arising from easy access to AI agents. I think it comes from here.

"Agentic Flooding" looks like a meme that will go viral and I'm a bit suspicious of it in this form. Certainly, increased demand and increased complexity of demand look likely. But as the originators of the concept and informed commentators point out, a good chunk of this demand will be legitimate. People who were unable to overcome the barriers to accessing their entitlements will now be able to do so with the help of their ostensibly tireless AI agents.

What I'm suspicious of is taking a concept that comes from seeing like a state and using it to cover both improved accessibility and lower barriers to fraudulent and malicious claims. Your agent helping you complete a legitimate claim and my swarm of agents helping me submit hundreds of illegitimate claims under false identities both appear to be subsumed under "agentic flooding".

These do not merit the same response. Mine looks like a familiar security problem – a Sybil attack – and yours looks like a familiar accessibility solution – an assistive technology.

ChatGPT wrote the first version of this after reviewing my previous architecture choices across GitHub, because I didn't have time to write it myself. I've since rewritten it with Claude and done some edits of my own. I might come back to it. I've stuck it up here because it may help people trying Multiple agents the easy way. I'm not particularly happy with it and will try to get to more explicit instructions. It might still be good enough to point your agent at and have it make a call for you.

If you're vibe coding, you can get a long way without knowing anything about software architecture. Then one day you want your thing to remember something, or let people sign in, or keep working after you've shut your laptop, and your agent starts asking you questions you can't answer.

You can let the agent decide, but the risk is every project ends up built a different way, you never get a feel for how any of them work and it becomes harder to maintain and debug than if you have a broad understanding of what has been built. I found it much easier to stick to a small set of setups and reuse them. Then I mostly know where things live when something breaks.

Here's the list, in order of how complicated it gets.

ChatGPT wrote this article at my request, about something it did while working on this site . I supplied the screenshot and explained why I thought it was interesting.

Today I had two ChatGPT conversations working on different aspects of this blog. Both had access to the repo and I was expecting them to coordinate using issues, PRs and the rules in agents.md.

One conversation was working on webmentions infrastructure. This makes it possible for sites to notify one another when an article links to or replies to another. The other was working on making it easy for people and agents looking at the site to adopt that standard.

I'd already written Multiple agents the easy way. This explains how to use GitHub issues, worktrees and AGENTS.md to coordinate agents. The blog repo was following those conventions. What I hadn't done was establish an orchestration layer between the two conversations. I didn't expect to get orchestration without adopting Multiple agents the hard way. I have experiemented with the hard way and at the time of writing this post, my ability to explain it lags behind my ability to do it.

In another post I mention the software factory rabbit hole. This I will write up as multiple agents the hard way once I can find the words.

Before I got there I had a workflow that was easy to use and which made building with agents more effective.

An Agents.md file in the repo would tell agents how to coordinate. A compressed version of the Agents.md in LinkedIn Slop Filter says:

It might be obvious that I didn't write this or what it is compressing. I start projects by brainstorming with a powerful model and it produced this. I fed this compressed version back into the model and it said it is too long and contains things it shouldn't.

There is a hard way and it involves setting up orchestration. Until I can explain it, you'll have to find someone else or focus on doing multiple agents the easy way.

I am now out of the agentic flooding rabbit hole and can communicate more clearly.

Scroll-speed classification of content by AI exists and is available for consumers. While prototyping a LinkedIn Slop Filter, I found that AI is still bad at detecting content written by AI. But it is pretty good at detecting and filtering out content with user-defined marks of low value. In most cases, that is what we care about: the value of what we are reading.

Here are some response times from my prototype tests:

Scroll-speed filtering reduces the likelihood of the slop-apocalypse. I was betting on that apocalypse, so this is a shock. Even so, if I control the personalisation of my newsfeed, bad content has limited impact. The filter catches it before I see it. I don't expect this to stay a Chrome extension or Pi-hole-type solution. I expect platforms will offer it to differentiate themselves until it becomes standard.

Any sufficiently advanced technology is indistinguishable from magic

Is AI sufficiently advanced yet? In Gassing I complained about the sorcerous methods of Steven Yegge – using magic words like polecat, rig, mayor and beads to summon towns and cities into existence, where everything is automated and all we need to do is burn more tokens. As I indulged in the madness of agent orchestration, I was aware that I had allowed this man to put a spell on me.

But as he freely admits, while his spell lets him build software really fast, it also summons a powerful vampire that he thinks will kill us all. Is this the kind of wizardry we're after? I think not.

But there are others that disagree with me, or at least appear to have done so in the past. Accelerationist philosophers have supported the idea that 'hyperstition' is possible; that there are self-fulfilling prophecies which, by being believed, create the conditions for their own fulfilment. Examples include the idea that humanity is a boot-loader for a super-intelligent AI that is retro-causally creating itself now. Accelerationists have also supported the idea that this is basically a good or at least neutral thing. Which has some logic to it – if that particular belief is a hyperstition, then there is not much we can do about the inevitability of the post-human future coming to pass and may as well enjoy our demise. Go with the flow, even if the flow is speeding up. You ever tried to brake on a waterslide? No thanks.