Notes from FOSE Europe

Giles Edwards-Alexander · article · 2026-07-07 source ↗ Reader 🖥️

Agent Harness Agentic Engineering Context Engineering Coordination Cost Learning Culture & Slack Optimiser vs Learner Organisations Platform Engineering Sociotechnical Architecture Software Design Fundamentals Taste & Judgment

Five months into the agentic era the value of agentic engineering is now settled ('the evidence is in'), so the live frontier of the debate has moved from the tools themselves to the socio-organisational questions they raise — how to design your organisation (Optimiser vs Learner), where engineering rigour and human judgement now live, and how to coordinate agentic work across teams and enterprises — none of which is yet resolved.

mixed · mixed — Reflective field notes from an unconference (the FOSE Europe retreat). Part narrative report of what shifted between two retreats, part expository framing of org-design options, and largely a set of deliberately unresolved open questions rather than settled prescriptions.

Structure

Part	Role
Framing: two retreats, Chatham House Rule, first rough thoughts	Establishes the vantage point (host of FOSE Europe at Engelberg, sequel to Deer Valley) and the tentative, in-transit status of the reflections
A real shift in five months	Contrasts Deer Valley's hesitancy with Engelberg's confidence and argues attention has broadened from tools to cross-team/enterprise and the social side of the socio-technical system
What kind of organisation is right for you? (Optimiser vs Learner)	Presents two org-design archetypes as real options distinguished by who owns the inbound work stream
Has engineering rigour found a new home yet?	Surveys candidate homes for rigour (tests, BDD, linting, formal models, agent-extracted rigour) and the expertise-vs-judgement limit; questions whether domain modeling will finally work
What still feels unresolved?	Lists open questions (harness engineering teams, the DevOps-movement analogue, persistent vs regenerated code) while affirming the value is here

Key terms

Optimiser vs Learner
Two organisation-design archetypes for the agentic era: the Optimiser, where engineers pull automatically-queued work (from agent-synthesized feedback or monitoring) and agents change any part of the enterprise; and the Learner, where product/technical pairs situate with users and curate a highly filtered stream of work — differing only in who owns the inbound work stream
grey goo (software equivalent)
The failure mode of the Optimiser: unbounded, undirected agentic change proliferating across the enterprise, mitigable by a continuously evolving central shared harness of architecture guidance and engineering rigour
engineering rigour
The disciplined verification of correctness whose 'home' is being renegotiated — located variously in tests, BDD, linting, and formal models, and increasingly extracted via agents (e.g. getting Claude to write TLA+ and verify the program)
'higherings'
The author's coined term for higher-order applications of agents — using an agent to perform meta-level rigour work, such as reviewing your harness after each new model drop rather than doing it manually
harness engineering teams
Emerging teams dedicated to building the shared scaffolding of tools/agents; the author suspects this repeats the DevOps-team mistake and that the friction of each team building its own harness is generative
judgement (vs expertise)
The human faculty agents cannot supply — while agents can bring all the expertise, they cannot bring judgement; what exactly this means is left open

Propositions

explicitIn just five months, the prevailing sentiment about agentic engineering shifted from Deer Valley's hesitant belief that 'there was something here even if we weren't yet sure what it was' to Engelberg's confidence that the value is here.conf: high
explicitAgentic engineering demonstrably works and is here to stay; its value is no longer in question.conf: high
explicitAlthough the value is established, what the evidence actually says — which patterns and practices are effective, and when — remains unclear and still emerging.conf: high
explicitAs practitioners gain experience, the central open questions have shifted from the tools themselves toward the social side of the socio-technical system — coordination between teams and across companies.conf: high
explicitUncoordinated agentic work across teams risks duplication — one team building a pricing engine while another builds a pricing service — raising the question of whether an enterprise-wide shared context layer is possible or even desirable.conf: medium
explicitOrganisations face a real design choice between two archetypes — an Optimiser and a Learner — that differ only in who owns the stream of inbound work: data and measurement, or conspicuously humanist curation.conf: high
explicitThe Optimiser model risks a software equivalent of 'grey goo' — unbounded agentic change — which can be mitigated by a continuously evolving central, shared harness of architecture guidance and engineering rigour.conf: medium
explicitIn the agentic era, learning — not engineering delivery — has become the binding constraint.conf: high
explicitEngineering rigour is being relocated into a variety of places — tests, BDD, linting, and formal models — including using agents to extract or perform that rigour, though whether agent-extracted rigour is truly rigorous is itself in question.conf: high
explicitAgents can bring all the expertise, but they cannot bring judgement.conf: high
explicitDomain modeling is repeatedly proposed as the mechanism to steer agents and scale teams, but it is not a new idea, and its past failure to become the standard way to model teams across an org casts doubt on why it would suddenly succeed now.conf: medium
explicitHarness engineering teams are already emerging, but dedicating separate teams to harnesses likely repeats the DevOps-team mistake, because the friction of each team building its own harness is generative and creative rather than pure waste.conf: medium
supportsAgent Harness Engineering · p9 — The claim that the friction of each team building its own harness is generative — and that dedicated harness teams are a mistake — supports the idea that the right harness is shaped by local failure history and cannot be downloaded as a generic package.
implicitThe maturation of agentic engineering is recapitulating the trajectory of earlier movements such as DevOps and domain-driven design — value gets demonstrated, then organisations risk mishandling it by creating specialist silos and reaching for old modeling tools.conf: medium
explicitWhether the technical system / code is a persistent artifact or is continuously discarded and re-generated remains a foundational unresolved question carried over from the first retreat.conf: medium

Arguments

The debate over whether agentic engineering delivers value is effectively settled, so the frontier has moved to socio-organisational questions. strength: medium

Explicit premises:

Between Deer Valley (January) and Engelberg (July) the mood moved from hesitancy to confidence: 'the evidence is in.'
With more experience, participants stopped asking about the tools and started asking how success plays out between teams and across companies.
The discussion returned again and again to the social side of the socio-technical system.

Implicit premises:

The sentiment of an experienced, self-selected group of practitioners is a reasonable proxy for the state of the field.
Once value is demonstrated, the binding problems become organisational rather than technical.

Inferences:

Therefore the important open work is now about organisation design, rigour, judgement, and cross-team coordination — not about the tools.

The right organisation for the agentic era depends on which is your true constraint, and since learning (not delivery) is now the constraint, the Learner design has the stronger claim despite moving more slowly. strength: medium

Explicit premises:

Agents and harnesses now make engineering delivery fast and cheap.
The Learner moves more slowly but 'learning is the constraint now, not engineering delivery.'
The Optimiser risks a software 'grey goo' of undirected change.

Implicit premises:

Optimising a system for something other than its binding constraint yields little net gain.
Humanist curation of inbound work is what actually accelerates learning.

Inferences:

Therefore an organisation should choose its design by identifying its real constraint, and for most that constraint is now learning.

Dedicated harness engineering teams are the wrong response to the rise of agentic engineering. strength: low

Explicit premises:

Harness engineering teams are already emerging.
DevOps teams were a misunderstanding of DevOps-the-movement.
The friction of every team creating its own harness is generative and creative, with value for the teams.

Implicit premises:

The DevOps-team analogy transfers to harness engineering.
Capabilities that are a movement rather than a function are degraded when siloed into a specialist team.

Inferences:

Therefore harness work should stay distributed across teams rather than concentrated in a dedicated team.

Narratives

The contrast between two retreats five months apart: Deer Valley, Utah (January 2026), hesitant and unsure what it had found, versus FOSE Europe at Engelberg, Switzerland (this last weekend), confident that the value is here — 'not a conference for true believers: the evidence is in.'
→ Frames the whole piece and grounds the claim that a real shift has happened in only five months
The author's own circular use of formal methods: not smart enough to write TLA+, he gets Claude to write it, then feeds that back in as input to design work and to verify the program — and asks whether that is actually rigorous.
→ Makes concrete the question of whether agent-extracted rigour is real rigour
Sam Ruby's account that his belief in using agents to extract rigour 'survived contact' with the retreat, because whole-program type inference works via the agent's semantic understanding of the Rails app.
→ Offers an external, named data point that agent-extracted rigour can hold up in practice
The scenario of one team building a pricing engine while another separately builds a pricing service.
→ Illustrates the cross-team coordination and duplication problem that motivates the enterprise-context-layer question

Questions addressed

✅ Has the value of agentic engineering been established?
Yes — the evidence is in, the value is clearly here, and it is here to stay.
⭕ What kind of organisation is right for the agentic era?
Two archetypes are offered as real options — Optimiser and Learner, distinguished by who owns the inbound work stream — but the author prescribes neither.
⭕ Has engineering rigour found a new home in the agentic era?
Rigour is being located across tests, BDD, linting, formal models, and agent-extracted methods, but whether it has truly found a home — and whether agent-extracted rigour counts as rigour — is left open.
⭕ Will we see harness engineering teams, and what is the agentic-era equivalent of the DevOps movement?
Harness engineering teams are emerging but the author suspects they are a mistake; whether the 'DevOps movement equivalent' question even makes sense is left unanswered.
⭕ Is the technical system / code persistent, or discarded and continuously re-generated?
Unresolved — carried over as an open question from the first retreat.

Gaps

uninformedThe central claim that 'the evidence is in' is asserted but the evidence itself is never presented — no measured outcomes, no specification of which patterns are effective or when. The Chatham House Rule and first-24-hours caveat partly explain this, but it leaves the confidence claim empirically ungrounded within the piece.
Read next: Seek empirical or DORA-style measurement studies of agentic-engineering outcomes, and the catalogued agentic-engineering pattern libraries the author mentions.
incompleteThe Optimiser-vs-Learner distinction is reduced to a single axis — who owns the inbound work stream — yet the two designs also differ in team structure, risk profile (grey goo), and speed. Reducing them to one variable may oversimplify a genuinely multidimensional operating-model choice.
Read next: Read on operating models and team design (e.g. Team Topologies) to test whether the single-axis framing holds.
incompleteThe claim that agents 'can bring all the expertise' but 'can't bring judgement' is asserted without defining judgement or explaining why it is non-transferable, and it sits in unexamined tension with the author's own reliance on agents to extract engineering rigour.
Read next: Read on the distinction between taste/judgement and expertise in AI-augmented work, and on where human judgement remains load-bearing.
incompleteThe domain-modeling skepticism ('why would DDD work now when it never became standard before?') is raised sharply but never answered, leaving the proposed core mechanism for steering agents and scaling teams unresolved.
Read next: Read on domain-driven design applied to agent steering and on enterprise context/knowledge layers to see what, if anything, is different this time.
illogicalThe harness-engineering-teams argument rests entirely on the DevOps-team analogy, asserted because it 'feels wrong' in the same way; the parallel is never established, so the conclusion inherits whatever weakness is in the unexamined analogy.
Read next: Read critiques distinguishing DevOps-the-movement from DevOps-the-team and test whether the same structure applies to harness engineering.

Notes from FOSE Europe

Structure

Key terms

Propositions

Arguments

Narratives

Questions addressed

Gaps

Related documents