What to Write Down (And What to Protect)

A structural engineer has worked with the same steel fabricator for eleven years. She doesn't document what she knows about them: how their quality control slips when they're at capacity, which site manager to escalate through, when to specify tighter tolerances in writing because the usual verbal agreement won't survive a handover. She just knows. Her specifications reflect it. Her site visit schedule reflects it. Almost none of it exists anywhere anyone else could find.

When she goes on parental leave, the colleague covering her asks what they should know. She spends an afternoon trying to explain it - some of it she can articulate, but most of it can't quite be put into words. The colleague takes notes, follows them, and still gets things slightly wrong.

In Agents cannot do osmosis I argued that AI tools cannot pick up context by proximity - every task starts from zero, and firms need to produce written context deliberately before that becomes a critical liability. What your AI tools are missing described what that written context should contain: decision rationale, process knowledge, and client context. This post addresses a further complication: not all knowledge behaves the same way when you try to write it down.

Three categories of professional knowledge

In The Tacit Dimension (1966), Michael Polanyi wrote, "we can know more than we can tell." This is not a documentation problem. Expertise simply contains things people struggle to explain, even when they know them well. It means that the knowledge you need to write down falls into three distinct categories, all of which behave very differently.

Category 1 - Explicit knowledge that gets stronger when written. Decisions and their rationale. Conventions that evolved for good reasons. Lessons from past failures. Client preferences. The "why we do it this way" that leaves with every departing staff member. This is the knowledge that earlier posts in this series were describing. A new team member who reads a decision log makes fewer avoidable mistakes. An AI agent given this context performs better. The explicit knowledge earns its keep by being used and updated.

Category 2 - Administrative context that is useful but operational. Project details, document locations, team structures, who owns what. Essential for anyone coming in cold - human or AI - but not the thing that makes the work good. Documenting it is clearly useful but it is scaffolding, not expertise.

Category 3 - Tacit expertise that degrades when formalised. The engineering judgment that comes from building things and seeing the complications. The relationship intelligence built over fifteen years with a particular client. The instinct of a senior engineer who reads a set of drawings and knows, before an analysis model has been run, that something won't work.

This last category resists documentation in two distinct ways. Some of it becomes a checklist that imitates expertise without reproducing it. Some of it only exists in practice, which is a bit awkward to write down.

What the research confirms

Research on AGENTS.md files - the written context files software teams use to brief AI agents - found that files above 150 lines with too many "don'ts" made agents worse, not better. Over-specification degraded performance.

Another issue shows up in the literature. Research on agent harnesses and their memory identified an issue where bigger memory makes agents worse when it contains false retrievals - where a relevant-seeming piece of context from a previous project gets applied inappropriately to the current one. Undifferentiated documentation treated as a general memory layer actively harms performance.

Much of the current research concentrates in one domain. A recent analysis of 43 AI agent benchmarks found that the tasks in them are almost entirely programming-centric. The areas where professional services value actually concentrates - design coordination, client relationship management, project risk assessment, regulatory navigation - are barely represented. Which is convenient for benchmarking, but not especially representative of professional work.

The knowledge that's hard to write down is also hard to test AI against, so consulting firms and AI researchers are currently ignoring it.

What this means in practice

A rough autonomy map for AEC and professional services work, adapted from that benchmark analysis, looks something like this:

Task	Current AI capability	12-24 months
Document drafting - reports, specs, briefs, proposals	High	High
Research - precedent, regulatory, technical	High	High
Calculation and analysis with defined inputs	Moderate	High
Applying standards to specific situations	Moderate	Moderate-High
Coordination across disciplines, teams or workstreams	Low	Low-Moderate
Client relationship management	Low	Low-Moderate
Risk assessment and professional judgment	Very Low	Low

The top rows are category 1 and 2 work. The bottom rows are category 3. The table is not an argument against AI - it is an argument for documenting selectively and being honest about what expertise can and cannot be externalised.

Before you start writing, map your knowledge by category. Start by listing the five decisions you made this week. For each one, ask:

• Is this a rule that could be written down and followed?
• Is this a piece of context someone needs to do their job?
• Is this a judgment that depends on experience you can't fully articulate?

Many practices find the third category is larger than they expected - and that the first two are smaller and more writable than they assumed.

The uncomfortable part

The firms with the most to gain from this framework may well be the firms most likely to resist it. A practice that has accumulated twenty years of tacit expertise has a director who can scan a set of drawings in ten minutes and know where the problems are. That person senses - correctly - that something is lost when you try to write down what they know. So they resist the documentation project. The result is that their expertise is inaccessible to AI tools, to junior staff, and - when they leave - to anyone.

Protecting category-3 expertise is not the same as refusing to document anything. It means being deliberate about what you do with the time AI frees up. Use AI to accelerate category 1 and 2 work - drafting, research, analysis, project updates. Then reinvest that time in the conditions that actually produce category-3 expertise: difficult problems, real consequences, work where something is at stake and judgment has to be exercised under pressure. A firm that uses AI to handle routine work so all its staff can take on harder problems is protecting its expertise. A firm that uses AI to do more of the same work faster is quietly depleting it.

Category-3 knowledge is not just held by senior people - it develops through difficult work. Repeated judgment calls. Enough exposure that pattern recognition becomes instinct. Research on cognitive offloading suggests that when AI gives answers instead of scaffolding thinking, some of the learning that builds real expertise never happens.

For an individual practitioner, that is a productivity tradeoff. For a firm, the problem is who becomes senior next. The engineers and lawyers and consultants who currently hold category-3 expertise built it before AI existed. The junior staff entering the profession now may not get the same formation. If the work that used to develop judgment gets automated before the people doing it have developed any, the profession does not just lose efficiency - it loses the capacity to reproduce itself at the level that matters. Building written context for AI and investing in how junior staff develop judgment should not be separate initiatives.

Where to start

Document what can be written. Be deliberate about what can't. And honest about what you are choosing to leave out.