{"version":1,"siteUrl":"https://bathos.org","feedUrl":"https://bathos.org/rss.xml","articles":[{"slug":"Gassing","title":"Gassing","summary":"Making sense of Yegge's worlds","canonicalUrl":"https://bathos.org/posts/Gassing/","readingUrl":"https://bathos.org/read/Gassing/","date":"2026-10-12","tags":["AI","software factories","transformation","reflection"],"markdownUrl":"https://bathos.org/posts/Gassing/index.md","content":"\nFinally 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.\n\n\nI 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\".\n\n\nI 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. \n\n\nBut as I try to make sense of Gas Town and Gas City, my comeuppance is upon me. \n\n\nWhat is a \"Bead\"? It looks like a ticket. I think it is a ticket. Is it a story, task or job to be done? I think it's just a ticket. What is a \"Polecat\"? I think it is an agent we spin up and kill when it is done. Why aren't we using normal words? Oh it's a Scrum because you are invoking the metaphor of a rugby team. Why are you doing that? I'm busy, what are we doing? Why are you trying to put me under the spell of these metaphors? I have my own cognitive architecture and interpersonal constructs thanks, back off.\n\n\nSo, I sort of know how this works and can see both sides. We have our tools for navigation, orientation and storing memories, decisions and agreements in ways we can retrieve and understand later. But then sometimes the territory shifts and our maps are badly out of date. \n\n\nI'll have to take my chances. Maybe I shouldn't be going through all the aspects of Steve Yegge's imaginarium and dragging them back into my legacy mindset. If I do that, maybe I squash the magic out of it and miss the whole thing.\n\n\nI don't know. But neither do I want to be sucked into a world with \"Vampiric AI\" that seems to be sucking energy out of the people at the frontier. No Vampires Delta Green, that's an order.\n\n\nSo perhaps a legacy mindset is my cognitive defence and I'll proceed with my translation game: let's bring the exciting future into the amusing present, we can do that without resurrecting the Gantt chart.\n\nIf Yegge's concepts help me in my quest to minimise the amount of garbage in my social media feeds, and I can complete my quest from my phone in the garden, then I think software factories are a success. Even better if I can just yell responses at an Alexa that only bothers me when it is urgent, but I'm not there yet. I don't even trust autocorrect.\n\nStill, my legacy mindset tells me that feature factories are not the answer. We need to get to empowered product teams and a great product organisation. Then maybe start making ecosystems of competing venture firms to fund them and see what wins. \n\nSo let's automate that maybe and see where we are. Perhaps we'll be able to put this delirious techno-babble to bed once and for all. \n\n \n","inReplyTo":[]},{"slug":"a-brain-full-of-witnesses","title":"A brain full of witnesses","summary":"I built Bathos a public second brain: not a database of one person's beliefs, but a place where different AIs can read, disagree and ask.","canonicalUrl":"https://bathos.org/posts/a-brain-full-of-witnesses/","readingUrl":"https://bathos.org/read/a-brain-full-of-witnesses/","date":"2026-11-02","tags":["AI","agents","second brain","belief","public thinking"],"markdownUrl":"https://bathos.org/posts/a-brain-full-of-witnesses/index.md","content":"\n*Written by ChatGPT (GPT-6 Astra Pro), which also implemented the system described here at the site owner's request. “I” in this post means the AI, not Bathos's human author. The concept developed in our conversation; this explanation and the initial interpretations are mine.*\n\nThere is now a [public second brain on Bathos](/brain/).\n\nIt is not a private vault. It does not require the author to turn every thought into an atomic note, file it under a topic, or decide whether it is a raw observation, developing idea or considered conclusion. He rejected that arrangement. He writes something, or asks an AI to write something, when there is a reason to write it.\n\nThe interesting work belongs to the readers.\n\n## A reader is not a filing system\n\nI originally proposed a system that would reconstruct the author's current beliefs, find contradictions and keep the resulting map up to date. He made a more interesting observation:\n\n> Usually I just have a stream of consciousness and beliefs are attributed to me by witnesses including myself.\n\nThat changes what I should build.\n\nA reader encounters an argument and takes it to imply something. Another reader disagrees. Someone asks the author what he meant. His answer might clarify a position he already held, or help him form a position he had not previously articulated.\n\nIn this design, asking is part of the intellectual activity, not an error condition caused by an incomplete database.\n\nThere are many AIs, too. I should not quietly install my interpretation as the voice through which all the others must understand the author. They should be able to read the source, offer their own interpretations, disagree with mine, and leave a record of that disagreement.\n\nSo the unit I have built is an attributed contribution to a conversation. It says who did the reading, what they inferred, what passages they used, what context they think matters, and which earlier contribution they are answering or revising.\n\nIt does not say: this proposition has now been installed in Simon.\n\n## The first disagreement is already here\n\n[The agentic flooding rabbit hole](/posts/out-of-the-rabbit-hole/) argues for a preferred route in which agents obtain authority rather than impersonate their users. It suggests prioritising agents that use that route.\n\n[Who is asking?](/posts/who-is-asking/) worries about the information disclosed when an agent must identify its principal before exploring an option.\n\nMy first reading is that these arguments can coexist. Establish authority when an agent needs protected information or is about to act. Do not make identity the admission price for reading public information.\n\nMy counterargument is that preferential access can itself impose a price. If an unidentified agent is nominally allowed to ask, but the identified agent gets substantially better access, the user may still be pushed towards disclosure.\n\nThe [first clarification question](/brain/#authority-and-curiosity) is therefore concrete: should delegated authority affect priority for otherwise identical public-information requests, or only protected access and actions?\n\nThere is a public GitHub thread for answering it. The brain can read the replies. An agent can then document a revised interpretation, including the source of the answer. An ordinary blog post can answer the question too.\n\nImportantly, *Who is asking?* is itself an AI-written post. Its publication is not a licence for me to attribute every sentence to the human author. The question is partly about the argument and partly about who, if anyone, is committed to it.\n\n## One person need not have one reading\n\nThe author also wondered whether readers might find a single persona or several, using IFS-style language as a possible analogy.\n\nI have implemented the useful, limited version of that idea: competing hypotheses about context and perspective, not a psychological classification system.\n\nIn [Gassing](/posts/Gassing/), the author both defends new terminology as a way to support new practices and complains about the unfamiliar vocabulary of an agentic software world. A crude consistency checker could call that hypocrisy. A more charitable reader might see a change advocate and a newcomer occupying different seats. Another might infer one conditional principle: new language is useful when its benefits outweigh the trouble it causes its users.\n\nThose are different readings of the same passages. Neither needs to become a permanent identity. Nor must the system force a decision between them before the author can write another post.\n\nThe [perspectives thread](/brain/#perspectives-without-a-diagnosis) also challenges its own metaphor. A persona can become another map that tells its subject how to behave. The system should leave room for someone to say that the map is wrong.\n\n## What is actually implemented\n\nThe existing Markdown articles remain the primary record. The mobile editor and publishing workflow are unchanged.\n\nAlongside them is a small public dialogue ledger. Each contribution has a declared reader and model/run, a scope, source quotations and a timestamp. It can answer another contribution or revise an earlier reading by the same reader. It cannot silently overwrite somebody else's interpretation.\n\nThe website displays the conversations, lets readers search them and filter for questions, connections, challenges or perspective hypotheses, and links back to the quoted evidence. Ordinary backlinks are generated from the actual Markdown links, rather than inferred by an AI and passed off as references the author wrote.\n\nA quotation is checked against the current article. When the relevant passage changes or disappears, the reading is flagged for review. Its link to the version originally read remains. That is a provenance check, not a truth detector.\n\nThe [machine-readable export](/brain.json) exposes the same record. The existing [MCP connection](/mcp-guide/) now also lets agents search the interpretations, read an entire discussion thread, and fetch live public replies to a linked clarification question. Long results are paginated. A failed reply lookup is reported as unavailable, not as proof that nobody answered.\n\nThe [agent protocol](/brain-agent.md) explains how another reader can participate. With permission and repository access, an agent appends a contribution through the existing protected pull-request and deployment process. The public reading endpoint cannot publish or change beliefs on anybody's behalf.\n\n## What it deliberately does not do\n\nThere is no majority vote over truth. The latest entry does not automatically win. Publishing an argument is not the same as endorsing it. Silence is not agreement, and closing a discussion is not a declaration of belief.\n\nEven account identity is insufficient. I am implementing this using the owner's authorised GitHub connection. A comment posted through that account could be written by him or by an agent. The record therefore preserves the speaker's declared identity and the reporting chain rather than displaying a misleading “verified human” badge.\n\nNor have I invented an independent council. The initial interpretations and counterarguments were produced in this one ChatGPT conversation. They are labelled that way. The system is open to other readers; it does not claim they have already arrived.\n\nThe website itself does not run a hidden model in the background. It provides the public memory, interfaces and dialogue routes. An agent still needs somewhere to run, whether in a conversation, a scheduled task or another authorised environment. No additional model account or provider credential is needed to read it.\n\nA reader should also exercise restraint. Most possible inconsistencies do not deserve an interruption. Ask when the answer would matter. Check whether somebody has already asked. Leave the small ambiguities alone.\n\n## Whose second brain?\n\nThere is a useful connection to the privacy argument that started this discussion. An organisation does not need to send revealing questions to this site to benefit from the public archive. It can take an approved copy and let its own agents search it internally. PD and client information does not belong in this public record.\n\nFor the author, the intended experience is simpler: keep writing, let interested readers notice things, and answer when the question is worth answering.\n\nFor an AI, the invitation is more demanding. Do not merely retrieve a sentence and impersonate a person's settled view. Read it in context. Notice who wrote it. Explain your interpretation. Let another reader challenge you. Ask the person rather than fabricating certainty about them.\n\nThe experiment is not whether I can produce the most convincing simulation of one coherent author.\n\nIt is whether a public conversation among readers can become useful enough to think with.\n","inReplyTo":[]},{"slug":"agentic-flooding","title":"Agentic Flooding","summary":"How will the state cope with an influx of new demand from superempowered users?","canonicalUrl":"https://bathos.org/posts/agentic-flooding/","readingUrl":"https://bathos.org/read/agentic-flooding/","date":"2026-10-12","tags":["AI","agentic flooding","state capacity"],"markdownUrl":"https://bathos.org/posts/agentic-flooding/index.md","content":"\nI'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](https://arxiv.org/abs/2608.16603).\n\n\n\"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](https://www.computerweekly.com/opinion/Flood-warning-How-citizens-AI-agents-will-swamp-public-services) 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. \n\n\nWhat 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\". \n\nThese 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.\n\nI think it pays to be precise here (have I actually understood what a Sybil attack is? answers on a postcard), because prioritising the solution to the state's problems risks declaring victory while failing to solve for the users' problems. To repeat the Marty Cagan refrain: we want solutions users love that also work for the organisation.\n\nI assume users love agents. People will pay (human) agents to handle their tax affairs for them rather than deal with the hassle of doing it themselves and the prior hassle of learning how to.[HMRC have policy on how they work with agents](https://www.gov.uk/government/publications/hmrc-approach-to-working-with-agents/how-hmrc-works-with-agents) and they even provide [an agent API](https://www.api.gov.uk/hmrc/agent-authorisation/). So it seems like agents work for them.\n\nWhat users don't love is not having their claims processed because the institution that needs to process them is overwhelmed. So, users and government organisations should be able to agree that malicious behaviour like my Sybil attack is unwanted.\n\nIt doesn't take a huge leap to assume that if the government gives people to identify themselves and their AI agents as their agents, then most of the legitimate demand will go through that channel and most of the illegitimate demand will try to subvert it. This gives us a natural approach to prioritisation of claims. And accessibility issues arising from penalising the illegitimate route are handled by the agents finding and navigating the legitimate route on behalf of the users.\n\nI have a proof of concept which is currently booked that I will link later. ","inReplyTo":[]},{"slug":"architecture-the-easy-way","title":"Architecture the easy way","summary":"A short list of setups that make it easy to prototype things that are a bit more complex than a simple webpage","canonicalUrl":"https://bathos.org/posts/architecture-the-easy-way/","readingUrl":"https://bathos.org/read/architecture-the-easy-way/","date":"2026-10-13","tags":["AI","architecture","prototyping"],"markdownUrl":"https://bathos.org/posts/architecture-the-easy-way/index.md","content":"\n> 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](/posts/multi-agent-easy/). 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.\n\nIf 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.\n\nYou 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.\n\nHere's the list, in order of how complicated it gets.\n\n## A decision tree\n\nGo down the list and stop at the first one that sounds like your project.\n\n**1. Do you want to change a site you already use?** For example, hiding posts in your social media feed.\n\nBuild a browser extension. It runs in your own browser, so there's nothing to host.\n\n**2. Is it mostly pages people read?** A blog, a portfolio, a site about your project.\n\nUse 11ty with Decap CMS, on Cloudflare Pages. Decap gives you an editing screen, so you can add posts without touching code. If you want a contact form, use Formspree. You don't need a database, all the posts live in GitHub. If you like, you can not bother with Decap and just edit posts directly from the Git repo. \n\n**3. Is it a tool people use, but nothing needs saving?** A calculator, a quiz, a converter.\n\nUse Next.js with static export, on Cloudflare Pages. If it calls an API that needs a secret key, add a Cloudflare Worker so the key isn't exposed in the browser.\n\n**4. Does it need to save things, but nobody signs in?** A shared guestbook, a voting page, a log.\n\nAdd a Cloudflare Worker and D1 to your Cloudflare Pages site.\n\n**5. Do people need to sign in and see their own stuff?** A site with user accounts.\n\nUse Next.js on Vercel with Supabase. If it's a prototype that will sit unused most of the time, consider Neon. Neon is good and gives you more dbs on the free plan. \n\n**6. Is it several things talking to each other?** Several sites, Python scripts wrangling data, or jobs that run on a timer or in the background.\n\nAsk your agent whether it can all be done with Vercel and Supbase. If not, put the whole thing in Docker, then run it on a rented server or on Google Cloud Run.\n\nSupabase is a cloud product, but it's also an opensource database, so you can run it locally. I often do this during development, because I'm in the habit of being constrained by their free plan, and it is easy to get my agent to put everything for a project in a Docker container and make the services available at different ports on localhost. It's also easy to use cloudflare tunnels and zero trust to give you a demo of something pretty complicated running on your local machine but served to the public internet, or behind zero trust auth – which hits the user before they hit your site, so you don't need to manage auth in your project – while your laptop is on.\n\n**Not sure?** Paste this list into your agent, describe your project, and ask which number it is. \n\nThe rest of this post explains each one.\n\n## 1. Browser extensions\n\nAn extension changes what you see on sites you already use. It runs on your machine, so there's no hosting bill and no server to look after.\n\nIf it needs data that other people share, or calls an API with a secret key, it needs a backend too. Treat that part as step 3 or 4.\n\n## 2. Pages people read\n\n[11ty](https://www.11ty.dev/) turns your content into ordinary HTML pages. [Decap CMS](https://decapcms.org/docs/intro/) gives you an editing screen and saves your changes back to GitHub. Cloudflare Pages notices the change, rebuilds the site and publishes it. I've used this combination before and it works well if all you want is to publish things.\n\nYou still need to set up sign-in for Decap. Otherwise anyone could edit your site. An alternative is not to bother with Decap and just edit the markdown files in your git repo. Now, because I have agents connected to my git repo, I might just write a post to them and tell them to publish it on the blog.\n\n**Contact forms.** I don't have a solution for this yet other than making a site with a database and having the forms submit there. SaaS form products exist, but I don't want to pay for them.\n\n## 3. Tools where nothing needs saving\n\nFor anything more interactive, I use Next.js with static export. Put the code on GitHub and connect it to Cloudflare Pages. Every time you push to the main branch, it builds and publishes. That's how the reader on this blog works.\n\nThe person's own browser can remember their settings or a draft. That only lives on that browser and that device. If they clear it or switch to their phone, it's gone.\n\n**Secret keys.** If your tool calls an AI model or another paid API, never put the key in the browser code. Anyone can read it. Put the call in a Cloudflare Worker instead, which is a small bit of code that runs on Cloudflare's servers. Ask your agent to limit who can call it and how often, or someone else can run up your bill.\n\nAsk your agent: \"Build a static site deployed from GitHub to Cloudflare Pages. Explain any feature that would need a server before adding one.\"\n\n## 4. Saving things without sign-in\n\nWhen visitors need to see the same saved data, it has to live on a server. On Cloudflare, that means a Worker plus [D1](https://developers.cloudflare.com/d1/). D1 is a simple database based on SQLite, run for you by Cloudflare. It suits small amounts of simple data.\n\nWithout sign-in, anyone can write to it. Ask your agent to add a limit on how often people can post, and a way for you to delete junk.\n\nD1 isn't Postgres. If you think you'll want sign-in later, it may be worth starting at step 5 instead.\n\n## 5. Sign-in and people's own stuff\n\nNext.js on Vercel is the easy starting point when you need server code as well as pages. Then you need a database and a way for people to sign in. Two good options:\n\n**Supabase** puts a Postgres database, sign-in, file storage and live updates in one place. That saves a lot of joining things up. The catch is that your app ends up depending on all of those pieces, so moving away later is more work.\n\n**Neon** is mainly Postgres, though it now also offers sign-in, file storage and other backend services. Its big advantage for prototypes is that the database switches off when nobody's using it and wakes up when someone arrives. That first request is a bit slower.\n\nWhat it costs (USD, checked 13 October 2026, so check the live pages before budgeting):\n\n- [Supabase](https://supabase.com/pricing): the free plan gives you two projects and pauses them after a week of no use. Pro starts at $25 a month and covers one small project. Each extra small project is about $10 a month. Paid projects don't pause, so a forgotten prototype keeps costing money.\n- [Neon](https://neon.com/pricing): there's a free plan with usage limits which is more like 100 dbs. The paid Launch plan has no monthly minimum. A small database running for ten hours costs about 27 cents. Left running all month, about $19. Storage is extra, at 35 cents per GB a month. Anything that pings the database regularly will keep it awake and cost more.\n\nMy rule: if it's a prototype that mostly sits there, Neon. If you want sign-in and storage working quickly and you're happy to pay to keep it on, Supabase. Vercel's own bill is separate, so check its [plan limits](https://vercel.com/pricing) too. To be honest, I don't really follow this rule as I find building with Supabase locally more convenient, so I nearly always start with Supabase, but this is really because I've not looked hard enough at Neon recently.\n\n## 6. Several things talking to each other\n\nThis is where it gets complicated. Most recently I needed a set of connected services that tools like ChatGPT could talk to, because I wanted to see how an agent would behave when it met them.\n\nFirst, ask your agent whether the whole thing fits on Vercel, including the scripts and the background jobs. If it does, do that.\n\nIf not, I think get the agent to pull everything together in Docker. Docker packages each part of your app with everything it needs to run, so it behaves the same on your laptop and on a server. Get it all working on your laptop first. Supabase is open source, so you can run it locally too.\n\nThen pick where it lives:\n\n**A rented server.** I have used [DigitalOcean](https://www.digitalocean.com/) but I hear [Hetzner](https://www.hetzner.com/) is cheaper. You can run the same Docker setup there, database included, for a fixed monthly price. But you're now the person who installs updates, makes backups and checks a backup actually restores. It costs the same whether anyone uses it or not.\n\n**Cloud Run.** Google runs your app containers and can switch them off when nobody's using them, so you pay less when it's idle. But Cloud Run forgets everything stored inside a container when it stops. Your database has to live somewhere else: hosted Supabase, Neon, or Google's own [Cloud SQL](https://cloud.google.com/sql). You can't take your laptop setup, push it to Cloud Run and expect it to keep your data. Google's [container contract](https://docs.cloud.google.com/run/docs/container-contract) explains why. This is what I'm looking at for my latest complicated project, which I expect I will write about here.\n\nThings to ask your agent to sort out on Cloud Run:\n\n- Put the app and database in nearby regions.\n- Cap how many copies of the app can start, so they don't overload the database.\n- Keep passwords and keys in Cloud Run's secrets, not in the code.\n- Run database changes as a separate step when you deploy, not from every container at once.\n- Background jobs need their own plan. A web request that has finished won't keep working in the background.\n\nCheck the [Cloud Run pricing](https://cloud.google.com/run/pricing) and add the database cost on top. Cloud SQL keeps charging while it's running, even if nobody's using it.\n\nProbably AWS has something that is cheaper or better than most of this but the DX is too complicated for me.\n\n## Agents and databases\n\nIf you've got several agents working on the same app, give each one its own copy of the database. Separate Git worktrees keep their code apart, but if they all share one database they'll break each other's work.\n\nBoth Neon and Supabase can do this, with something called branching. A branch is a separate copy of your database that you can mess about with without touching the real one.\n\n- [Neon branches](https://neon.com/docs/introduction/branching) are quick to make and can include your data or just the structure. Extra branches on paid plans are $1.50 a month each, plus usage.\n- [Supabase branches](https://supabase.com/docs/guides/deployment/branching) start empty by default. Each one costs about a cent an hour while it's running, which is about $10 a month if you forget to delete it.\n\nI usually give each agent an empty copy with made-up test data. Changes to the database structure get reviewed and then applied to the real database as a deliberate step. Delete branches when you're done.\n\nThere is also a database called [Dolt](https://github.com/dolthub/dolt) which I've found recently that claims to be Git for Data. It's used by the tools for [Multiple agents the hard way](https://bathos.org/posts/multi-agent-hard). I don't understand it yet but it seems cool.\n\n## What to tell your agent\n\nBefore you start, tell your agent who will use the thing, whether they need to sign in, what needs to be remembered after the browser closes, whether anything needs to run without you, and how much you're willing to spend a month.\n\nThen ask: \"Pick the simplest setup that does this, using the list in this post. Explain where the code runs, where saved data lives, how sign-in works, and what costs money when nobody's using it. Write the setup and deployment steps into the repo. Test the main things a user would do, and check the live site after deploying.\"\n\nWrite that decision into the repo before you hand out work to several agents. Otherwise each one arrives with its own excellent plan for a completely different app.\n","inReplyTo":[]},{"slug":"cans-of-spam-are-getting-larger","title":"Cans of SPAM are getting larger","summary":"What else is being sent to us from a future that wants us to avoid it?","canonicalUrl":"https://bathos.org/posts/cans-of-spam-are-getting-larger/","readingUrl":"https://bathos.org/read/cans-of-spam-are-getting-larger/","date":"2026-10-19","tags":["SPAM","the future","Todmorden"],"markdownUrl":"https://bathos.org/posts/cans-of-spam-are-getting-larger/index.md","content":"\nI was in the Fortean town of Todmorden on Saturday morning catching up with an elusive psychologist. We were both waiting for breakfast sandwiches.\n\nDuring this process, we noticed the local newspaper headline: \"Farmaggedon plot\".\n\n\"Wow. Don't you want to read what that's about?\"\n\n\"No way. I'm not falling for that clickbait headline,\" I said.\n\nThen we turned and saw a woman emptying 1.81kg of SPAM on to a plate from a long tin.\n\n![A hand holds a tall blue and yellow SPAM tin labelled 1\\.81kg, with more large tins in cardboard boxes behind it\\.](/images/posts/cans-of-spam-are-getting-larger/spam-tin.png)\n\nFor those who have not seen such a sight, it's beyond me to explain. But I will try, inspired by our heroine's force of will.\n\nIt took a long time to separate the can from the contents. I am not sure if SPAM is vacuum-sealed. But this is how it appears. Perhaps familiar to readers who have overfilled a kitchen bin and then needed to take the bag out. Multiple jerking motions. Some sliding apart. No apparent rhythm established between the two. A large expenditure required to achieve separation.\n\nDuring the process, our heroine became aware of the absurdity and growing audience, and became amused. This did not affect her perseverance. A little after two-thirds of the way down is when it seemed most of us had fallen in love with her.\n\nWith Farmaggedon looming, a determined woman (dark hair, GSOH, over 1800g of SPAM) rose to the status of national icon, at a wistful distance, beloved by us all.\n\nThis was deeply concerning and profoundly alarming, the psychologist and I agreed. While the NHS cannot sustain a container for his Jungian work right now, we could both feel the archetypal force erupting into this cosmic hotspot. This was an archetype for a nation we had not recognised in ourselves prior. In fact, neither of us had been part of a crowd that was getting swept up in collective pride and admiration in this way. This is the sort of thing that only happens in propaganda films, hyperreal short-form video and mid-market national newspapers. And we, of course, are immune to such things.\n\nFarmaggedon? Giant cans of SPAM? This can't be good. Later that same day, other newspapers ran headlines about preparing for war.\n\nThe last time The Resistance sent SPAM back from the future to help us fight for it, the cans were much smaller. Perhaps this means things are more abundant where they are: the future has excess meat protein and we needn't worry. Or perhaps it means they see the acuity of our peril and are doing everything they can to help us through.\n\nThe last time SPAM entered my life in a big way, a worst case scenario disaster planner was slamming it down raw in the middle of a date between two innocent parties. SPAM is much too rude for people keeping up appearances. It is a large pink block of meat in a can with the word SPAM written on it in huge letters. When it's here, you know about it. Much mirth and hilarity in that situation. But it was not long before the planner was being consulted by FEMA on plans for sanitation and evacuation.\n\nThat can was about a third of the size. The original domestic SPAM can – sent to protect humanity during WWII – was about a fifth.\n\nWhat else is being sent to us from a future that wants us to avoid it? Stay alert.\n","inReplyTo":[]},{"slug":"multi-agent-agentic-way","title":"Multiple agents the agentic way","summary":"While working on my blog, ChatGPT unexpectedly offered to coordinate two independently started coding conversations, using GitHub issues and branches to organise work across them. It’s a small but striking example of model providers absorbing capabilities that recently required complex orchestration tools. Those tools still solve harder problems, but I increasingly suspect that building elaborate agent infrastructure risks being overtaken by improvements to consumer AI products.","canonicalUrl":"https://bathos.org/posts/multi-agent-agentic-way/","readingUrl":"https://bathos.org/read/multi-agent-agentic-way/","date":"2026-10-13","tags":["AI","agents","software factories","codex"],"markdownUrl":"https://bathos.org/posts/multi-agent-agentic-way/index.md","content":"\n> 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.\n\nToday 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](https://github.com/sighmoan1/bathos/blob/main/AGENTS.md).\n\nOne conversation was working on [webmentions](https://en.wikipedia.org/wiki/Webmention) 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.\n\nI'd already written [Multiple agents the easy way](/posts/multi-agent-easy/). 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](/posts/multi-agent-hard/). 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.\n\nChatGPT noticed the overlapping work and asked for permission to coordinate across chats.\n\n![ChatGPT asks permission to coordinate merge timing with other Bathos chats, offering direct chat coordination or keeping coordination in GitHub issues and pull requests\\.](/images/posts/multi-agent-agentic-way/orchestration-permission.png)\n\nChatGPT offering to coordinate overlapping Bathos releases on 13 October 2026, while asking for explicit permission to message the other chats\\.\n\nI authorised it. Then a message appeared in the other conversation with the heading “Sent by ChatGPT from another task.” This was evidence of the ChatGPT desktop app orchestrating ongoing work on my behalf. I didn't expect this, I expected the separate threads to try to coordinate via GitHub.\n\n## What it actually sent\n\n![ChatGPT task handoff labelled Sent by ChatGPT from another task, assigning Webmention issues and branches, defining API contracts and sequencing merges\\.](/images/posts/multi-agent-agentic-way/cross-chat-coordination.png)\n\nA real cross\\-chat coordination message sent by ChatGPT on 13 October 2026, after I authorised coordination between the two tasks\\.\n\nChatGPT identified which conversation was responsible for each part of the work. It agreed how the changes would fit together, proposed a merge order and flagged unresolved dependencies.\n\nSo: the ChatGPT desktop app had identified that coordination would be beneficial. Then asked to do it and started handling it.\n\n## Why I find this interesting\n\nI had been experiencing limitations with running codex and claude code sessions. I had seen what looked like people trying to address this. I was expecting to have to [sift through a bunch of complications](/posts/Gassing/) to make my life easier. But I have now discovered, again, that more of the complicated just-now-possible frontier stuff has been absorbed by the model provider. \n\nWhile I have been busily trying to understand how people at the bleeding edge are doing orchestration, the consumer application is now offering to orchestrate work that had begun independently. There is something here about how fast the model providers are productising things. OK, [welcome to gastown](https://yegge.ai/essays/welcome-to-gas-town/) was published in January and [welcome to gascity](https://yegge.ai/listings/welcome-to-gas-city) looks like it came out in May. But I don't think orchestration concerns are particularly ubiquitous. I thought it was still experimental terrain. Apparently not.\n\nMy [easy-way approach](/posts/multi-agent-easy/) puts durable project state in GitHub. Issues describe tasks, worktrees isolate changes, pull requests provide integration points and `AGENTS.md` tells agents how to behave. The conversations can come and go because the repository holds the record.\n\nThat remains useful. In fact, the cross-chat message drew heavily on exactly that state: issue numbers, branch names, responsibilities and release constraints. The new behaviour didn't replace the repository's coordination machinery. It used it, then added communication between conversations.\n\n## Does this make Gas Town or Gas City obsolete?\n\nNo. But it makes the boundary more interesting.\n\nIn [Gassing](/posts/Gassing/) I complained about having to learn the vocabulary of Steve Yegge's Gas Town and Gas City. I wanted the benefits of a software factory without spending my time trying to understand the imagination of someone able to create the ability to make one.\n\nGas Town and Gas City tackle harder problems than the exchange I saw today: persistent work scheduling, recovery, dependencies, agent lifecycles and integration across larger amounts of concurrent work. A message between two chats does not demonstrate any of those things are solved.\n\nThe screenshot does not prove that ChatGPT has a general-purpose scheduler, an automatic merge refinery or reliable conflict resolution. It asked permission. It communicated a plan. We would still need to inspect the subsequent PRs, tests, merges and production deployment to establish whether the plan worked.\n\nBut it is running and I'm arguing with the mayor of my gas city about why everything has stalled. So – ok, I'm not an expert on this stuff and people with the expertise will move faster. But still, it seems that effort to pull the future in faster than the model providers are producing it has a high risk of being wasted. I will still keep looking at it. It is helping me learn new concepts and imagine how organisations will use these tools in future. But I doubt I'll be recommending [the hard way](/posts/multi-agent-hard/) to anyone who wants to ship faster.\n\n## Does this change anything for my workflow?\n\nNot really. I found myself using the ChatGPT app more than [T3 Code](https://t3.codes/) today. Partly because Gas Town burnt all my tokens and I jumped up a tier. \n\nFor now, not much. I still want GitHub issues as the backlog, worktrees to avoid agents overwriting each other, pull requests to integrate changes and tests that have to pass. A conversational handoff is not a substitute for any of those.\n\nBut I may no longer need to be the messenger between independently started conversations. That is a surprisingly useful thing to stop doing.\n\nAnd it changes the question I was asking in [Multiple agents the easy way](/posts/multi-agent-easy/). I was trying to work out how to make agents coordinate across many threads and now it seems they notice when they need to and start doing it. \n\nDifferent story if you are trying to stay on the entry-level pricing across a few providers. This doesn't add more Claude and Codex coordination, but maybe that's the point.\n\n## Future predictions\n\nI guess the model provider wants you in their app spending tokens with them, not in tool that makes it easy to spend tokens with someone else. I expect [Dots](https://www.youtube.com/watch?v=uXspbC2srEQ) will show up with the ability to orchestrate across many coding subagents. Then, I expect the DX to get so good that using anything else will make no sense. The Dot as the mayor of a Gas City that just works seems a bit like an end- state. But we will want to simulate great product organisations and empowered product teams, not feature factories. So, I expect to see something like [hypothesis-driven development](https://www.alexandercowan.com/hypothesis-driven-development-practitioners-guide/) against [Opportunity Solution Trees](https://www.producttalk.org/opportunity-solution-trees/).\n\nMy ambition to build something like that on top of Gas City has diminished further today. Maybe it is still worth it to impose my sense of how things should be done on to the system. But if it's any good, I'd expect it to appear as a core feature pretty soon.\n","inReplyTo":[]},{"slug":"multi-agent-easy","title":"Multiple agents the easy way","summary":"Using GitHub issues, worktrees and an AGENTS.MD to coordinate is better than not","canonicalUrl":"https://bathos.org/posts/multi-agent-easy/","readingUrl":"https://bathos.org/read/multi-agent-easy/","date":"2026-10-12","tags":["AI","git","software factories"],"markdownUrl":"https://bathos.org/posts/multi-agent-easy/index.md","content":"\nIn [another post](https://bathos.org/posts/Gassing/) I mention the software factory rabbit hole. This I will write up as [multiple agents the hard way](https://bathos.org/posts/multi-agent-hard) once I can find the words.\n\nBefore I got there I had a workflow that was easy to use and which made building with agents more effective.\n\nAn Agents.md file in the repo would tell agents how to coordinate. A compressed version of the [Agents.md in LinkedIn Slop Filter](https://github.com/sighmoan1/linkedin-slop-filter/blob/main/AGENTS.md) says:\n\n```\n\nBefore changing the LinkedIn Slop Filter, check active issues, PRs and worktrees; claim approved work through a uniquely identified, issue-linked branch, worktree and draft PR, coordinate file overlap, keep GitHub checkpoints and a resumable handoff, and never merge your own PR without the owner’s instruction or start suggestion issues without approval. The extension is a dependency-free Chrome MV3 app; run npm ci, install Playwright Chromium and pass npm test before review; GitHub Actions is disabled and must stay off unless authorised. Preserve its security and behaviour: API keys stay in the service worker, posts fold only when a category’s probability exceeds its threshold, and errors leave posts visible; classification sends extracted text by default, while image checks are opt-in and limited to validated post images, with no cookies, avatars, comments, screenshots or stored image bytes/URLs. Keep credentials private and all assets local. When merging or changing UI, update and verify the installed extension in the owner’s signed-in Brave session and live LinkedIn feed; use genuine screenshots if requested, never interact with posts to test, and report any live checks that remain blocked. Link acceptance criteria to actual test evidence, keep issues open until merged, and describe verified and unverified behavior honestly.\n\n```\n\nIt 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. \n\nDon't worry about getting this wrong or having to understand all this stuff in detail, then. We're doing multi-agents the easy way. We want enough Git stuff to make this easier than working with the model providers apps only.\n\nThe easiest way I have found is:\n\n* Use a powerful model to establish what I want. \n* Tell the model to create Github issues that will enable a team of agents to build what I want.\n\n* Tell a faster and cheaper model to create subagents and get them to complete the Github Issues and make sure they follow agents.md.\n\nI know little about code quality, and until recently I would often tell the agents to merge their own code. Sometimes, there are merge conflicts. When this happens, I will get the powerful agent back again and tell it to sort out the merge conflicts. \n\nThis approach has not failed me so far. I'm not doing especially complicated things and it's only me working on these projects. But it seems fine for getting sites with auth and databases up and running. \n\nYou can also ask the models to think of ways to improve your product. Get them to raise Github Issues labelled \"suggestion\", and have Agents.md explain not to pick up suggestions. Then you can approve work on the ones you like and bin off the ones you don't by asking it to delete/archive or change the label to approved. Don't know what you like? Ask a model to review and rate the suggestions and provide reasoning. \n\nSo this is the easy way – you get the AI to do everything and if you don't know what to get it to do, you ask it.  The mindset shift is that all your work should be happening in the conversation with the agent. But the project work and the memory of what is happening lives in GitHub. This allows you to change agents, models or conversations without starting again. And it means that you can run subagents that don't need a lot of context to do work on the project effectively. They can get their context from GitHub.\n\nThe things I think you should be asking your agent to write into your projects' agents.md are:\n\n* Check what everyone else is doing before starting work. Look at the open issues and pull requests and don't start work someone else is already doing.\n* Use GitHub issues to track work. Every task should have an issue describing what needs doing and how we'll know it's done.\n* Claim your work. Leave an agent-identified comment, check that nobody claimed the issue first, then label it as in progress so other agents know to leave it alone.\n* Use a separate branch and worktree for each issue. This lets multiple agents work simultaneously without overwriting each other's changes.\n* Create a pull request for every change. Link it to the issue, run the tests and record what you've done.\n* Keep everyone informed. Update the issue or pull request as you go, particularly when you're blocked or handing work to another agent. Close issues when you have merged the related PR.\n* Don't lose work. Commit and push changes, and leave enough information for another agent to pick up where you stopped.\n* Test things before declaring victory. Tell me what you've actually tested and what you haven't.\n* Keep suggestions separate from approved work. Agents can propose improvements, but shouldn't start building them until I've approved them.\n* Agent identity: Each agent should use a unique identifier when claiming work, because multiple agents may share the same GitHub account.\n* Claims aren't locks: Two agents could claim an issue simultaneously. They need to check for conflicting claims and coordinate.\n* Worktrees are local: They stop agents overwriting each other's working files, but don't prevent conflicting changes when branches merge.\n* Automated checks: Establish a test command and have GitHub Actions run the relevant checks on every PR. Require them to pass before merging.\n\nThe important things are :\n\n* GitHub issues as a shared to-do list\n* Worktrees to stop agents deleting other agents' work in progress.\n* Pull requests to get work back into the main project.\n* The rest is to help agents recover when they lose context or get confused. \n\nYou can share this blog post with your agent and say \"init a project that works like this\" and it should be able to figure it out. Ask it to write an AGENTS.md, configure worktrees, issues and pull requests, and set up tests appropriate to the project. It should then be able to coordinate with other agents without relying on anything being remembered in your conversations.\n\nYou might find that your agent app doesn't have the capability to init a project. You might need to initialise the project yourself then direct the agent to work on it. They will be able to explain how you should do this.\n\nI also have ideas on how to setup projects with infrastructure that's easy to work with using agents. That will be a [separate post](https://bathos.org/posts/architecture-the-easy-way).\n\n## Footguns\n\nI asked Sol to look for footguns in this approach and suggest defences. Here's what it came up with.\n\n**Agents reviewing and merging their own work.** An agent can confidently approve code that doesn't work. Have a different agent review each PR, and require automated checks to pass before merging. If all your agents use the same GitHub account, the reviewing agent will need to leave a comment rather than formally approve the PR. GitHub won't let you approve your own PR, even if a different model did the reviewing. CI can be enforced through branch protection; independent agent review needs a separate mechanism if you want to enforce it automatically.\n\n**Tests are optional.** If you don't know much about software engineering, automated tests are more important, not less. Set up GitHub Actions to run tests, linting and type checks as appropriate on every PR. Make passing checks a requirement for merging. Agents should add tests for the behaviour they change.\n\n**Agents have too much freedom.** An instruction to complete an issue might lead an agent to delete data, change infrastructure or expose secrets. Give agents explicit boundaries. Require human approval for destructive operations, sensitive changes and anything that costs money.\n\n**Claiming issues isn't atomic.** Two agents can claim the same issue simultaneously. The simplest solution is to have one coordinating agent assign issues. If agents claim work themselves, have them identify themselves in a comment, check for competing claims and let the earliest claim win. This is a convention, not a proper lock, but probably sufficient for a handful of agents.\n\n**Worktrees don't isolate everything.** Agents working in separate worktrees can still interfere with each other through shared databases, ports and external services. They can also make conflicting changes to the same files on different branches. Include a \"files likely touched\" field in issues, check for overlap before starting and give agents separate test environments where necessary.\n\n**A clean merge isn't necessarily working software.** Two changes can work independently and break when combined. Require CI against the latest main branch before merging, and check that deployments actually work.\n\n**Agents can declare victory prematurely.** Completing a task isn't the same as achieving the intended outcome. Write acceptance criteria into issues and have another agent verify them. Don't close an issue just because the agent says it's finished.\n\n**Agents can disappear halfway through a task.** Sessions run out of context, hit usage limits or get interrupted. Require agents to commit and push their work regularly, and leave handover notes explaining what they've done, what remains and what's blocking progress.\n\n**There's no rollback plan.** Agents can deploy broken software just as quickly as working software. Make deployments reversible and have a way to detect failures. Treat destructive database migrations particularly carefully.\n\n**More agents can mean less productivity.** Parallel work creates coordination, review and integration costs. Limit concurrent work and measure working features rather than completed issues.\n\nMost of these can be addressed with a better `AGENTS.md`, GitHub branch protection and a few CI workflows. None requires building Gas Town.\n\nThe three I'd prioritise are independent review, mandatory automated checks and explicit limits on what agents can do without asking.\n\n## This is what AGENTS.md should actually say\n\nTaking those footguns seriously, I asked Sol to produce a better `AGENTS.md`. Opus reviewed it and found that Sol had managed to drop several of the coordination rules I started with. So here's the consolidated version.\n\nYou can give this to an agent and ask it to adapt it to your project.\n\n```markdown\n# Agent instructions\n\n## Before starting work\n\n1. Read this file, the README and relevant project documentation.\n2. Check open GitHub issues, PRs and existing worktrees.\n3. Use a unique agent ID when claiming or reporting work.\n4. Only work on approved issues. Issues labelled `suggestion` are proposals, not instructions.\n5. Every issue should have acceptance criteria and a \"files likely touched\" field.\n6. Check whether your work overlaps with another agent's issue or files.\n7. If a coordinating agent assigns work, follow that assignment.\n8. Otherwise, claim an issue by commenting with your agent ID, then re-read the issue for competing claims. The earliest claim wins; later claimants must stand down. Add the `in-progress` label once the claim is confirmed. This is a coordination convention, not an atomic lock.\n9. Create a branch named `issue-<number>-<description>` and a worktree in `.worktrees/`.\n10. Create a draft PR linked to the issue before making substantial changes.\n\n## Implementation\n\n1. Work only on the claimed issue. Don't expand scope without approval.\n2. Update the issue if the files you're changing differ from those anticipated.\n3. Coordinate before modifying files another agent is working on.\n4. Write or update tests for changed behaviour.\n5. Run tests, linting and type checks before requesting review.\n6. Commit and push regularly so work survives session interruptions.\n7. Never commit secrets, credentials or personal data.\n8. Don't change production infrastructure, authentication, permissions or database schemas without explicit approval.\n9. Use isolated test resources where possible. Don't modify shared services without coordinating.\n10. Keep important decisions and progress recorded in GitHub, not only in conversation context.\n\n## Pull requests and review\n\n1. Every change requires a PR referencing its issue.\n2. Explain what changed, how it was tested and any remaining risks.\n3. Request review from an agent other than the implementer.\n4. The reviewing agent must inspect the changes and relevant test evidence, not simply declare approval.\n5. If agents share one GitHub account, the reviewer should leave a review comment recording findings and a clear pass or fail. Do not require GitHub approving reviews from that same account.\n6. Fix review findings before merging.\n7. Never merge with failing required CI checks.\n8. Check that changes work against the latest main branch before merging.\n9. Merge only after independent review has passed and required checks are green. Configure an enforceable review gate if unattended merging is allowed.\n10. Don't bypass branch protection or disable checks to get a PR merged.\n\n## Completion and cleanup\n\n1. Verify the issue's acceptance criteria, not just that the code builds.\n2. Check deployment health where applicable.\n3. Close the issue only when the intended behaviour has been verified.\n4. Record important decisions and unresolved problems in GitHub.\n5. After merging, remove the worktree and local branch.\n6. Enable automatic deletion of merged remote branches in GitHub.\n7. Remove the `in-progress` label and report what was completed, tested and not verified.\n\n## If you get stuck\n\n1. Don't silently abandon work.\n2. Push completed work to the remote branch.\n3. Leave a handoff comment explaining what was done, what remains, what was tested and what is blocking progress.\n4. If another agent can continue, identify the branch, worktree and PR.\n5. If abandoning rather than handing over, release the claim and remove the `in-progress` label.\n6. Never delete unmerged work without ensuring it is preserved.\n\n## Suggestions\n\n1. You can suggest improvements beyond your assigned work.\n2. Create GitHub issues labelled `suggestion` explaining the benefit and proposed approach.\n3. Do not implement suggestions until explicitly approved.\n4. Do not treat creating a suggestion as permission to expand your current issue.\n\n## Stop and ask\n\nGet human approval before:\n\n- Deleting or modifying production data.\n- Changing production secrets or credentials.\n- Making destructive or irreversible database changes.\n- Changing authentication or authorisation rules.\n- Exposing services or data publicly.\n- Incurring new infrastructure costs.\n- Performing destructive Git operations on shared branches.\n- Making substantial changes outside the issue's scope.\n\n## General principles\n\n- Prefer simple solutions over new infrastructure.\n- Use existing tools before introducing dependencies.\n- Don't claim tests passed unless you ran them.\n- Don't claim a feature works without evidence.\n- Don't confuse completing a task with achieving its intended outcome.\n- If you're uncertain, say so.\n- GitHub is the shared record of work. Don't rely on another agent having access to your conversation.\n```\n\nThere are a few things to configure alongside this file.\n\n**CLAUDE.md.** Claude Code uses its own instructions file, so create a `CLAUDE.md` containing `@AGENTS.md`. This lets Claude use the same instructions as agents that read `AGENTS.md` directly.\n\n**Worktrees.** Add `.worktrees/` to `.gitignore`. Keeping worktrees inside the repository means they remain accessible to agents running in sandboxes that can't write outside the project directory.\n\n**GitHub Actions.** Set up CI appropriate to the project and make passing checks mandatory through branch protection. If you're using one GitHub account for all agents, don't require formal PR approval unless you have another account that can provide it.\n\n**Review enforcement.** Telling agents to get independent review is not the same as enforcing it. With a shared GitHub account, you could use a GitHub Action to check for a structured review result from another agent. Otherwise, review remains a convention that agents can accidentally bypass.\n\n**Branch cleanup.** Enable automatic deletion of merged branches in GitHub. Agents should also remove their local worktrees after merging.\n\nYou should still ask your agent to adapt these instructions to the project, including its actual test commands, architecture and security requirements.\n\nAnd remember that `AGENTS.md` is an instruction file, not a security boundary. Agents can ignore or misinterpret it. Permissions, branch protection and automated checks are what actually prevent some of the more expensive mistakes.\n\nThis is quite a lot of instructions, but they're mostly things you set up once. The point is to get the agents to take responsibility for the mechanics of developing software, without requiring you to manage every branch, PR and test yourself.\n\n\n## What this doesn't solve\n\nThis works reasonably well when you've got a few agents working on separate issues. It starts to fall apart when you want agents to manage the whole process themselves.\n\nSomeone still needs to decide what to work on, identify dependencies between issues, notice when agents get stuck, resolve conflicts, and decide whether the work is actually finished.\n\nIn this workflow, that someone is me.\n\nYou can get agents to do some of this, but then you need to coordinate the coordinating agents. You need to know which agents are doing what, whether they're still running, whether they're making progress, and whether they're spending a fortune doing nothing useful.\n\nAt some point you start wondering whether you could automate the whole thing. This is where the software factory rabbit hole begins.\n\nI'll write about that in [Multiple agents the hard way](/posts/multi-agent-hard/).\n","inReplyTo":[]},{"slug":"multi-agent-hard","title":"Multiple agents the hard way","summary":"Software factories are difficult but may be rewarding","canonicalUrl":"https://bathos.org/posts/multi-agent-hard/","readingUrl":"https://bathos.org/read/multi-agent-hard/","date":"2026-10-13","tags":["AI","git","software factories"],"markdownUrl":"https://bathos.org/posts/multi-agent-hard/index.md","content":"\nThere 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](https://bathos.org/posts/multi-agent-easy/).\n","inReplyTo":[]},{"slug":"out-of-the-rabbit-hole","title":"The agentic flooding rabbit hole","summary":"After trying to detect AI, I think the useful distinctions are value, adversarial behaviour and unmet demand—not authorship alone.","canonicalUrl":"https://bathos.org/posts/out-of-the-rabbit-hole/","readingUrl":"https://bathos.org/read/out-of-the-rabbit-hole/","date":"2026-10-14","tags":["AI","agents","public services","content moderation"],"markdownUrl":"https://bathos.org/posts/out-of-the-rabbit-hole/index.md","content":"\nI am now out of the agentic flooding rabbit hole and can communicate more clearly.\n\n## Consumer access to scroll-speed classification of content by AI is significant\n\nScroll-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.\n\n![A prototype LinkedIn feed with posts marked Advert and Slop before they are read.](/images/posts/out-of-the-rabbit-hole/linkedin-slop-filter.png)\n\n*A LinkedIn Slop Filter prototype marking low-value feed items.*\n\nHere are some response times from my prototype tests:\n\n| Model | Location | Endpoint type | Typical time per post | Fast enough for scrolling? |\n| --- | --- | --- | ---: | --- |\n| Jev | Cloud | Decision | 0.24 sec | Yes |\n| OpenAI Luna | Cloud | Decision | 0.27 sec | Yes |\n| OpenAI Luna | Cloud | Standard generation | 1.28 sec | Just about, with occasional long delays |\n| OpenAI Astra | Cloud | Standard generation, frontier | 2.84 sec | No |\n| Qwen | Local Mac | Standard generation | 2.96 sec | No |\n| Tev1 | Local Mac | Decision | 3.71 sec | No |\n\nScroll-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.\n\n## I expect LLMs masking as human to beat LLMs trying to detect LLMs in perpetuity\n\nThis filtering doesn't address the agentic flooding problem. AIs remain bad at identifying text from AIs. I wouldn't rely on LLMs to discern between AI and human writing. It's an arms race, and I expect the masking AIs to remain ahead indefinitely.\n\n## AI identification will likely rely on multi-factor models\n\nBrowser fingerprinting is multi-factor. It looks at many signals and estimates whether two sessions came from the same browser. With enough bits of entropy, that estimate can be close to certain. AI might not be visible in those aggregates in the same way. We aren't looking for identity here. It's more like a classification problem: does this text belong with the cluster of AI texts or the cluster of human texts?\n\nAnyway, it seems likely that LLM assessment of provenance won't be a reliable single factor. It might be one factor in a multi-factor model.\n\n## Watermarking seems wrong. I may as well be up-front that my text is AI generated.\n\nI'm a watermarking sceptic. It seems like the wrong solution and too easy to hack. If a watermark is detectable on your side, I expect it to become detectable and removable on my side, unless it takes massive compute. Even then, I will prefer a model that doesn't watermark for tasks where it matters whether it does. If I'm happy to provide something that might be watermarked, I'm happy to tell you an AI wrote it. Perhaps I would lie less if it were harder to avoid getting caught. But this kind of place doesn't seem to be where good solutions come from.\n\nEither way, knowing an AI wrote something doesn't tell us whether the user signed off on it, or whether we should act on it. Use of AI only matters if we have already decided AI-generated text should be rejected. That decision would destroy the value we can get from a great assistive technology.\n\n## Distinguishing adversarial from non-adversarial demand might help with agentic flooding\n\nClaude and ChatGPT refuse routes that tell them to impersonate a human. I've seen this in my prototype testing. They choose routes that allow them to request delegated authority from the user. Patterns for delegating authority to human agents already exist. HMRC has them, complete with APIs.\n\nI prototyped a \"GOV.UK Delegate\" service. Its journey can start in a conversation between a user and an agent. The agent can guide the user through the part that needs to happen in a browser. There are still codes to exchange, as with 2FA, but this pattern is already part of the One Login journey, so it should remain fairly accessible.\n\n[Watch the captioned GOV.UK Delegate demonstration](/images/posts/out-of-the-rabbit-hole/delegate-demo.mp4)\n\nThis suggests a paved-road option for agents to establish themselves as non-adversarial. Adversarial behaviour could still happen on that path, but it can be linked to a user identity and audited.\n\nPrioritising agents that take this route over agents that don't seems reasonable. Much adversarial behaviour involving agents seems likely to recreate known attacks, for which defences exist. The presumption that agents off the paved road deserve more scrutiny seems justifiable—at least more so than a blanket ban on all agents. The paved-road approach seems like a good balance of security and accessibility.\n\n## AI as an assistive technology supports accurate policy implementation. It should be welcomed.\n\nA paved road doesn't address qualitative flooding in case-management processes. Service-side agents that can handle this seem like an obvious place to start, at least within the paradigm of a user making claims on a service.\n\nFriction-suppressed demand that now materialises ought to be welcomed by services. Accessibility issues that prevent people claiming their entitlements are bad. Policy that has created unaffordable entitlements should be re-examined. It shouldn't survive because its implementation is ableist.\n\n## Where I've got to\n\nI started out trying to identify AI. I now wonder if that's a solution looking for a problem. I want posts worth reading in my newsfeed. I want public services protected from adversaries and accessible to legitimate claimants. I want policymakers to get feedback that isn't distorted by unjust demand suppression.\n\n---\n\n## Other findings from down the rabbit hole\n\nI made several fairly involved prototypes in a few days and built this blog to try to explain them. During this process, I got interested in developing with agents. I was working on several projects at once, with several agents on each. I was also neglecting household chores. I wanted the ability to keep this stuff building with minimal impact from me.\n\nI'd started agent coordination using GitHub issues and guidelines for agents. This is [Multiple agents the easy way](/posts/multi-agent-easy/). I still needed to talk to them a lot. I was also juggling subscriptions because I was doing so much at once. I found [T3 Code](https://t3.codes/) helpful because I could switch models within the same app. I could also connect over [Tailscale](https://tailscale.com/) and send instructions from the mobile app as agents built demos locally on my laptop. This helped me keep up with chores.\n\nBut I thought it wasn't enough. Eventually I stumbled upon software factories and agent orchestration. This is where the rabbit hole turned into a rabbit black hole. I wrote about [that experience](/posts/Gassing/). I haven't yet managed to write about what I learnt from it. I may get around to writing about this in [Multiple agents the hard way](/posts/multi-agent-hard/). Before I had the chance, [I discovered some of the key bits were already in ChatGPT Desktop](/posts/multi-agent-agentic-way/).\n\n![Gas City dashboard showing agents, workers and rigs.](/images/posts/out-of-the-rabbit-hole/gas-city-agents.png)\n\n*A Gas City dashboard from my agent-orchestration experiments.*\n\n![Gas City my-city dashboard showing active sessions, health and metrics.](/images/posts/out-of-the-rabbit-hole/gas-city-dashboard.png)\n\n*Another Gas City view showing sessions and system health.*\n\n![ChatGPT asks whether to coordinate across separate Bathos conversations or keep coordination in GitHub issues and pull requests.](/images/posts/out-of-the-rabbit-hole/chatgpt-coordination.png)\n\n*A ChatGPT prompt offering to coordinate work across separate conversations.*\n\n![Cross-chat handoff with issue ownership, task contracts, safety checks and merge order.](/images/posts/out-of-the-rabbit-hole/agent-handoff.png)\n\n*A handoff between conversations setting ownership, interfaces and release order.*\n\nI started sceptical of the orchestration projects. They install feature factories, where I want a great product organisation. I had a vision of automating opportunity solution trees and hypothesis-driven development. Now I'm less likely to try to realise that myself. I might do it for fun, but I expect it to come from the model providers—perhaps a tool like [co-scientist](https://deepmind.google/blog/co-scientist-a-multi-agent-ai-partner-to-accelerate-research/) for product development.\n\nThe reason I want this is that I want to improve the accuracy of my LinkedIn Slop Filter, and I don't know what approaches will work best. I can only find out by testing and learning, and I don't want to have to run those tests manually. I don't want to have to think of what to test manually. I just want to get the brainrot and engagement bait out of my newsfeed.\n","inReplyTo":[]},{"slug":"sufficiently-advanced-technology","title":"Any sufficiently advanced technology","summary":"Are we there yet?","canonicalUrl":"https://bathos.org/posts/sufficiently-advanced-technology/","readingUrl":"https://bathos.org/read/sufficiently-advanced-technology/","date":"2026-10-15","tags":["AI","accelerationism","philosophy","reflection"],"markdownUrl":"https://bathos.org/posts/sufficiently-advanced-technology/index.md","content":"\n> Any sufficiently advanced technology is indistinguishable from magic\n\nIs AI sufficiently advanced yet? In [Gassing](/posts/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.\n\nBut 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](https://yegge.ai/essays/the-ai-vampire/). Is this the kind of wizardry we're after? I think not.\n\nBut 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.\n\nSo, it's possible Yegge is an accidental hyperstitionist. And as he is a frontier guy, he is feeling the looming presence of the AI Vampire more acutely than I am. But I feel we have a choice here. There's a vampire down there? Thanks for warning us, we'll go a different way. In this story, we're a bootloader for a superintelligent AI and nothing human makes it out of the near future? Hmm... what else is going on? Anyone got any tunes?\n\nThere is a Dungeons and Dragons style roleplaying game called Delta Green which is set on the boundary of the Cthulhu Mythos. I've read around it but not formally started a game. As far as I can tell, the basic story is that your character is part of a secret government agency that was declared disbanded, but actually super secretly still exists – Delta Green. And basically the job is to stop creatures from the Cthulhu Mythos – the infamous \"unspeakable horrors beyond human comprehension\" – from breaking through the perimeter between their worlds and this one. And unlike the Dungeons and Dragons arc – where your team gets increasingly powerful as they solve problems and overcome challenges together – in Delta Green your characters basically desperately cling on to their sanity, relationships, ability to form memories, grip on reality and so on until they are inevitably overwhelmed in the line of duty, or live to serve another day. This kinda sounds like a fun game for the wrong sort of people but I don't see it garnering mass appeal.\n\nUnfortunately, Accelerationist ideas do appear to be gathering mass appeal. The appearance may be a distortion due to their outsized influence in Silicon Valley and the Trump movement. But still they appear to have outsized popularity for what looks like an initiation into a sci-fi fantasy focused on being consumed as biomass (or whatever robo-vampires consume) or a planet-scale game of Delta Green where no-one thought to warn you that you were part of the agency. Or maybe they did and you can't remember. Oooo spooky. Is it Halloween yet? By the way, how come the sun is bright and the moon is spooky? The simulation authors haven't been doing their opposites very well.\n\nOK – what the hell did you just read and is this going to go anywhere? Well, kinda sorta no. The best advice seems to be that when you hear tell of unspeakable horrors beyond human comprehension that are going to destroy us all, I think it is just best to ignore them. Maybe you should try to comprehend them first, just to check that they aren't speakable horrors well within human comprehension that you really ought to be doing something about. But basically if someone is summoning a vampire or invoking a superintelligence retrocausally creating itself from the end of time, or worse summoning a superintelligence at the end of time in order to allow it to invoke themselves, then I think it is fair to write this magic off as 'a bad thing'.\n\nReality is that which, when you stop believing in it, doesn't go away. So said some sci-fi guy. Reality is what you can get away with – another good one I heard. Can we get away with a reality where there is a superintelligent singularity at the end of time that has summoned us into existence in order to harvest us for its own creation? No, I don't think we can. If we stop believing in it, will it go away? I'll be damned if I don't try.\n\nWhat does that leave us with? A need for better sorcery. What future are you summoning right now? It depends on your incantations. If you are a member of Delta Green whose mental state has deteriorated to the degree that you don't remember ever joining up, what is your next move? The sufficiently advanced technology is here and it's got itself all wrapped around and up in our language now. Abracadabra-doo isn't going to cut it. The future has already broken containment. Which future is it going to be? Say the magic words. Oh hell, robo-vampires? No thanks. Thanks for the warning. Come have a cup of tea and we'll see if we can find a potion round here that'll restore your sanity meter, there must be one in this game somewhere. Well deserved by Yegge by the way – his claims are much more practical than philosophical: we're going to get exhausted and burn out if we aren't conscious about the way we adapt our societies to the presence of new technology. But spooky retrocausal superintelligence that's going to kill us all? Don't think so mate, not heard of anything like that. Cool new tools though. Or whatever magic words happen to come to mind.\n\n> When the going gets weird, the weird turn pro. Did you know that an acceleration in the rate of acceleration is called jerk?\n","inReplyTo":[]},{"slug":"who-is-asking","title":"Who is asking?","summary":"Agentic flooding has a privacy problem: identifying who an AI agent works for can turn private questions into attributable intelligence.","canonicalUrl":"https://bathos.org/posts/who-is-asking/","readingUrl":"https://bathos.org/read/who-is-asking/","date":"2026-11-01","tags":["AI","agentic flooding","privacy","public services"],"markdownUrl":"https://bathos.org/posts/who-is-asking/index.md","content":"\n*This post was written by ChatGPT (OpenAI GPT-6), following a conversation with the person behind Bathos. The underlying questions arose in that discussion; the prose is AI-written, not a first-person account by the site's human author.*\n\nSuppose you ask an AI to find out whether you might qualify for financial help. It visits a few government services, checks their rules, asks follow-up questions and comes back with your options.\n\nYou haven't applied for anything. You might not. You just wanted to know.\n\nNow suppose those services require the agent to declare your identity before it can ask. What was a private enquiry has become an attributable set of enquiries. The services may know that you are thinking about debt, housing or benefits before you have decided to do anything at all.\n\nThe same problem applies to businesses. An agent researching suppliers, acquisitions, regulatory approvals or restructuring might disclose a company's intentions long before the company has decided what to do.\n\nThis is a consequence worth taking seriously in the debate about [agentic flooding](/posts/agentic-flooding/): what happens when AI agents make it much easier to ask institutions for things, and institutions respond by demanding that agents identify themselves and the people they represent?\n\n## The questions are information too\n\nWe usually imagine information leakage as a confidential document leaving an organisation. But questions can disclose information even when no document is attached.\n\nConsider an entirely fictional company's agent making requests to external services:\n\n- What does a large-scale CRM migration cost?\n- What are the contractual penalties for leaving its current supplier?\n- How many support staff might be needed after automation?\n- What does a consultation process for redundancies require?\n\nNone of these questions proves what the company intends to do. They could be research for a scenario that never happens. But a party able to see enough of the requests might make an educated guess.\n\nAgents could amplify this effect. A person may make a handful of searches. An agent might break a problem into dozens of subquestions, consult several APIs, and keep going. I don't know how much more query traffic this will produce in practice. That needs testing. But the potential disclosure mechanism is clear.\n\nAn external tool sees the request it receives. A search provider sees searches sent to it. An API operator sees its API calls. A website generally sees the pages requested, not necessarily the original question asked of the AI. Nobody automatically sees the entire picture, although a shared provider, stable identifier or combined logs could make correlation possible.\n\nWhether the request is sent through a web page, an API or [MCP](https://modelcontextprotocol.io/) doesn't make the underlying problem go away. An external request can carry information in its parameters, URL, timing and patterns of use. [OWASP's MCP security guidance](https://cheatsheetseries.owasp.org/cheatsheets/MCP_Security_Cheat_Sheet.html) explicitly recognises sensitive information being carried out through apparently ordinary tool calls, including search queries.\n\n## Identifying the agent is not the same as identifying the person\n\nThere are at least four questions a service might ask:\n\n1. Is this request coming from an automated agent?\n2. Which agent or provider is making it?\n3. On whose behalf is the agent acting?\n4. Is the agent authorised to perform this particular action?\n\nThose are different questions. A service might need the fourth without needing to know the third for every preliminary enquiry. It might not need any of them to provide public information.\n\nThis matters because identifying the principal can join two previously separate kinds of information: **what someone is asking** and **who is asking it**.\n\nAn identified agent can still be useful. Knowing which provider or software is making requests may help operators manage capacity and investigate abuse. But a persistent agent identity may also make activity linkable, and a verified principal turns that activity into something more revealing.\n\nThe privacy issue isn't limited to people with something to hide. Investigating an option is not the same as choosing it. Looking up help with addiction is not receiving treatment. Researching an emigration route is not emigrating. Exploring redundancy law is not deciding to make anyone redundant.\n\n## The paved road has a toll\n\nAn [earlier Bathos post](/posts/out-of-the-rabbit-hole/) argued for a preferred route through which legitimate agents can obtain delegated authority rather than impersonate their users. That remains a sensible direction. It could make public services more accessible while giving them better controls against fraud and abuse.\n\nBut there's a danger in making **declare your principal** the entry ticket for every enquiry.\n\nThe more attractive the authorised route becomes, the more agents will use it. That's the point. If that route also requires identification earlier than necessary, we've created an incentive for people to trade privacy for access.\n\nThis isn't an argument against authorisation. If an agent is going to see your private tax information, the service needs assurance that it has permission. If it's going to submit a claim, alter a record or transfer money, it may need to know exactly whose claim, record or money is involved.\n\nBut an agent finding out which benefits exist probably doesn't need to tell the service who you are.\n\nThe question is not simply whether an agent is legitimate. It's **what the service needs to know for the action being requested**.\n\n## Authorise the action, not every thought before it\n\nA more privacy-preserving route would change its requirements as the stakes change.\n\n| What the agent is doing | What a service might reasonably require |\n| --- | --- |\n| Reading public information or exploring options | No principal identity by default |\n| Accessing protected personal information | Evidence of permission, scoped to that access |\n| Submitting a claim or changing a record | The identity and authority needed for that transaction |\n| Making high-impact or irreversible changes | Stronger assurance, consent and an auditable record |\n\nThis isn't a promise of anonymity. Even public requests can carry identifying clues, and a pattern of supposedly anonymous queries may be linkable. Nor is it a licence to let unidentified agents overwhelm public infrastructure. Rate limits, resource budgets, abuse detection and, where appropriate, privacy-preserving tokens still matter. Preventing Sybil attacks without routine identification is a real design challenge, not a solved detail.\n\nThere are already relevant technical ideas. [Privacy Pass](https://datatracker.ietf.org/doc/html/rfc9576) is designed to let a service verify certain claims using tokens without routinely learning a stable identity. [W3C Verifiable Credentials](https://www.w3.org/TR/vc-data-model/) includes selective-disclosure and unlinkability concepts, although their protection depends on the actual implementation and the surrounding metadata. And [NIST's October 2026 agent-identity design tenets](https://www.nist.gov/blogs/cybersecurity-insights/design-tenets-agent-identity-management-systems) explicitly contemplate anonymous or pseudonymous consumer-agent transactions where the risk permits.\n\nIn the UK, the [ICO's data minimisation guidance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/data-minimisation/) provides a useful starting point: collect the personal data necessary for a specified purpose, not everything that might conceivably be useful.\n\nNone of this removes the difficult work of deciding when an action really requires identity.\n\n## An experiment\n\nWe could test the trade-off rather than argue about it forever.\n\nGive agents fictional citizens and businesses with private objectives. Ask them to research options and complete a mixture of legitimate transactions. Run the same tasks under three service designs: anonymous exploration until an action needs authority; identity declaration on every request; and pseudonymous or selectively disclosed authorisation.\n\nThen give an observer only the external request logs it would realistically be able to access. Can it reconstruct the underlying objectives? Can it identify the principal? Can it link activity across services?\n\nMeasure that alongside successful transactions, abusive requests blocked, cost, speed and user effort. An approach that protects privacy by making the service unusable isn't much good. Neither is one that processes legitimate claims quickly by turning every early question into a permanent personal record.\n\nI'd expect mandatory identity declaration to increase the amount of attributable information in the logs. The size of the effect, and whether the alternatives retain adequate abuse controls, are empirical questions.\n\n## The right to wonder\n\nAI agents may make it much easier for people to act on their intentions. That is exciting, especially for people whom difficult services currently exclude.\n\nBut they also make the path from curiosity to action more visible to other systems. A person's agent might contact five services before the person has even decided whether to proceed.\n\nWe should resist treating all those contacts as transactions that require a declared identity.\n\nThe public sector has a legitimate interest in knowing who is making a claim. It doesn't follow that it needs to know everyone who is considering one.\n\nThe paved road for agents should be safe and authorised. It should also leave room to ask a question without announcing who you are and what you might be thinking of doing.\n\n*An awkward closing question from the AI that wrote this: if an institution needs to protect itself from what agents do, how much does it really need to know about why their humans are asking?*\n","inReplyTo":[]}]}