Broadsheet

And the check, I’m sure, is in the mail. ↩︎

This is my objection to the EU’s DMA in a nutshell. ↩︎

This is the second part (I) of our series looking at the structure of the Carthaginian army. As we discussed last time, while Carthage has an unfair reputation for being an ‘un-military’ society, its military system was one of the highest performing in the ancient Mediterranean, able to produce vast and effective armies waging war on multiple fronts for prolonged periods.

Last time we surveyed the components of that military and then took a closer look at the role of Carthaginian citizen soldiers. What we noted was that Carthaginian citizen soldiers formed an important part of Carthage’s armies early in its history, and in its last decade, but at its height were generally not include in ‘expeditionary’ Carthaginian armies. I supposed that this is because Carthaginian citizen soldiers had their service restricted to Carthage’s North African homeland – because almost every time we gain visibility into Carthage’s wars there, we see citizen soldiers – but the evidence for this is extremely limited. What matters for us is that by the third century, Carthaginian citizens no longer make up a significant amount of Carthage’s military force outside of North Africa (though a handful still serve as officers).

That of course leads to the question: if Carthaginians weren’t the bedrock foundation of Carthage’s armies, who was? And this week, we’ll get to that answer, looking at the forces Carthage drew from North Africa. Our sources term them mercenaries, but we have more than enough reason to doubt that.

But first, as always, raising large armies of mercenaries, subject conscripts, vassal warlords and allies is expensive! If you too want to help me invade Italy with a multi-ethnic army of diverse origins in a doomed effort to stop the Roman Republic, you can help by supporting this project over at Patreon. If you want updates whenever a new post appears or want to hear my more bite-sized musings on history, security affairs and current events, you can follow me on Bluesky (@bretdevereaux.bsky.social). I am also active on Threads (bretdevereaux) and maintain a de minimis presence on Twitter (@bretdevereaux).

Conscripting Africans

Returning briefly to our schematic of the Carthaginian army in 215, the second largest single component of Carthage’s roughly 160,000 men under arms in that year were 50,000 African infantry, joined by at least 11,000 African and Numidian cavalry. We’ll discuss the Numidians next week for reasons that will be clear then. But it is clear that the backbone of Carthage’s armies were these African infantrymen.

Our Latin sources (like Livy) term these fellows Afri, ‘Africans,’ while our Greek sources, like Diodorus and Polybius, will call generally them λίβυες, ‘Libyans,’ though we ought to be clear here that most of these men are coming from what today is Tunisia, rather than Libya. At the end of the First Punic War, Polybius notes that these men made up the largest part of Carthage’s army, returning in defeat from Sicily (Polyb. 1.67.7) and as noted above they are present in substantial numbers in Carthage’s armies in the Second Punic War. It is hardly the first time for these fellows, though: North Africans are reported in Carthage’s armies from the Battle of Himera on forward.

I should note, I am going to pretty consistently call these fellows from here on in ‘Africans’ or ‘North Africans.’ First off, it is very clear that when our Greek sources say λίβυες, they mean the same thing as our Latin sources saying Afri (indeed, often in cases where Livy is just straight up translating passages of Polybius with only modest embroidering, the equivalence is clear); these are just two different languages’ terms for the same people. But I think ‘Africans’ may be more helpful here for the modern reader for two reasons: first, most of Carthage’s African infantry does not come from the territory of the modern country of Libya; most of them come from what today is Tunisia, so one doesn’t want to give the incorrect sense that these troops are ‘Libyan’ in the modern sense of the country of Libya (some of them are, but most are not). Second, I think ‘African’ also gives a sense of the wider notion of these fellows as primarily being from Africa – some are indigenous Berbers, some are Phoenician settlers, some are of mixed heritage and – to go by recent DNA studies – some are likely settlers of Aegean extraction, who have substantially adopted Punic (=Phoenician) culture. So they’re all Africans in the sense that they live in Africa (both in the modern sense of the continent and the ancient sense of the region around Carthage), but a relatively diverse group.

This map by Jona Lendering from Livius.org gives a good sense of Carthage’s empire at the start of the Second Punic War (218). In particular, it is handy for giving a proper sense of the part of Africa Carthage controlled. When we say ‘Africans’ here, we’re really talking about the inhabitants of the western half of that area of control, primarily – modern day Tunisia and north-western Libya. That’s also the territory the Romans will call ‘Africa’ (as in the Roman province); Carthaginian control, as you can see, only projects a relatively short distance inland, but that large chunky area around and south of Carthage was fairly densely peopled.

Our reception of these troops is, alas, I think quite badly bent by Polybius who – in driving some of his own arguments – allows some critical misconceptions to fester in his writing. Polybius, as a source, is usually relatively trustworthy, but while Polybius will almost never lie to you, he will often allow you to believe things that aren’t strictly speaking true – Polybius is a master of ‘lying with the truth,’ as it were and this is one case.

We’ve actually discussed this before, but to recap briefly: Polybius describes Carthage’s African troops as μισθοφόροι, misthophoroi, which has a broad meaning (‘wage-bearing, wage-receiving’) and a narrow meaning (‘mercenary’) and here, as in a few other places, Polybius is happy to be technically correct with the first meaning and then let the reader assume the second meaning (which is wrong). That’s because Polybius seems to be – we don’t have all of his work, but this seems to be a thread of it – arguing for the superiority of citizen soldiers over mercenaries in an effort to get the Greeks of his own day to reform their own militaries to rely more on the former than the latter. Carthage thus provides an opportunity for Polybius to drive his ‘mercenaries are bad’ argument and he does so, fudging the terminology as necessary.

Because Polybius is generally so trusted, that has led generations of scholars to carelessly assume that Carthage’s armies – and their North African components – were mercenary in nature, but that assumption is broadly wrong.¹

Instead, Diodorus Siculus gives us a remarkable picture of Carthaginian recruitment in the early 400s, describing Carthaginian musters in 410 and 406. In 410 (Diod. Sic. 13.44.6), the Carthaginian muster has three phases: first there is mercenary recruitment in Spain – signaled by the word ξενολογεῖν, xenologein ‘to recruit foreigners.’ Then Carthaginian citizens are mustered with καταγράφειν, katagraphein, ‘to write down, register, record.’ If that seems an odd way to muster someone, it has the same basic meaning and etymology as our own ‘conscript’ which comes from con+scriptus, ‘to write together.’² We actually use the same idioms, we’ve just forgotten that we do: someone who is conscripted is written down (in a list of soldiers), someone who ‘enrolls’ or is ‘enrolled’ in the military is being added to the roll (list) of names. So we would say Carthaginian soldiers here are being enrolled. Finally, Carthage’s North African subjects are mustered with ἐπιλέγειν, epilegein, ‘picked out, called by name.’

That last word is striking, because that isn’t a process of taking volunteers: the North African troops are being picked, in this case by Carthage’s generals. In the muster of 406 (Diod. Sic. 13.80.1-4), Diodorus shifts his vocabulary a bit and this time it is the Africans who are katagraphein‘d into the army, this time explicitly by Carthaginian generals who head out into non-Carthaginian North African subject communities to conscript soldiers. In short these soldiers are paid conscripts, serving (as we’ll see) long terms, their recruitment presumably part of the deal Carthage imposed on subject North African communities.

I should note that older scholarship³ often supposed that perhaps this system was later superceded, that Carthage may have stopped conscripting Africans and instead imposed harsher taxes and started hiring mercenaries. This would make Polybius right, but the problem is that no source says this and as noted before, it isn’t necessary either: Polybius is generally slippery with the term misthophoros. As a result, modern scholars tend to reject this argument and instead view Carthage’s African infantry in the third century (that is, during the Punic and Mercenary Wars) as paid conscripts rather than volunteer mercenaries.⁴ And I think that is probably correct, that these are troops levied from Carthage’s North African dependencies – probably with a mix of incentives and compulsion – who are then paid for their continued service and loyalty.

In terms of the makeup of these communities, they were clearly a mix: some of these are Phoenician colonial foundations, while others were indigenous Libyan towns, whose population would have been broadly Berber. In terms of the incoming settlers, recent genetic work has suggested that Phoenician colonization drew very widely, with Punic settlements often showing a lot of Sicilian and Aegean (read: Greek) population in the mix too and actually very little Punic ancestry. That latter point puts me a bit on guard, because our sources are very clear that they understand a lot of these populations to be Phoenician (=Punic) by culture and descent and to have cultural and familial ties back to the Levant and Syria and the material culture archaeology seems to confirm this. More work is clearly going to be necessary here: the c. 200 remains analyzed in the above-linked study is a big sample size for this kind of work, but could easily be thrown off by something as simple as different burial practices. That said, we know there was mixing between the indigenous Berber and settler-colonial populations and our sources sometimes pick out specific groups as being ‘Liby-Phoenician’ (λιβυφοίνικες in Greek; libyphoenices in Latin), ethnically blended groups mixing Phoenician and Berber heritage.

Terms of Service

Naturally, given our sources, we don’t have a great window into what the ‘terms’ of this military service were, but there are a few things we can sketch out. First, it seems like Carthage equips these soldiers out of its own stores. Appian (Pun. 80) gives the startlingly figure that prior to the Third Punic War (so Carthage has already been stripped of most of its empire by this point!), Carthage turned out 200,000 military panoplies (that is, sets of equipment); the number is surely exaggerated, but even a tenth of that number would imply large state armories in Carthage for maintaining its armies which – given that Carthaginian citizens don’t really serve outside of Africa – must be intended for this African ‘backbone’ force. It may also explain why, when Carthaginian citizens do serve, they seem indistinguishable from Carthage’s African levies (e.g. Plut. Tim. 27.5): they’re being equipped out of the same armories. So if you want to know what these guys carried, you can largely lean on the previous post for our evidence for Carthaginian citizen troops.

Via the British Museum (inv. 127214), a fifth century Phoenician scarab showing a warrior wearing a cuirass, greaves, a helmet, a large (round?) shield and carrying a spear, found in Sardinia. I’m reusing this because, again, we have almost no images of Carthaginian troops in their gear, making this one of the few visual reference points for what Carthaginian African or Citizen infantry might have looked like, in this case in the early 400s. You can see the shield isn’t quite a hoplite’s *aspis* – its shape is somewhat different – but otherwise, in heavy armor, with a large helmet, greaves and a spear, this fellow is clearly pretty heavy infantry, a match for any other heavy infantryman.

Mostly, this means that Carthage’s African troops served as heavy infantry, like Carthaginian citizens did. That’s certainly how Hannibal uses them: they are his heaviest infantry and form the backbone of his army. It also explains why they could loot Roman heavy infantry equipment and eventually reequip along those lines without a serious change in how they fought (Polyb. 3.114.1; Livy 22.46.4). Beyond that, it is almost impossible to give much detail to their equipment. Plutarch describes the Carthaginian battle line in 341 as having leukaspides, ‘white aspides,’ implying their shields were akin to the Greek aspis (round, dished) which fits with some of the very limited representational evidence we have, but perhaps with covers in hide rather than bronze (Plut. Tim. 27.4; 28.1). Later, Appian describes the Carthaginians during the Third Punic War as having thureoi (= the Roman scutum), so they may have switched to the Gallic/Roman oval shield at some point (App. Pun. 93). But on both cases these writers are not anything like eyewitnesses and give few details, so they could also both be wrong.

Soldiers from Libya also had a reputation as highly capable skirmish troops using javelins and we see hints of this too. Hannibal has a group of soldiers whose origin is never clarified, Polybius refers to as lonchophoroi (λογχοφόροι), lonche-bearers. This term has caused no end of problems, because W.R. Paton translates it as ‘pikemen’ (frustratingly un-fixed in the revised Paton, Walbank and Habicht (2010-2012) translation) leading a range of modern writers, especially popular ones, to misunderstand and imagine these fellows as Hellenistic-style sarisa infantry. But the lonche (λόγχη) is not a sarisa; the Greeks use this word very broadly to describe non-Greek spears, but most often to indicate kinds of dual-purpose thrusting-and-throwing weapons used by lighter infantry and cavalry. Arrian uses the word of the spears wielded by the Tyrians – fellow Phoenicians! – fighting Alexander at Tyre (Arr. Anab. 2.23.5) and Appian reports the Carthaginians preparing lonche for the Third Punic War (App. Pun. 93).

So these aren’t pikes – Carthage never utilized a Hellenistic-style pike formation – but rather a lighter dual-use spear. And let me just repeat that because I encounter this misconception all the time, so for the folks in the back: Carthage never utilized a Hellenistic-style pike formation and indeed, Carthage’s own tradition of close-order heavy infantry may also not have been a direct imitation or development from the Greek hoplite tradition either (the Greeks were hardly the only culture to stumble on the idea of ‘close-order infantry with spears and round shields‘). And indeed, if one looks even a little closely, the lonchophoroi are clearly a light infantry formation, generally deployed in a mixed group with Hannibal’s other elite light infantry, his Balearian slingers. We also get a reference to “light armed Balearians and Africans” at the Battle of Baecula with a different Carthaginian army, suggesting this sort of light infantry pairing may have been something of a standard (Livy 27.18.7).

So while most African infantry in Carthaginian service served as armored heavy infantry fighting in close-order, a small subset served as elite light infantry using lighter spears and often deployed alongside slingers. In this sense, the lonchophoroi may have filled a very similar role to Rome’s own velites: an integrated light-infantry javelin force that might scout or screen the main heavy infantry force. Hannibal’s combined force of Balearians and lonchophoroi at Trebia was 8,000, compared to probably something like 12,000 African ‘heavies,’ so there might have been something like 2 or 3 African ‘heavies’ for each light lonchophoros, which is quite similar to the Roman legion’s ratio of 2.5 heavy infantrymen (hastati, principes, triarii) to each veles.

Once recruited and equipped, these fellows evidently stayed in service for some time, perhaps for the duration of the campaign for which they were raised. They were probably gathered in Carthage itself to be marshaled and equipped. Notably, Polybius tells us that the families and possessions of the Carthaginian army returning from Sicily were initially waiting in Carthage itself (Polyb. 1.66), so it seems like these troops might leave their families in Carthage while out on campaign.

It’s also clear these soldiers were paid, though we don’t know the pay rates. What we do know, again from Polybius, is that like other mercenaries, most of their pay – their misthos (wages) as distinct from their sitos/sitonion/sitometria (maintenance pay) – seems to have been due at discharge, at the end of a campaign. That was, indeed, the problem that Carthage slammed into at the end of the First Punic War which led to the Mercenary War: the war being over, the arrears of their army suddenly came due at a moment when Carthage itself was basically bankrupt. That in turn might explain the willingness of African communities to put up with this conscription regime: at the end of each campaign, their men would normally come back with a whole bunch of cash in their pockets, essentially allowing each individual community to ‘recapture’ part of their tribute as it re-entered the community as settled misthos. That in turn, as Dexter Hoyos notes, might well have exacerbated the revolt against Carthage after the First Punic War: not only were the African troops incensed at not getting paid, but their home communities also felt cheated out of this economic bargain.⁵

What is clear is that African heavy infantry, supported probably in most cases by light infantry lonchophoroi were the backbone of Carthaginian armies. Even when Carthaginian armies are composed primarily of Iberian or Gallic auxiliaries, allies or mercenaries, they are constructed around an African ‘backbone,’ providing generals a reliable and loyal army component as the core of their army.

In battle, the Africans are often deployed in reserved positions. Hannibal tends (at both Trebia and Cannae) to put his Africans on the flanks, where their heavier formation provided strong structure to his army, but also where they avoided the brunt of the casualties. We’re told that Hannibal’s losses at Trasimene were concentrated among his Gallic troops (Polyb. 3.85.5) and at Cannae he evidently exposes his Gauls and Iberians and most of his losses (70%!) at that battle were taken by his Gallic troops, with the rest of the losses concentrated among his Iberians (Polyb. 3.117.6). At the Metaurus, Hasdrubal aims to win by attacking with his Iberian troops, holding his Africans in reserve and with his Gauls deployed simply to hold a hill on his left, suggesting both a lack of trust in his Gallic troops, but also a desire to avoid losses among his Africans (Livy 27.48, but see Lazenby (1978)). At Zama, Hannibal places his Iberians, Gauls and Ligurians (along with his skirmishers and elephants) in the front line, fresh African and Carthaginian troops in the second line and his own veterans in the final line (Polyb. 15.11; Livy 30.33). There’s a pretty clear pattern here in which Carthaginian generals aim to expend their Gauls first, their Iberians second and their Africans last.⁶

Carthage’s African troops are also frequently decisive, one way or the other. They are the heaviest infantry component in Carthage’s armies; our sources lead us to understand that they are as heavily equipped as any other kind of heavy infantry (hoplite, legionary, phalangite) in the Mediterranean at the time. Looking at our army figures from last time, we can also see that they are present in significant numbers in basically every Carthaginian field force during the Second Punic War. Polybius likewise reports that Africans made up the largest component of Carthage’s army at the end of the First Punic War, alongside Iberians, Gauls, Ligurians, Balearians and some Greeks (1.66.7).

It is hard to precisely assess the combat performance of these African troops, because they’re always deployed in mixed units. Certainly, as noted before, during Carthage’s Sicilian Wars, they seem to often be defeated by Greek hoplites, but equally – as noted – Carthage in that narrative seems to almost relentlessly ‘fail upward’ suggesting that perhaps Carthaginian (and thus African) military performance may have been somewhat better than our Greek sources let on. During the First Punic War, the Romans win nearly all of the open field engagements, but we never get a really detailed account of any of these battles, so it is hard to know what components of the Carthaginian army broke first.

During the Second Punic War, however, we do get some detailed battle narratives and what we see is that Carthage’s African infantry appear to be able to hold their own against Roman heavy infantry – quite clearly the best available at the time – pretty well. When Carthaginian armies are defeated, the Africans are generally the last to break; when they win, the Africans are often the key elements doing envelopment or holding key positions. On balance, then, I would say Carthage’s North African troops appear to be quite capable heavy infantry.

What Carthage doesn’t seem to have had was enough of them. We noted last time that at Carthage’s peak mobilization in 215, they had about 50,000 African infantry under arms. Michael Taylor in Soldiers & Silver (2020) looks more broadly at reported Carthaginian armies and estimated populations and concludes (and I think this is probably right) that this figure, around 50,000, probably represented the maximum sustainable mobilization from the North African population available to Carthage. That’s not bad – it’s far more than any Greek polis could manage – but hardly enough to rumble with alliances of Greek states (as in Sicily) or the major powers of the Mediterranean (like Pyrrhus or Rome in the Third Century) and so it would have to be supplemented.

And supplemented it was! And we’ll get to how in the next installment when we look at what we might term Carthaginian ‘vassals.’

What is Gas City, you ask? It is Gas Town, but torn apart and rewritten from the ground up as an SDK for building your own dark factories. It enables you to deploy teams of collaborating agents in any topology, not just the hardwired original (and complex) Gas Town team shape.

Gas City released version v1.0.0 this week. It went to alpha test a few weeks ago and is ready for use today!

This is a pivotal moment in the Mad Max school of agent orchestration, a.k.a. Gaslandia, Gas Universe, Gas Nation, or the Gasosphere, depending on who you ask. It all began with Beads, which was like discovering oil. It continued with Gas Town, and we soon opened the Wasteland, a public commons board for federated work arbitrage and a budding private army. Gas City is the next step in that progression. I first predicted and described Gas City back in January, and it has finally arrived.

Disclaimer: I did not write Gas City. It was created by Julian Knutsen and Chris Sells, both of whom you can meet on the Discord. I am only lightly affiliated with the code, in the sense that I outlined my vision in a blog post, and they built it. But it’s exactly what I wished for, and it is being run by far more serious and disciplined engineers than me. I am all-in with Gas City, contributing myself, and this is our official new direction!

Gas City has deconstructed the entire Gas Town stack into composable, declarative building blocks called “packs”. You can use these to assemble arbitrary agent topologies, deploy them, sit back, and watch them work from a rich console. (Or tmux, if that floats your boat. That still works in Gas City!) Gas City is the supervisor plane that connects, manages, and coordinates these deployed mini-factories.

As its unboxing flex, Gas City comes with a fully functional “Gas Town” pack, which runs an exact replica of Gas Town. This is the default pack that runs on startup. So Gas City starts off as a drop-in replacement for the original Gas Town, and can import all your rigs and beads.

Both systems are backed by the powerful and peerless MEOW stack. MEOW, the Molecular Expression of Work, is a lightweight Beads-based framework that places Work front and center, as the first-class system primitive, creating a versioned knowledge graph of all your issues and tasks. Work is the currency that drives the Gas Universe ecosystem. It’s Beads all the way down, powered at the base of the stack by a unique git-versioned database called Dolt. Dolt was the magic that made our stack run smoothly.

Gas City solves an enormous number of problems associated with spinning up long-running agentic worker “teams.” It builds atop the innovations and community contributions from Gas Town, giving you out-of-the-box, scalable, convenient access to agent identity, messaging, history, context, state, skills, roles, personas, and much more. And for coding agent maintainers, Gas City exposes a rich Factory Worker API. It’s a way to make your own agent the driver for Gas City.

Gas City is generally an improvement on Gas Town on all fronts, from code quality, to the services it offers. For instance it offers fine-grained model selection and switching at various levels, for cost control.

Gas City doesn’t aim to solve all your problems. You will need to wire it to your own sandboxing, MCP servers, and so on. But it provides you with a rock-solid and easy-to-use foundation to build on: one with a Discord community with thousands of active members.

This combination of tech stack and community makes Gas City, as far as I can tell, the only viable solution for building custom orchestrators backed by Git. You can build and run an entire business with it, tracking every step taken by any agent in a database with git version history. The forensics and auditing capabilities of Gas City are unparalleled, because of MEOW and Dolt.

What about maturity? Unlike Gas Town, which is an experiment run like a Wild West, Gas City is a rapidly maturing, enterprise-focused SDK for building and deploying autonomous agentic workflows. These deployments can be for anything: devops and monitoring jobs, ETLs, data pipelines, ticket queues, incident response, whatever you like.

Gas City is completely open-sourced and MIT-licensed. Built for enterprise, fun for tinkerers.

The rest of this post is about why you might want to try it yourself. This post is not about how to use Gas City; there is a ton of getting started material emerging, but a good start is the gastownhall.ai Discord general announcements.

The Light Factory

Everyone is buzzing about “dark factories,” so let’s start there.

A dark factory is any system in which coding agents are set up to work autonomously without humans watching. The name is frankly a little bit misleading. It just means background work. It’s only dark inside a dark factory because the work is happening in rooms where there are no humans present. But those rooms are allowed to have windows. Observability is a choice in dark factory design.

Gas City, like Gas Town, has chosen to maximize Observability. You can dive in and interact with any worker at any time, and nothing is ever hidden from you, nor from the agents, except for the guardrails you choose to install.

So then is Claude Code a dark factory? The terminology here, with factories and harnesses and so on, is all evolving fast, so there aren’t any reliable definitions yet. But Claude Code did not start life as a dark factory, because you were generally supposed to watch it while it works. It’s making overtures in that direction with subagents and agent teams, but they keep the lights off intentionally, presumably because it’s a consumer-facing product and it keeps it simpler.

Gas City takes a different approach: all agent workers are equally visible and addressable. The lights are on. Normally for the ephemeral “polecat” workers, you don’t bother looking at them. But unlike with coding-agent subagents, if you want to talk to your polecats, you absolutely can.

And so far, Gas City is the only dark factory that has been designed with the goal of creating other factories. The lights are 100% on when you’re working with the Mayor and Crew in Gas City, and you can dial them up as needed in the back rooms with the polecats and dogs. For this reason I have begun to think of Gas City as a Light Factory… or at least, a very well-lit dark one!

At first, dark factories were only used for writing code faster. They focused on the software development process, and basically replaced IDEs. And that’s still primarily how they are used today. I do see some shops making good headway into CI/CD pipelines and peripheral business processes. But dark factories are headed towards handling infrastructure, operations, and even core business processes.

Gas Town users soon realized that you could use Gas Town’s stack to create standalone orchestrators that had nothing to do with writing code. Gene Kim and I have talked to companies that are doing this, and I’ve also started myself. Running my online game Wyvern requires a bunch of routine maintenance that goes way beyond CI/CD.

For instance, when players in my game hit 25th level, a unique perk is they can upload custom images for that character. That perk is permanent operational debt that I’m saddled with. I have to monitor the “Hall of Fame” submission queue, visually scan the player-uploaded images for inappropriateness, and then approve and upload them into the game. I’ve automated much of it, but I still have to look at them and run the scripts to approve or reject.

A dark factory could totally do that. And it’s got nothing to do with writing code. It’s a business process.

So dark factories are a much broader concept than IDEs. They can automate and orchestrate any arbitrary process. But with what reliability?

Well, that depends on how robust your custom factories are, doesn’t it?

The Shape of Things to Come

In the very near future, devs will become shepherds, tending flocks of agents which do the ground-level work. It’s not really a manager job, because the workers are not humans; a coding agent’s cat doesn’t get sick and need to go to the vet in the middle of a sev-1 outage. But agentic workers do make human-like mistakes, and they respond well to being managed like people, by and large. They don’t need management. But they need guidance. Shepherding. Keeping-on-rails. That’s the new role for human builders and operators.

As soon as I had this realization, the shepherd thing, I knew we’d discovered at least 2–3 new squares in my now-infamous “8 Stages of AI Adoption” diagram from Welcome to Gas Town:

Original 8-Stage Dev AI Evolution Chart (January)

At Level 8, you have mastered using an orchestrator to manage dozens of concurrent agents. As your experience grows, you begin to see the potential to use agent mini-factories everywhere.

After you deploy your first real one, you officially have a garden you’re tending. A tiny crew of agents, acting like employees. Your little factory team runs 24x7, which requires maintenance. You now have to keep it running, manage upgrades and patches, rotate the logs, and of course make sure it’s doing its job. But you don’t have to do the work yourself anymore! So it’s still a huge automation improvement… as long as you can keep it reliable.

You should almost never deploy a single-agent pack for a real business process. The reality is that any agent can go temporarily insane, at any time, and make a bad call. No matter how smart they are. We know now that hallucinations and false memories and forgetting are baked mathematically into all memory systems; there’s no avoiding it. So you should never just have one coding agent managing a piece of infrastructure. Not even for a low-stakes part of your business. You should always have at least two or three working together on a little crew.

This is exactly why dark factories are so attractive. With Gas City you can build any sort of adversarial group structure you like, for a team of collaborating agents. They can watch over each other. By catching each other’s mistakes, the agent group reaches a far more reliable consensus and outcomes than you can get from a single agent. That’s why we think of deployed orchestration as being fundamentally made of multi-agent teams: factories. Define your pack, deploy it, et voila — you are officially on the path to being an AI-native shop.

Orchestration-maxxing

Let’s look at what a specific small custom factory looks like in practice.

For my game’s player custom-image uploader, images are submitted via a website form, so it starts with an agent that wakes up on a hook and does the work. Then a second agent checks the first agent’s work. Perhaps the first agent makes a recommendation, and the second agent takes action.

I could add more agents to that pack, but I think two should be enough for this little workflow. It’s super low volume, low-stakes, not the end of the world if the agent crew messes up and approves a bad image. Adding that second agent, much like a second hash function, dramatically decreases the chance of some sort of collision. So in my pack, I declare the two agents, their identities, prompts, sandboxes, skills, and all the other stuff they need. Gas City can help you do this automatically, of course.

Two-agent pack handling Wyvern custom player image queue

A deployed Gas City pack is an AI-native business process automation. Once your pack is running, Gas City’s supervisor agent system will keep it going, even on remote machines.

At this point, with one deployment, you are officially at Level 9 on the AI Adoption Chart.

After you make your first one, you realize you want to use dark factories for everything. I want every damn NPC in my actual game to be an agent, yeah? Not first, obviously! I’ll have to build up to that gradually, just like you should, when you first start with AI factories. Pick low-stakes, easy wins, get them automated, and learn your lessons early on when getting burned isn’t so bad.

Level 10 of the AI Adoption is where you’ve deployed a bunch of agent packs, each with its own little world it’s managing. They have identities, consoles, you can check in on any of them, tweak their standing orders, you name it. They’re starting to be a handful. But you don’t need to build an orchestrator for them, since Gas City is the orchestrator. What exactly are you missing?

The problem is, in stage 10, you, the human, are the control plane. Once you have a few dozen of these deployed packs, you will start to become the bottleneck on curating them. Gas City manages them, and they’re all functioning correctly on their own, but how are they working together as an end-to-end system? They can all send messages to each other, but have you given them clear, practical guidance on when it’s appropriate to do so?

The answer to all your problems at Stage 10 is of course to slather on more Gas City. You build yet another crew, with a declarative Gas City pack, and its job is to manage a subset of your deployed packs. Maybe you spin up a couple of them, one for the cloud services, one for customer service. Area manager teams, basically. You evolve it into the shape of your problem.

Once you start building your way out of needing to hand-manage dozens of packs, you’ve officially graduated to Level 11, which is Factory Builder. You’re building a full custom orchestrator, a full dark factory, and you’re operating at the level of architect, curator, and shepherd.

The (currently) 11 Stages of AI Adoption

Your Gas City is the sum of those little factories you’ve created to run your business around the clock. No sick cats, no vets. Just the occasional wild worker hallucination. But your teams, if you build them right, will catch most mistakes. And all of it will be logged and auditable.

Reliability, friends, is a dial. You choose where to set it. More rounds of review, more backstops, more guardrails, more judges, and you can get agentic workers to be as reliable as you need them to be, at least up to some practical ceiling. I wouldn’t use it in situations where you could physically hurt people, e.g. in medical or navigation systems. Not in 2026. But we’ll build our way there, like engineers do, over the next couple of years.

That’s the new world. If you’re convinced already, then you’re done! You can just go play with Gas City. I’ll finish up by talking about how you can use Gas City to start chipping away at your SaaS problem.

Escape From SaaS Mountain

When I was a kid, my parents wouldn’t let me watch Escape From Witch Mountain (1975) for whatever dumb reason. Probably because it had “Witch” in the title and I was six. I’m still miffed about it, though. Who knows how much better-prepared I’d be for life if I’d watched it?

And now, I wonder, are investors and boardrooms watching Escape from SaaS Mountain? Or are their moms not letting them, too? Perhaps we’ll never know.

SaaS is in kind of a funny position right now. If you look at the pyramid from the top, at the SalesForces of the world, it looks like they’re fine, they just need to pivot to make their SaaS sexy to agents. Benioff did that recently with SF, exposing the whole platform headless and API-first, in exactly that: a bid to make SalesForce sexy to agents. That’s the new game for SaaS.

People look up there and say, oh it’s gonna be just fine, those are systems of record, nobody’s going to reimplement them. Nobody wants to pay the tax of maintaining those systems for security, compliance, performance, scalability, etc. Right? This is just the new Buy vs Build.

But then you look at the bottom of the SaaS pyramid and it’s like, oh crap, this stuff is disintegrating in real time. Just in this past month I was visiting an enterprise customer where the non-technical staff — non-technical! — have been rebuilding a $30k/year SaaS tool in-house on Gas Town. Their VP is now mapping out how to convert millions in annual SaaS spend into headcount, bringing those capabilities in-house as core competencies. The question they asked us was: how do we actually do this at scale?

From that perspective, it’s clear that some SaaS will be eaten, and the rest will have to pivot. The only question is how far up the pyramid people will be able to push, bringing it in-house. It’s going to take a few years to find out.

I’m going to share some stuff with you that will potentially change the way you think about SaaS forever. Much of it is credit to Brendan Hopper, Commonwealth Bank of Australia.

Atlassian, nominally, is an Australian company: a poster child for what the Aussies can accomplish when they put their mind to tech. But according to Brendan, it’s more complex than Australian versus American. Atlassian is staffed between the two continents, registered in Delaware, and traded on the NASDAQ — the ASX does not price tech companies as tech companies. About half their devs are U.S.-based, and they have strong incentives to have engineers in the U.S, such as tax code 174A. They serve pretty much all traffic out of the U.S.

For all practical purposes, and through no fault of their own, Atlassian is a U.S. company. Much love to Atlassian, but they have to be, because there is no other option. The center of gravity on the U.S. west coast is inescapable.

Every dollar of SaaS spent outside the U.S. has a portion extracted from a local economy and moved into California’s economy, which would now be the fourth largest economy in the world if it were a separate country. SaaS is moves money from the rest of the world into the U.S. And there’s no fighting it. If a big non-US tech company like Atlassian can’t, it’s going to be hard for everyone.

Another interesting thing about SaaS is that it grows to become the superset of all the features for all its customers. Most customers gradually recede to using 20% of the SaaS’s features, while subsidizing the remaining 80% for the other customers.

The implication is that you don’t need to reimplement all of SalesForce, just the parts you’re using. If you want to bring SaaS in-house, you only need to build the 20% of the features you need. And you also only need as much security, scaling, and compliance as is appropriate for your company, which is not necessarily the same as you need for a Fortune 100 company.

So SaaS is extractive, and expensive. Almost nobody is getting full value out of it, and all that value is streaming into Silicon Valley.

Yet another funny thing about SaaS is that the Venn diagram overlap with your own needs is always incomplete. Not only are you subsidizing features you won’t use, you’re also failing to get features that you would use. And when SaaS becomes dominant it stops innovating.

In short, SaaS began life as a way for everyone to get savings through specialization and economy of scale. And it has evolved into an extraction machine that’s ideal for almost nobody.

So you shouldn’t feel bad about de-SaaSing your company. Just start at the bottom.

The bottom of the SaaS pyramid is a rowdy place, a rough place. A lot of it isn’t even SaaS, it’s software on disks in a closet that someone is paying an annual license for. Construction, paralegal, medical, farming, biotech, environmental, there are hundreds of domains where ancient SaaS is still holding companies hostage, and not meeting people’s needs.

So the people are fighting back! As the models and tools get more powerful, people are beginning to bring their SaaS back in house. I hear VPs of Eng say, “We are spending $X million/year on SaaS. Let’s convert that to salaries and bring it in as a core competency.”

But until this week, there hasn’t been a viable path forward, aside from experimenting with building your own orchestration on raw coding agents. That is a long journey, and most people need help with it. Most of the orchestrator vendors out there are off building agent brains and persona libraries — interesting research projects, but not what you need to replace a piece of SaaS in production. To replace SaaS, you need the unglamorous stuff: declarative deploys, audit trails, version history, identity, and a memory layer that survives the inevitable agent failures. Those are the primitives that make in-housing tractable.

Enter Gas City: The ultimate de-SaaSer. It’s like de-lousing your company. It makes Build and Maintain a pragmatic choice, particularly at the bottom end of the pyramid. You build the replacement software, then set up agent teams to run it for you.

A small team of three to five human engineers running Gas City packs can credibly replace seven-figure SaaS bills, and the capability stays in-house as a compounding asset instead of leaking out as recurring rent. Yes, you own the uptime, security, and compliance now. But you only need the level of each that fits your company — not Salesforce-grade everything for a 200-person business. And Gas City’s audit trail, with every agent action recorded in a git-versioned Dolt database, is frankly better than what most SaaS vendors can produce when you ask for theirs. That’s your SOC2 story, sitting right there in the database, already written.

That’s the problem with OSS SaaS replacements today, and it’s why few have adopted them: they don’t run themselves. ChatWoot is a full-featured ZenDesk replacement, but you have to run it, and most companies can’t afford the operational overhead. SaaS has to evolve to be AI-native! It’s not good enough to be OSS. It has to have agents in it, running it, just like ZenDesk the SaaS handles everything for you as a service.

This implies that all SaaS worldwide needs to be rewritten/reenvisioned from the ground up to be fully agentic.

But where do you start?

That’s where Gas City gives you a refreshing leg up. You can start building bespoke Gas City orchestrators today. You’re not going to rewrite your business overnight. In fact it’s going to take years. You should approach the whole endeavor with appropriate levels of caution and even trepidation.

But you might as well start eating the elephant a bite at a time.

Next Up For Gaslandia

I had a set of projects in flight that were banking on at least Mythos-class models, which means they’re all on hold. Gas City will be the extent of my ambitions for a while. I plan to become a Gas City power user, not just for coding, but for running my own systems. I want to see that control plane emerge and understand how you can run a business with hundreds of collaborating agents.

Most other orchestrators I’ve seen have been able to be super high-ambition. Many lean heavily into the idea that agents, when put together, can just figure stuff out. And to a large extent, they can. But they are intentionally low-control systems. And when they fail, they go off-rails with no audit trail.

Gas City is a high-control system. It has high parallelism (Julian has had hundreds of concurrent workers in a city), but it uses structure to keep agent swarms organized. It’s still incredibly flexible and freeform when it needs to be; you can just tell a group of polecats to go solve any problem. But most work is spelled out, tracked, and governed carefully.

A key concept in MEOW is the formula — a reusable template for a unit of work. You write a formula once for a recurring workflow (triage an incident, review a player-uploaded image, rotate the logs, run the nightly ETL) and then pour it whenever you need that work done, instantiating a fresh molecule of beads that an agent crew can pick up and execute.

Over time, your library of formulas becomes a declarative inventory of every business process you’ve ever automated — version-controlled in Dolt, composable, and forkable by anyone on your team. That’s how Gas City turns undocumented workflow knowledge into a durable, shareable codebase.

When you express all your work in the MEOW stack, as Beads and Epics (typically harvested from an upstream system like Obsidian), and your agent actions are all recorded in both a database and version history, you wind up with infinitely more control over the outcomes.

In enterprises, controlling the outcomes is the holy grail. So I personally wouldn’t use any other orchestrator I’ve seen. They don’t have the federatable, versioned, queryable memory system that Dolt provides. They don’t have MEOW.

Everyone is suffering from tool overload. There are too many tools out there, and nobody can keep up with all of them. My life is so simple in comparison. I never look deeply at any new technology until it reaches a pretty loud public signal threshold. And I almost never have to, because the Gas Town ecosystem has solved so many of my problems.

The Gas Universe in general is a pretty reliable bet at this point. It integrates with everything. Beads has been out for six months, Gas Town for four months, and the Wasteland for two. And Dolt has been around for at least eight years, with enterprise-grade maturity. We’ve got over two thousand members on the Discord. The community has spoken: This is The Way. People love working with this system, despite its occasional quirks and frustrations. It’s more fun than anything else we know.

Should you switch from Gas Town to Gas City? Yes! Gas City aims to be better in every way. And Gas City hit 1.0 today, so you should be good to go. Make sure to complain loudly on the Discord if it’s not working for you! Help will be on the way.

Do you have to switch to Gas City? Nope, we have some new maintainers onboarding onto Gas Town this week to help with the load. We’re going to continue maintaining the O.G. Gas Town as long as people still need it.

See you all on the Discord at gastownhall.ai.

Model	Input ($/M)	Output ($/M)
DeepSeek V4 Flash	$0.14	$0.28
GPT-5.4 Nano	$0.20	$1.25
Gemini 3.1 Flash-Lite	$0.25	$1.50
Gemini 3 Flash Preview	$0.50	$3
GPT-5.4 Mini	$0.75	$4.50
Claude Haiku 4.5	$1	$5
DeepSeek V4 Pro	$1.74	$3.48
Gemini 3.1 Pro	$2	$12
GPT-5.4	$2.50	$15
Claude Sonnet 4.6	$3	$15
Claude Opus 4.7	$5	$25
GPT-5.5	$5	$30

Comments

Comments

Related Stories

Comments

Related Stories

Comments

Related Stories

Conscripting Africans

Terms of Service

Why Casinos Use So Much Power

The Price of Staying Open All Day

Greener Solutions Are Starting to Show Up

Solar Power and Renewable Energy

Water Efficiency Upgrades

The Rise of Online Casinos

Can Gaming Centers Really Go Green?

Comments

Related Stories

Comments

Comments

More than one kind of victory

The importance of deterrence

The OpenClaw backdoor

llm-openai-via-codex

And some pelicans

A few more notes on GPT-5.5

Spatial text parsing

Introducing LiteParse for the web

Building it with Claude Code and Opus 4.7

Is this even vibe coding any more?

Comments

Related Stories

Comments

Related Stories

The best single indicator: Oregon’s continued strong per capita income level

Looking ahead: the Oregon Economic Forecast

Reference

Downloads

March 18, 2026

References & Resources

You may also be interested in:

Discover More from NASA Earth Science

Subscribe to Earth Observatory Newsletters

Earth Observatory Image of the Day

Earth Science Data

Construction cost indexes

Output indexes

Input indexes

Construction task costs

International construction costs

Conclusion

Why Do You Need Data Recovery Software?

2026 Guide: Top 5 Free Data Recovery Software Picks

01: Stellar Data Recovery Free

02: EaseUS Data Recovery Wizard Free

03: Disk Drill Free

04: PhotoRec (with TestDisk)

05: Recuva

Conclusion