A way of running a company where a growing share of the work is done by AIs. It asks things of you; the software only makes them cheap.
For as long as producing was expensive, the scarce thing was the capacity to produce. That is over, and three problems take its place — in this order, in every company that puts AIs to work.
None of the three is a technical problem. All three are answered by what a team decides to demand of itself.
Every piece of work names the objective it serves. Work that names none does not start — and saying so out loud is your job, not a tool's.
What is not attached is never arbitrated. It gets done because someone asked, and nobody ever finds out whether it was worth doing.
Before any technical specification, someone writes the business brief: for whom, what changes for them, and by what measure you will know. Whoever carries the objective writes it — not whoever will build it.
A how written without a why gets built exactly as asked, and serves nothing. The one who asks is the only one who can say what would count as success.
The specification states what will prove it delivered — the pages to open, the figures to compare, the answer that means done — before the work begins.
An acceptance written afterwards is written to be passed. Written first, it is the definition of the job, and the person doing the work knows exactly when to stop.
At delivery, you name what will have to be re-checked and on what date. A delivery with no re-check date is not finished, it is abandoned.
Something that quietly stopped working does not announce itself. Without a date, you learn it from a customer — and by then it has been true for months.
A result moves by a dated statement carrying a figure and a confidence. « At risk » is an allowed answer, and an expected one.
A report that only ever says « on track » carries no information at all. The ritual is worth something only because bad news can be said inside it.
Whatever you expect from an agent exists in writing, where the objective lives — not in a conversation that closes. And the agent accounts for itself in the same place.
An instruction that lives in a chat dies with it. Written down, it outlives the session, the person, and the tool you used that week.
At the end of a piece of work, what was learnt becomes a rule that the next piece of work reads. Not a note in a retrospective document nobody reopens.
Teams do not forget lessons because they are careless. They forget them because the lesson was stored somewhere nobody passes by again.
Inside your workspace, a page states where your practices really are — from what an agent observed of your setup, never from a box someone ticked. A self-assessment is an opinion; that page does not display opinions.
It is the difference between what you commit to practising and what you actually practise, and only the second one is worth reading in a bad month.
Everything above is a discipline, not a feature. You can practise all of it without ever opening Galy, and some teams do.
What Galy does is hold the whole chain in one place — the objective, the brief, the specification, the proof, the re-check date — so that keeping it costs less than dropping it. That is the only thing a tool can do for a method: make it cheap enough to survive a busy month.