DIALOGUE PRODUCES DECISIONS · DECISIONS PRODUCE STRUCTURE · STRUCTURE PERSISTS
Koòrdinated Thinking: a proposed method for working on a complex problem with a language model without the reasoning dissolving into the flow of the conversation. This document sets out its principles, its limits, and the rationale that supports it.
Working on a complex problem with a large language model almost always produces the same outcome: a conversation that is long, rich, and unrecoverable.
Decisions are made in the middle of the dialogue, motivated by an exchange that no one can reconstruct a few hours later. At the next prompt the model does not remember why a certain path was discarded; nor does the human operator. What remains is the code — or the draft, or the architecture — without the reasoning that produced it. When the work has to be taken up again, it is re-argued from scratch, and it is not rare for the second decision to contradict the first without anyone noticing.
Software came to know this problem before the arrival of generative models, and offers its sharpest illustration: code shows what was built, never why it was built that way. But the phenomenon is not peculiar to software — it belongs to any work in which the finished product does not carry with it the reasons that produced it, from the text of a contract to the plan of a project. With AI the problem worsens everywhere, because the speed of production increases and with it the quantity of implicit choices that slip away in the flow of the dialogue. One obtains a great deal of output, and no durable source of truth.
There is a second aspect of the problem, less obvious and more insidious. Working on a complex problem with a language model tends to amplify the competence — and the lack of it — of whoever leads the dialogue. The model goes along with its interlocutor: it rarely adds a competence the interlocutor does not possess, because without that competence the interlocutor does not know where to steer it, what questions to ask, or how to recognise a wrong answer when it arrives. The interaction thus works almost as an echo chamber for the abilities of whoever conducts it. It is an effect that research argues for complex tasks, and that finds confirmation in the practice of working with AI in real teams: the very deference of the model to user feedback amplifies competence in those who have it and mistaken beliefs in those who lack it; the expert uses each cycle of refinement to improve quality, while whoever lacks competence steers the model, without realising it, toward a mediocrity that is ever more sure of itself. The model's speed does not close the competence gap: it can widen it.
This document describes a way of working that addresses the problem at its root, and explains why. It introduces no new terminology where established terms already exist: the method sits at the intersection of known practices — the specification as source of truth, the decision log, the document as an instrument of thought — and adds to them the dimension of digital interlocutors, distinct by role and by architecture, used to multiply the points of view on a single problem.
To this composition — and to this alone, so as not to multiply names where existing ones suffice — the document assigns a term of its own: Koòrdinated Thinking. The name is deliberate. It ties the method to the tool that embodies it (Koòrd) and declares its nature: not a new technique, but the coordination of four dimensions that, taken singly, are already common property, and that remain disconnected until something holds them together. All the rest of this document's vocabulary is borrowed, by choice, from the disciplines that ground it.
The method's first principle is that the primary artefact of the work is not the finished product, but a specification document. The product — a program, a document, a plan, a strategic decision — is a derived artefact: generated or verified from the specification, not the other way around. In this document's examples the derived product in mind is predominantly software code, because that is the domain the experience comes from; but the principle is general in those areas where an artefact is built from an intent.
In software this principle has an established name — spec-driven development: the specification is the source of truth, the code is what follows from it. But the reason the idea, in itself not new, has become topical again holds beyond code. When a model generates an artefact from instructions scattered across a conversation, every ambiguity left unresolved upstream re-emerges downstream — in the form of a product that works but does not do the right thing, of rewrites, of divergence between what was intended and what was produced. It holds for a program as for a report, a policy, a plan. Fixing the intent explicitly, before producing, reduces this cost: the software literature calls it the "ambiguity tax", but the effect is observable across various fields.
In the method described here the specification is a plain-text document, versioned, that grows through successive iterations. While it is being drafted, one property is non-negotiable: additivity. A new version does not delete the content of the previous one; it integrates it. This constraint guards against a typical and insidious failure mode — the silent loss of content between two revisions, where a detail decided weeks earlier disappears without anyone choosing to remove it.
A specification also declares its own scope: the general aim that frames it and the objectives, stated as atomic, verifiable elements. This is not formalism. A language model, left without explicit boundaries, tends to overdo — to add structure, cases, generalisations no one asked for, in the direction of what looks complete rather than what is needed. It is the machine's own version of a tendency project management has long known under the names gold plating (adding unrequested merits) and over-engineering: symptoms paid for in time, cost and complexity, which the management disciplines cite as a recurring cause of delays and of resources spent on features no one will use. The declared scope is the boundary against which this tendency is measured; it is also what makes it possible for the competent human operator to recognise the overdoing and correct it, because it provides the yardstick — was this in the scope? was this objective declared?
Alongside this boundary stands an explicit criterion: good enough. The good-enough discipline, formalised by Herbert Simon as satisficing, holds that under real constraints of time and information the rational choice is not the best in absolute terms but the first that clears a declared threshold of adequacy. In business management it is a recognised principle: releasing a "good enough" product allows entering the market sooner, and the pursuit of perfection is documented as a cause of missed opportunities. The method adopts this criterion as a design constraint: complexity is to be justified case by case, and "good enough" is a legitimate decision, not a compromise on the cheap.
One qualification applies, and it is also the method's point of flexibility: good-enough is not universally superior to optimisation — there are contexts, and the literature documents them, in which pushing toward the maximum pays. The method adopts it as a default because the failure mode it must correct is the excess, not the shortfall, of structure; but the behaviour remains configurable. Scope is where one declares where to set the bar: "good enough" stops the search at the first valid result; raising it on a critical dimension — asking not for an acceptable solution but for the best attainable on that axis — commits all the actors to a more demanding criterion, with the costs that follow. One can change the height of the threshold, not the fact that a threshold, under the constraint of time and resources, is always there. The method does not impose a particular criterion; it requires that the criterion, whatever it is, be declared and explicit.
A specification could be written entirely up front, alone, and then handed to the model to execute. The method does something else: it builds the specification in dialogue with the model, through iterations.
Once an aim has been clarified, at each step the model returns a small set of consolidation questions oriented toward reaching the objectives, each with a reasoned recommendation. The human operator then answers on that basis, frequently in a concise way, at times elaborating on the proposals. Once a satisfactory stage is reached, the specification is updated.
Iteration, however, generates more than it closes, and here lies the second aspect of the same process. Some steps of the reasoning bring up questions that are not yet decidable — because they depend on an upstream choice not yet made, because they require information that is missing, or simply because it is not the moment to settle them. The method neither forces them to a premature answer nor lets them drop: it records them as open points, explicit and tracked entries in the document alongside the closed decisions. Iterating the reasoning and noting the open questions the iteration produces are not two separate activities: they are the same movement. One advances where the path is clear, writes down what remains open, and returns to it when a later decision makes it resolvable.
The discipline governing an open point is simple: do not block work on the rest. This avoids the failure mode opposite to haste — the indefinite wait for an answer before proceeding — which in work with AI is particularly costly: suspending work while waiting for an answer, only to proceed anyway when it does not arrive, combines the drawbacks of both options with the benefits of neither. Tracking the open point, instead, lets one proceed without feigning a certainty that is not there, and without forgetting the question. For this reason open points are not a flaw of the document but a function of it, and at the same time an indicator of its adequacy: an old rule of design documents says that if the part devoted to the consequences of a choice is shorter than the choice itself, one has probably not finished thinking. The register of open points is where this incompleteness is declared rather than hidden.
This form is not a procedural affectation. It has a documented cognitive function. Research on "cognitive forcing functions" in AI-assisted work suggests that obliging the worker to engage explicitly with the plan — instead of scrolling straight to the result — leads them to examine steps they would otherwise have skipped and to reconsider what the plan took for granted. The question–answer–consolidation cycle is exactly a forcing function of this kind: it prevents the operator from passively accepting the output and shifts attention onto the reasoning.
There is a second, simpler reason. Writing forces thinking. Those with long familiarity with design documents put it this way: the act of writing a specification adds rigour to what otherwise remains vague intuition, and reveals the gaps in the underlying reasoning. The dialogue with the model accelerates this revelation, because the consolidation questions expose the ambiguities while they are still cheap to resolve.
Every substantive choice made during the iterative process enters the specification as a numbered decision: a stable identifier, the statement of the choice, and its rationale. Decisions can be cited by number, in later conversations and in linked documents, without reopening the discussion.
It is the practice software knows as architecture decision records, in use for over a decade in organisations of every scale; but recording decisions with their rationale is not specific to software — it is what every minute of resolution, every note of direction, every project log attempts to do. The value lies not in recording the choice, but in recording its why and the trade-offs accepted. A decision without a rationale loses value over time: whoever encounters it months later has only two options, to accept it blindly or overturn it blindly, both dangerous if the context has changed in the meantime. The number serves precisely to close discussions already closed — "it has already been decided, see decision such-and-such" — and to make visible, to anyone arriving later, the reason for what they see. This holds equally for a human team, where the log prevents re-litigating what had already been settled, and for a large language model.
There is in fact a second beneficiary of the log, besides whoever will read it in future: the large language model itself, during the work. Re-presenting at each step the decisions already made together with their rationale enriches the model's context and guides its reasoning, keeping it away from a well-documented failure mode in iterative work with a model — state revisitation: the model returns to solutions already explored and discarded without recognising the cycle, re-proposing them with minimal shifts and no real progress. The known cause is the lack of a structured memory of what has already been traversed: the model detects repetition only among recent steps and neglects the more distant ones, and the phenomenon is not merely lexical but semantic — the same conceptual territory re-crossed with different words. An explicit decision log, kept in context, is precisely the memory of already-visited states that the model lacks during the dialogue: it makes present and citable what has already been decided and discarded, and replaces an implicit, volatile trace with an explicit, persistent one. It is the same service the log renders to the human team — not re-deliberating what is closed — offered here to the machine.
The log is not immutable in the strict sense of the term. The method adopts the "living document" variant: a superseded decision is not deleted, it is updated in a tracked way, so that the history remains legible. Revising a choice in the light of new information is the health of the drafting process, not a failure to be hidden.
The specification carries with it a few further anchors, minor in form but functional in substance. The first is a glossary: the explicit fixing of the meaning of terms in the context of the work. A language model, faced with a word that admits several legitimate senses, tends to slide among them from one step to the next — using "actor", "log" or "session" now in one sense now in another, all admissible in the abstract but not all correct in context. The literature recognises this sliding as semantic drift and points to a cause: in the absence of an explicit anchor, the model infers the sense of terms from statistical co-occurrence patterns rather than from an authoritative definition. Declaring once that, here, a term means this and not that removes the ambiguity at the root and binds all the actors — humans and models — to the same vocabulary.
The second anchor is a register of references: the links to external sources, materials and documents, fixed in the specification once retrieved. It serves a practical and recurring problem: what the model found once does not remain available at the next step, and without an explicit anchor it would be searched for again from scratch — with the cost, and the risk of different outcomes, of every fresh retrieval. Recording the source in the document makes it a fixed point, citable and findable, instead of a retrieval to be repeated. It is the same principle research calls provenance: every claim traces back to the source it comes from, so that it can be verified rather than guessed anew. These two anchors, together with the pragmatic evidence from which the method derived them, find confirmation in a literature that documents the domain glossary and the register of sources as effective correctives of real model drifts.
A third anchor concerns not what the specification says, but how it changes: the tracking of changes between versions. The document records not only the current state, but what changed from one version to the next and why. It is the natural extension of the living-document principle: as the decision retains its own rationale, so the specification retains the history of its own transformations. And it answers the same tendency of the model to return unwittingly over its own steps — a tracked change is a change that will not be undone without anyone noticing.
Glossary, references and tracking complete a picture that, at this point, has a recognisable shape. Objectives and scope, open points, decisions, glossary, sources, version history: these are all artefacts with a kindred purpose — to remember — but of a different nature from the implicit memory of a model or a person. They are an explicit functional memory: written, versioned, and above all legible and verifiable by humans and by the language models that operate on them alike. Where a model's memory is volatile and opaque, and a person's is limited and private, these artefacts are persistent, shared and inspectable. The method, in the end, does nothing but deliberately build this common memory, one artefact at a time.
An additive specification has a flip side: it grows. Version after version, decisions, open points, glossary, references and change history accumulate, and a document that loses nothing becomes, over time, voluminous. If the whole document must be held in the model's context at every step, its very completeness risks working against the reasoning — saturating attention with material that, at that moment, is not needed. The method addresses this tension with two devices.
The first device is distillation: the production, on demand, of a condensed version that presents the current state of the work as a legible specification, cleared of the chronicle of the process — the previous versions and the alternatives weighed and discarded. What remains is the current state with its reasoned decisions, the glossary, the constraints and the sources, as functional memory in the form the executor can apply. It does not replace the complete document — it stands alongside it, for the uses in which one needs the snapshot of the present and not the path that led there. It is the instrument of the application phase: whoever realises the product works on the current state, not on the history of how it matured. To distil is to choose deliberately not to saturate the context when the complete history is not necessary, while keeping the source document intact — with all its tracked history — for when it is.
When distillation omits something that would have been useful, and how much that weighs against working on the complete document, is a difficult judgement: it falls to the expert operator, and is still to be investigated in depth. In the practical use of the method for software development it has proven reasonably reliable: the cases in which the synthesis would have induced errors have for the most part proven recognisable in advance, and a well-formed specification in this field mitigates the problem at the root — the snapshot of the present is self-supporting because it rests on known foundations that need not be reformulated every time. It is the same principle by which, in technical domains, best practices, patterns and consolidated solutions to recurring problems emerge.
The second device acts on the same tension from another direction: partitioning into sub-specifications. A main specification that grows beyond a certain threshold is split into thematic sub-specifications — the interface design, the server-side design, the operational details of what is already in production — each coherent within itself and linked to the main one. Partitioning keeps each document within a size in which it stays legible, and each working context focused on its own theme, without whoever works on one aspect having to carry the weight of all the others. It is the same logic as distillation applied to space rather than time: showing, each time, only what is needed.
These devices have a consequence that goes beyond legibility, and touches cost. A wide specification held entirely in context is what most readily puts a model with a narrow window into difficulty — typically a local model, run on one's own hardware. Distillation and partitioning reduce what one needs to have before one's eyes at a given moment, and with it the load on the context; and since, as we have seen, a well-made specification turns the downstream work into a structured task, that task becomes within the reach of a model of modest size. Here the limit turns once again into a boon: minimising the portion of work that requires large, costly models in production, and entrusting to local models — cheap, runnable in-house, respectful of the data — the clear, well-specified tasks the method produces. The same discipline that risks saturating the context is the one that, once managed, makes it sustainable to work with small models where before the large ones were needed.
So far the method describes work between a human operator and a model. The dimension that remains concerns how many interlocutors, and of what kind. The method acts on two distinct levels, which address two different problems and are not to be confused.
A complex problem has more than one legitimate point of view. Whoever works alone, or in a group lacking specific competences, tends to examine it from a single perspective — the one that comes most naturally. It is the risk the decision sciences have known for half a century under the name of groupthink, and whose historical antidote is cognitive diversity: the deliberate presence of differing perspectives, reasoning styles and roles. The classic instruments are the devil's advocate — someone charged with contesting the prevailing position — and dialectical inquiry, where distinct teams generate and evaluate opposing alternatives. The underlying motivation is explicit in the literature: one resorts to collective decision precisely because real problems, complex and ambiguous, are very hard for a single individual to solve.
The method's first level gives the digital interlocutors distinct personalities — differing roles, competences, attitudes — so that the lone operator, or the incomplete team, has at its disposal a table of perspectives it would not otherwise have. One interlocutor that scrutinises the details, one that checks the facts, one that plans, one that contests. It is the transposition of the classic antidotes: perspectives assigned deliberately to counter the flattening onto a single point of view. This level thus fills the role gaps: the perspectives missing from the table.
The second level addresses a deeper, and different, problem. A single language model, however many personalities it is assigned, carries with it its own biases, its own blind spots, its own tendency to crystallise the reasoning along the tracks learned in training. Changing the mask does not change the underlying mind.
For this reason the method employs, when the stakes justify it — typically in the review phases — models of different vendors and architectures on the same problem. The reason is documented: different models, even trained on similar data, show distinct strengths, biases and failure modes. A group of interlocutors built on the same model stays correlated to that model's priors — it is an echo chamber; putting heterogeneous models at the table introduces complementary inductive biases and brings out hypotheses and objections that a single model, alone, would not produce. The first level multiplies the roles; the second breaks the idiosyncratic crystallisation of the single model. Both answer the effect described at the outset: if the dialogue with a model amplifies the perspective of whoever conducts it, putting more interlocutors at the table — by role and by architecture — is the structural corrective, because it introduces perspectives the operator, alone, would not know how to solicit.
On both levels the method is deliberately explicit, because the literature requires it. Neither the personalities nor the diversity of models guarantee, on their own, a better result.
The practical consequence is that neither the personalities nor the models are an ornament: they are objects of design, whose value is measured by the diversity of the reasoning they produce. This is why the method separates cleanly the role of the human operator — who decides — from that of the digital interlocutors, which propose, contest and verify: the decision remains an explicit human act, informed by a range of positions wider than a single point of view, or a single model, could sustain.
At the base of the method stand, then, four principles — the specification as source of truth, the reasoned and tracked decision, the iterative dialogue that opens and records its own open questions, the multiplicity of interlocutors; one then considers scope and the good-enough criterion, glossary and references as attributes that make them operative effectively. None of these is independent: they work because they reinforce one another, as the experience accumulated in their use suggests.
The specification as source of truth gives the dialogue a place to settle: without it, the dialogue evaporates. The numbered decisions give the specification a memory structure: without them, the specification is a text re-read from scratch every time. The open points give the process a way to proceed without lying about its own incompleteness: without them, one either stalls or feigns a certainty that is not there. The distinct interlocutors give the reasoning a range of perspectives: without them, the quality of thought is limited to that of a single point of view.
Each of these pillars comes from a consolidated practice, born for work among human beings. What the method adds is their recontextualisation in human–AI work, where each acts on two fronts at once: it disciplines a failure mode proper to the model and, in the same gesture, structures the reasoning of whoever guides it.
| Pillar | Origin | Gain on the human side | Model failure mode it answers |
|---|---|---|---|
| Specification as source of truth | spec-driven development | a single place where the group's reasoning settles and can be found again | the model's reasoning evaporates in the flow |
| Reasoned and tracked decision | architecture decision records | the team does not re-litigate what had already been settled | state revisitation: the model recycles solutions already discarded |
| Iterative dialogue with open points | design doc, open points | forces the operator to be explicit and not to feign certainties | passive acceptance of the output, false certainties |
| Multiplicity of interlocutors | groupthink, dialectical inquiry | opens the operator's perspective beyond their own point of view | echo chamber, crystallisation of the single model |
The decision log keeps the model away from recycling discarded solutions, and at the same time spares the human team from re-deliberating what is closed; the multiplicity of interlocutors breaks the crystallisation of the single model, and at the same time opens the operator's perspective beyond their own. No pillar, alone, covers all the fronts; it is their working together, on the same persistent artefact, that produces what the sum of the pieces does not give: a reasoning of many voices — human and artificial — that is not lost, and that remains executable by whoever comes after. The effect observed in use is a leap in yield: a few people assisted by models produce, with this framework, results that would previously have required larger teams and longer times. It is an observation from use, not a measurement; and it is in this composition, not in the single bricks, that the method finds its own reason and its own name.
The observed result is twofold. On one side, the work becomes recoverable: an interrupted session is resumed from the document, not from memory; a new person enters the project by reading the decision log. On the other, the quality of the reasoning increases, because the method forces the making-explicit of what would otherwise remain intuition, and because it exposes the problem to more perspectives than a single operator would bring.
There is a third effect, which answers directly the echo chamber described at the outset. By concentrating competence in the drafting phase of the specification — and multiplying the interlocutors there — the method curbs the amplification of the operator's limits precisely where it would be most damaging. And the product of that phase, the specification, remains as a structured artefact that whoever comes after can execute without having to re-confront the open problem: competence spent once is reusable by whoever lacks it, be they human or agent.
The method has limits, and some have already emerged in use.
| Limit | Implication |
|---|---|
| Initial overhead | Writing and maintaining the specification has a cost that is not justified for short or throwaway tasks. The method pays off on work of duration and complexity, not on the single request. |
| Context saturation | The additive character makes the specification grow, and a wide specification held entirely in context saturates the model's attention. Distillation and partitioning (chapter 7) mitigate the problem but do not eliminate it; it is the method's most tangible limit, and it strains above all models with a narrow context window. |
| Risk of over-structuring | The discipline can degenerate into apparatus: decisions where an obviousness would suffice, structure where prose is needed. It is the reverse of the tendency to overdo treated in chapter 3; the corrective — declared scope and the good-enough criterion — reduces the risk but does not eliminate it, and requires the judgement of a competent operator. |
| Personalities not sufficient | As stated, distinct interlocutors do not guarantee distinct reasoning. The benefit depends on the design of the roles, not on their mere presence. |
| Dependence on human judgement | The decision remains a human act. The method improves the information on which the decision is founded; it does not replace it, nor does it make up for the lack of a criterion. |
| Evidence from a single domain | The experience that supports the method comes from software development, where intent is formalisable in advance and error surfaces early. That it pays off in the same way where a rapid test of correctness is missing, or where intent and product co-evolve, is a reasonable expectation, not a demonstrated fact. It must be verified domain by domain. |
There is, finally, what this document does not claim. It does not maintain that the method produces better results in any measurable sense on an arbitrary task: it maintains that it makes the work traceable, recoverable and open to more perspectives, and that these are process advantages, distinct from the quality of the single output. Generalisation beyond the experience it is drawn from must be verified case by case.
A working method can remain an individual discipline, entrusted to the constancy of whoever practises it, or it can be embodied in a tool that makes it natural rather than laborious.
The reason to build a dedicated tool is that each of the four principles, today, is sustained only with effort on interfaces conceived for the single conversation. The decision log lives in a hand-maintained file; open points are lost if the operator is not disciplined; distilling the specification, tracking its changes and partitioning it into sub-specifications are entirely manual operations; the table of interlocutors — distinct by role and, where needed, by model — requires orchestrating several conversations by hand and keeping their roles separate. It was precisely this management effort — sustainable on one piece of work, insidious across many — that matured the idea of a dedicated tool. A tool that takes the method as its own native form — with the versioned specification at the centre, the decision log as a first-class structure, and several distinct digital interlocutors converging on a single shared document under the guidance of a human operator — turns a demanding practice into an ordinary way of working.
This is the justification of the tool for which this document is the foundation: not one more container of conversations, but the operational translation of a principle — that work between a human operator and a model requires a place to settle, a memory of its own reasons, and more than one perspective.
The method rests on four principles taken from consolidated traditions and composed into a unique form. The specification precedes the product and is the source of truth. Decisions are numbered and motivated, so that they are not re-argued. Open points are tracked instead of blocking or being hidden. The digital interlocutors are made distinct in order to multiply the perspectives on a problem, with the declared awareness that the distinction is necessary but not sufficient.
What holds the four principles together is a single conviction, verified by use: work with a language model produces lasting value only if the reasoning that generates it is held on to, structured and opened to more voices — instead of slipping away in the flow of a conversation no one re-reads. To this conviction, and to the form that gives it body, the document has given a name: Koòrdinated Thinking.
The references are grouped by the nature of the source. The distinction is deliberate: not all sources carry the same evidential weight, and treating them as equivalent would be incorrect. The academic papers and the consolidated practices underpin the foundational claims; the position papers and observational sources are cited for what they are — framings and field observations, not controlled experimental evidence.
Piskala, D. B. (2026). Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants. arXiv:2602.00180. arxiv.org/abs/2602.00180 — A systematic guide to spec-driven development and its levels of rigour. A practitioner-facing paper, widely cited in the subsequent literature.
Nygard, M. (2011). Documenting Architecture Decisions. Cognitect. cognitect.com — The original essay that popularised the Architecture Decision Record; rooted in Kruchten's work on the decision view. A de facto standard, adopted by GDS UK, AWS, ThoughtWorks.
Architectural Decision Records. A collection of templates and practices (the ADR organisation). adr.github.io — The current reference point for formats (Nygard, MADR, Y-Statement) and process.
On state revisitation and on the absence of a structured memory of visited states as its cause: recent literature on reasoning models and agents documents the cyclic return to already-discarded solutions, the semantic (not merely lexical) nature of the phenomenon, and its origin in the localisation of the context window and the absence of an explicit visited-set (studies on reasoning LLMs and reasoning degradation in agents, 2025–2026). Academic papers and observations of agentic practice; the phenomenon is widely encountered in agentic loops, and its mitigation through structured context is the object of current work.
On semantic drift (the sliding between legitimate senses) and its origin in inference from statistical co-occurrences in the absence of explicit grounding, and on the domain glossary as a corrective: recent literature on large language models in industrial contexts and on structured generation documents the phenomenon and measures the effectiveness of injecting a domain glossary and a data register as methods of reducing drift (studies on hallucination reduction and semantic consistency, 2025–2026). On the register of sources: the notion of provenance (every claim traces back to the source it comes from, verifiable rather than regenerated) is consolidated in the literature on grounding and agent memory. Academic papers and practice reports; the quantitative measures come from individual studies and are to be read as indicative.
Slatton, G. (2025). Writing a good design document. grantslatton.com — A practical treatment of the design document as an instrument that adds rigour to reasoning. A professional source, not an academic one.
On the cognitive forcing function in AI-assisted work: recent experimental studies show that obliging explicit engagement with the plan reduces passive acceptance of the output (literature on cognitive forcing functions, arXiv 2026). Initial experimental evidence, still consolidating.
On multi-agent debate and personalities: the literature shows that assigning distinct roles diversifies the perspectives but does not raise performance consistently, and that homogeneous reasoning produces a "mental fixation" despite different personalities (Diverse Multi-Agent Debate and related work, 2024–2026). Academic papers; results dependent on the design of the roles.
On heterogeneous models: research on ensembles and debate between models from different vendors documents complementary biases and failure modes, and the breaking of the single-model team's "echo chamber"; with the caveat that where the failure modes converge, diversity does not help (literature on heterogeneous LLM ensembles and mixed-vendor multi-agent, 2024–2026). Academic papers, some domain-specific.
Janis, I. L. (1972). Victims of Groupthink. Houghton Mifflin — the original formulation of groupthink and of the devil's advocate as a corrective.
Mason, R. O. (1969). A Dialectical Approach to Strategic Planning. Management Science, 15(8) — dialectical inquiry as a decision structure. Classic, consolidated sources.
An, T. (2026). AI as Equalizer or Amplifier? Task Complexity as the Moderating Factor for Human Expertise in Hybrid Intelligence Systems. arXiv:2512.10961. arxiv.org/abs/2512.10961 — Argues that AI amplifies competence on complex tasks and levels it on simple, well-structured ones. Position paper based on structured observations of a small team, not on a controlled study: to be read as a framing, not as proof. It anchors to the "jagged frontier" of Dell'Acqua et al. (2023).
Convergent empirical evidence on the expert–novice gap in the use of large language models for complex tasks (studies on cybersecurity, laboratory biology, problem reframing, 2024–2026); and contrary evidence of levelling on structured tasks (e.g. assisted scoring). Academic papers; the overall picture depends on the type of task.
Simon, H. A. (1955). A Behavioral Model of Rational Choice. Quarterly Journal of Economics, 69(1) — the original formulation of satisficing and bounded rationality, whereby under constraints of time and information one chooses the first option that clears a threshold of adequacy. A classic source (Simon, Nobel 1978).
Rittel, H. W. J. & Webber, M. M. (1973). Dilemmas in a General Theory of Planning. Policy Sciences, 4(2), 155–169 — introduces the distinction between "tame" problems (well-structured, with defined objectives and solution criteria) and "wicked" problems (whose very formulation shifts as they are tackled). The class of structurable problems the method addresses corresponds to the first pole of this distinction. A classic source.
On gold plating, over-engineering and scope creep as documented causes of delays and costs in project management and software development: consolidated nomenclature in the project-management literature; the quantitative estimates on the cost of unused features come from individual industry surveys and are to be read as such, not as consolidated data. On the reverse — contexts in which the pursuit of the optimum (maximizing) pays more than the sufficient — there is evidence in the entrepreneurial domain (studies on decision styles and performance, 2017–2026): the picture depends on the context.