Working with AI
As Above, So Below: Why Your Automations Copy Your Organisation
Your automations will copy the way your business already talks to itself. An alchemical text said as much a thousand years before anyone built a Zap.
14 Oct 2026 · 6 min read · By Sophie Kazandjian
The Emerald Tablet is a dozen or so lines long, and alchemists treated it as the founding document of their art. Legend credits it to Hermes Trismegistus, a mythical Egyptian sage, and says it was found carved on a slab of emerald. The oldest surviving versions are in Arabic. Latin translations reached Europe in the twelfth century, and by the Renaissance the text sat at the centre of the Hermetic revival.
Isaac Newton made his own English version around 1690. It survives in his hand at King's College, Cambridge, and its second line reads: "That which is below is like that which is above & that which is above is like that which is below to do the miracles of one only thing."
Later occultists cut it to four words. As above, so below. Read the Hermetic way, the line is about correspondence: the small world repeats the pattern of the large one, so what you see on one level tells you about the other, and if you want to change the pattern below you work on the pattern above. Of everything in that tradition it has had the most practical afterlife, because a computer scientist arrived at the same idea in 1968 and business has been stuck with it ever since.
The law nobody could shake off
Melvin Conway sent a paper called "How Do Committees Invent?" to the Harvard Business Review in 1967. The editors turned it down because he hadn't proved his thesis, and Datamation, a computing magazine, published it in April 1968. Any organisation that designs a system, he argued, will produce one whose structure is "a copy of the organization's communication structure." Fred Brooks named the idea Conway's Law in The Mythical Man-Month, and the name stuck.
His own example is small enough to remember. A contract research firm had eight people to write two compilers, one for COBOL and one for ALGOL. Five went to COBOL, three to ALGOL. The COBOL compiler ran in five phases and the ALGOL compiler in three. Nobody chose those numbers; the staffing did.
The paper's second conclusion is quoted far less. First designs are almost never the best ones, so an organisation has to stay loose enough to change shape when the design asks for it. A structure that cannot move goes on producing the same system.
Forty years of evidence
Conway had anecdotes. The data took another forty years. In 2012 Alan MacCormack, John Rusnak and Carliss Baldwin compared matched pairs of software products that did the same job, one built by a tightly knit commercial firm and one by a loosely coupled open-source community. In every pair, the product from the looser organisation was significantly more modular.
A study inside Microsoft went further. Nachiappan Nagappan, Brendan Murphy and Victor Basili measured the organisation behind each part of Windows Vista: how many engineers touched a component, how far the decision-makers sat from the work, how scattered ownership was. Those measures picked out failure-prone components better than the usual code metrics, churn and complexity and test coverage among them. When another team repeated the study on large enterprise software in 2015, the organisational measures still beat churn but lost to counts of bugs found before release. How strong the effect is varies with the setting. It keeps turning up regardless.
If you want to know where your systems will break, then, look at how your people talk to each other before you look at the tools.
What automation does to the mirror
In a small business the communication structure is rarely drawn anywhere. It lives in who emails whom, and in the spreadsheet only one person understands. While it stays in people's heads it stays soft: someone notices the odd step, works round it, and the work bends.
Automation sets it hard. Put a workflow on top of an unclear process and the confusion is written into software, where it runs by itself with nobody watching. Michael Hammer made the case in the Harvard Business Review in 1990, in "Reengineering Work: Don't Automate, Obliterate". Companies were using computers to speed up old ways of working, he wrote, and it was time to stop paving the cow paths. Reengineering became a byword for redundancies over the following decade, which is a fair mark against how it was used. His diagnosis held up better than the remedy.
In Hermetic terms an automation is a correspondence made permanent. What was above is now fixed below, and the thing below starts to train the thing above. A workflow that copies every enquiry to three people teaches all three that nobody in particular owns enquiries.
Faster mirrors
AI speeds the whole thing up. A workflow that once took a developer a fortnight can be described to an assistant in the morning and running after lunch, so a structure can be set in software before anyone has looked at it properly. Cheap building ought to make change cheap as well, and occasionally it does. Mostly, things that work get left alone.
Agents add something less obvious. An agent is built from your instructions and your documents, so it reflects how clearly you have thought about the work, and a business that has never decided who approves what will get an agent that doesn't know either. Briefing AI well is mostly a matter of having made the decisions first. Every prompt is a small org chart.
People tend to skip the other half of the Tablet's line. Below is like above, and above is like below; the correspondence runs both ways. If the systems copy the organisation, you can read the organisation off its systems. An automation that keeps breaking, or an agent that asks the same question every week, is reporting on a conversation that isn't happening upstairs.
Working above before below
Newton's translation has a line that could hang over every automation project: "Separate thou the earth from the fire, the subtle from the gross sweetly with great industry." Alchemists meant the refining of a substance. In operations it is the step most people skip, sorting judgement from routine before deciding what a machine should do.
Start above. Before you open a tool, write one page on who decides what and where work waits for someone. In a one-person business the people are your roles, the version of you who sells and the version who does the books, and the handoffs between them are as real as any between colleagues. Wherever that page is hard to write, you have found the real design work.
The gross is whatever is the same every time: the invoice going out, the reminder on day three, the record copied across. Judgement is the subtle part, whether to take on a client or how to answer a complaint. Automate the gross and leave the subtle with a person. Most of the care belongs at the handover, the point where a routine step has to recognise it has reached something it shouldn't decide.
Automate only what has settled. A process that changed twice last quarter is still being composed, and it should run by hand until it stops moving.
When something you built keeps failing, read below to see above, and ask what conversation it is standing in for before you fix the code. Software teams have a name for reshaping an organisation on purpose to get the system they want: the inverse Conway manoeuvre. In a small business it usually means making the one decision you have been putting off.
One only thing
Newton's line ends on a phrase that is easy to pass over: above and below correspond "to do the miracles of one only thing." For many alchemists the work at the furnace and the work on themselves were a single operation. Heinrich Khunrath's best-known engraving, from the Amphitheatrum Sapientiae Aeternae of 1609, puts both in one room, a figure kneeling at a prayer tent on one side and the laboratory furnace on the other.
Operations work has the same unity, whether anyone wants it or not. A business cannot automate its way into clarity it doesn't have, because the systems will copy whatever is above them, faithfully and fast. For some businesses that is the best news in this essay.
Sources
- Isaac Newton's translation of the Tabula Smaragdina, Keynes MS 28, The Newton Project
- The Emerald Tablet of Hermes Trismegistus, Cabinet, University of Oxford
- How Do Committees Invent?, Melvin Conway, Datamation, 1968
- Conway's Law, in Making Software (O'Reilly)
- Exploring the duality between product and organizational architectures, MacCormack, Rusnak and Baldwin, Research Policy, 2012
- The Influence of Organizational Structure on Software Quality, Nagappan, Murphy and Basili, ICSE 2008
- Merits of organizational metrics in defect prediction: an industrial replication, Caglayan et al., ICSE 2015
- Reengineering Work: Don't Automate, Obliterate, Michael Hammer, Harvard Business Review, 1990
- The Alchemist's Laboratory, from Khunrath's Amphitheatrum Sapientiae Aeternae, The Metropolitan Museum of Art