Tacit Work Needs a Mission Room

Disclosure. This research paper and the experimental builds it describes are supported by Theoremlabs.io (tacit.theoremlabs.io). It is a working paper: it has not been peer reviewed and reports no empirical results. Each author is an Adjunct Researcher-in-Residence, Future of Ways of Working, at Theoremlabs.io, which develops Tacit Chassis, the reference implementation described in Section 10. We invite comments, critique and collaboration from researchers and practitioners at research@theoremlabs.io.

1. Introduction

Consider a familiar engagement. A senior advisor and a small team are asked to assess how a client organization actually works: where decisions stall, which controls exist only on paper, which risks or opportunities are real. Over several weeks they interview dozens of people, read what documentation exists, and form a view. The result is a report or a slide deck. Weeks later, few people can say which interview a given conclusion came from, which conclusions the senior advisor examined personally, or where the client's confidential material now resides.

This kind of work is old and economically significant. Advisory, due diligence, implementation readiness, integration planning and many forms of assessment share its shape. Yet the software it runs on was built for other purposes: email and chat for conversation, shared drives for files, data rooms for controlled document exchange, slide software for the final product. None of these tools knows what a mission is, who must confirm what, how a finding relates to its evidence, or which knowledge belongs to which party.

Other kinds of team work have acquired purpose-built environments. Design and product teams work in tools such as Figma and Miro. Engineering teams work in issue trackers and wikis such as Jira and Confluence. In each case the tool encodes the structure of the work. Expertise engagements between a provider and its client have no equivalent.

AI agents change the urgency of this gap. Agents can now conduct structured interviews, transcribe and summarize them, draft findings and propose scores. That removes much of the labor that justified large engagement teams. It also creates three problems. The first is accountability: when an agent drafts a finding and a person forwards it, it is no longer clear who decided. The second is ownership: a system that interviews a client's people and applies a provider's method holds both parties' most sensitive knowledge at once, and an agent system that learns from one engagement may carry it into the next. The third is sovereignty, security and privacy: client content, including recordings of named individuals, flows through agents and model services whose location, retention and access the client may not control.

This paper makes four contributions. First, it characterizes tacit work and argues that it constitutes a distinct category of collaboration (Sections 2 to 4). Second, it specifies the Mission Room and two preconditions without which neither providers nor clients will adopt one: separation of ownership between client context and provider expertise, and solutions to data sovereignty, security and privacy that can be demonstrated under assurance standards such as SOC 2 (Sections 5 and 6). Third, it defines a governance pattern, Draft, Confirm, Commit, and consolidates the invariants that any Mission Room must hold (Sections 7 and 8). Fourth, it proposes an operating model that replaces the staffing pyramid (Section 9) and describes an open-source reference implementation (Sections 10 and 11). Section 12 states hypotheses, and Section 13 sets out limitations. We regard the first two contributions as the paper's main ones. The governance pattern and the operating model build on active lines of work, which we cite where they apply.

2. What Makes Work Tacit

Polanyi's observation that "we can know more than we can tell" (Polanyi, 1966) is the usual starting point for discussions of tacit knowledge. Nonaka and Takeuchi (1995) described how organizations convert tacit knowledge into explicit form and back. Collins (2010) distinguished kinds of tacitness, from knowledge that simply has not been written down to knowledge that is embodied or collective and resists articulation. The naturalistic decision-making tradition showed how experts decide under uncertainty (Klein, 1998) and developed interview methods, known as cognitive task analysis, for eliciting that expertise (Crandall, Klein and Hoffman, 2006). Leonard and Swap (2005) described the experience-based judgment of senior practitioners as "deep smarts" and examined how it is, and is not, transferred.

This literature is mostly concerned with knowledge inside one organization. We are concerned with a narrower unit: a piece of work in which one party is engaged to draw out and judge knowledge held by another. We call this tacit work and propose that it has five properties (Table 1).

Examples span industries: commercial due diligence, operating-model discovery, go-live and implementation readiness, post-merger integration planning, market-entry assessment, AI adoption assessment, and site assessment for economic development. Each involves a provider eliciting knowledge from a client's people, judging it against its own method, and standing behind the result.

3. The Collaboration Landscape

Collaboration software has long been studied as a support for articulation work, the effort of coordinating distributed activity (Schmidt and Bannon, 1992). Commercial tools have since divided along two lines that matter here. The first is orientation: whether a tool is general purpose or built around the artifacts and stages of a particular kind of work. The second is boundary: whether a tool is designed for work inside one organization or between organizations with distinct interests. Figure 1 places common tool classes on these two axes.

Three tool classes sit near the empty quadrant and are worth distinguishing from it. A virtual data room crosses the boundary between parties and is controlled and audited, but it holds what parties exchange rather than the work itself. Shared chat channels across firms carry conversation between organizations but impose no structure on it. Personal research assistants such as NotebookLM help one person reason over documents they already have; they do not elicit knowledge from other people or record who confirmed what. Products have also begun to apply agents to parts of this work: AI-led expert calls and knowledge-capture tools now conduct interviews and synthesize the results. They cover elicitation, but not the mission structure, the confirmation gate or the separation of ownership that this paper argues for. Table 2 compares these classes against the properties in Table 1.

4. What AI Agents Change

Two field experiments frame the opportunity and the risk. In a study of 758 consultants, Dell'Acqua et al. (2023) found that access to a large language model improved the quantity, speed and quality of work on tasks within the model's capability, while consultants using the model were less likely to reach the correct answer on a task just outside it. The authors describe this as a "jagged technological frontier": the boundary of what the model does well is uneven and not visible to the user. In a later field experiment with 776 professionals, Dell'Acqua et al. (2025) found that individuals working with AI performed at the level of two-person teams without it.

For tacit work, the implication is double. Agents can now do much of the elicitation and first drafting that once required layers of junior staff. Recent studies support this. An LLM agent interviewing employees recovered undocumented organizational knowledge in simulated settings (Zuin et al., 2025), and LLMs articulated experts' tacit knowledge from their behavior well enough to move novices toward expert performance (Cho et al., 2026). At the same time, their errors are hard to see, and research on automation shows that people supervising capable automated systems tend toward complacency and over-reliance (Bainbridge, 1983; Parasuraman and Manzey, 2010). Calls for human-centered AI emphasize high automation combined with high human control, rather than a trade-off between the two (Shneiderman, 2020).

Agents also change the stakes of ownership. Recent industry analysis argues that the differentiator in agentic AI is the tacit knowledge of an organization's people, which must be captured and codified for agents to act well (Tung and Roussière, 2026; Gartner, 2026). In tacit work, two bodies of tacit knowledge meet: the client's knowledge of itself, and the provider's knowledge of how to assess it. Once either is captured in a form agents can use, it becomes portable, and therefore easy to leak, reuse without permission, or absorb into a model. A workspace for agent-assisted tacit work must therefore treat ownership as part of its architecture, not as a clause in a contract.

A further concern is apprenticeship. Expertise has historically passed from senior to junior practitioners through repeated, supervised work on real problems (Leonard and Swap, 2005). If agents absorb the junior tasks, that path narrows. Section 9 returns to this.

5. The Mission Room

A Mission Room has seven components (Table 3, Figure 2).

Eight design principles follow from the properties of tacit work.

1. Missions before agents. The workspace is organized around the mission and its stages. Agents serve the mission; they are not the organizing unit.
2. A confirmation gate that cannot be removed. No finding becomes authoritative until the Lead confirms it (Section 7).
3. Provenance from conversation to record. Every record can be traced to the elicitation session that produced it.
4. Expertise as versioned playbooks. What the agents elicit and how findings are scored is written down, versioned and recorded against each mission.
5. Isolation per provider and client. Each provider and client pair is a separate tenant, which aligns the technical boundary with the contractual one.
6. Ownership follows the knowledge. The client's context belongs to the client and the provider's expertise belongs to the provider, and the system keeps the two apart (Section 6).
7. Sovereignty, security and privacy by construction. Where content resides, who can reach it and how personal data is handled are properties of the system, not procedures layered on afterwards (Section 6).
8. Explicit client visibility. The client sees the confirmed result in a read-only view at the end, not drafts in progress.

6. Preconditions for Trust: Ownership, Sovereignty, Security and Privacy

A Mission Room asks a great deal of both parties. The client is asked to let an agent interview its people and to place its internal knowledge in a system run by someone else. The provider is asked to encode its method, which is the substance of its professional value, in a form that software and agents can apply. Each party will reasonably ask three questions before it agrees: who owns what, where does it reside and who can reach it, and how can that be proved? Unless the answers are clear and enforced by the system, a Mission Room will not be taken seriously, however capable its agents. We treat these as preconditions, and Section 8 states them as invariants.

6.1 Two kinds of knowledge, two owners

Every Mission Room holds two kinds of knowledge. Client context is what the client knows about itself: its documents, what its people said in interviews, the Client playbook, and the client-specific facts recorded in findings. Provider expertise is how the provider knows to assess such a client: its Base playbook, including what to elicit, which fields a finding carries and the rubric for scoring, and its agent configuration for that kind of work. Table 4 assigns each asset an owner.

6.2 Learning without leakage

Providers will want their method to improve with use, and the research agenda in Section 12 assumes it does. This creates a tension with client ownership: the natural way for an agent system to improve is to learn from the content it processes. A Mission Room resolves the tension by design. The Base playbook improves only when the provider authors a new version, drawing on its own professional judgment. Client facts are recorded in the Client playbook and never written back into the Base playbook. Mission content is not used to train models, whether by the operator of the deployment or by the model providers the agents call. Any reuse of one client's content for another purpose requires that client's explicit consent.

6.3 Exit in both directions

Ownership is only real if each party can leave with what is theirs. A client must be able to export its context and the confirmed results of its missions, and to have its content deleted at the end of the engagement or on request, subject to agreed retention. A provider must be able to export its Base playbooks and agent configuration and take them to another deployment. An open playbook format, and an open-source implementation that any party may run, make the second form of exit credible.

6.4 Data sovereignty

Data sovereignty is the question of who controls data and under which jurisdiction and rules it is held and processed. In tacit work it has three dimensions. The first is location: a client may require that its content, including recordings of its people, remain in a particular country or region, or inside its own environment. The second is control of deployment: a provider or a client may need to run the system itself rather than entrust content to a third-party host. The third is control of processing: every agent call sends content to a model service, and the parties need to know which services receive it, where they run, and on what terms they retain it. A Mission Room must therefore let each deployment choose where content resides and which processing services may receive it, record those choices for each tenant, and ensure that no component, including an optional control plane, moves content outside them.

6.5 Security

Agent-assisted tacit work faces threats that ordinary collaboration tools do not face in the same form.

• Leakage across clients. A provider that serves competing clients must never let one client's context reach another's mission, including through shared agent memory, caches or search indexes.
• Privileged access by those who run the system. An operator or host should not be able to read mission content except through recorded, justified and limited access.
• Manipulation of agents. Documents and interview answers that agents read can carry instructions intended to make an agent disclose data or take unintended actions, a class of attack known as prompt injection (Greshake et al., 2023). Agents must act only within one tenant's context and only through approved tools, and must treat what they read as data, not as instructions.
• Retention by model services. Content sent to a model provider may be logged or retained unless terms and configuration prevent it.
• Compromised accounts. Leads and Operators can reach sensitive material across a mission and need strong authentication.

The response is defense in depth: isolation enforced on every data access and tested continuously, least-privilege roles, encryption in transit and at rest, an append-only audit log, and agents whose context and tools are confined to one tenant.

6.6 Privacy

Interviews are conversations with identifiable individuals, often about their work, their colleagues and what is not going well, and voice interviews produce recordings of their voices. Interviewees are data subjects with interests of their own, distinct from those of the provider and of the client organization. A Mission Room must tell interviewees what the agent is, what will be recorded, who will see it and for what purpose, and obtain their consent before the interview begins. It must keep recordings and transcripts only as long as agreed, allow personal data to be found, exported, corrected and deleted, and allow findings to attribute statements to roles rather than names where names are not needed. Data-protection law, such as the EU General Data Protection Regulation (European Union, 2016), adds obligations that depend on where the data subjects and the data are, which is one reason privacy and sovereignty cannot be designed separately.

6.7 Demonstrating it: SOC 2 and related standards

Solving these problems is necessary but not sufficient: the parties must be able to verify the solutions. Clients already require their service providers to demonstrate controls over the data they hold, and the most widely requested demonstration in the United States is a SOC 2 report. A SOC 2 examination, defined by the American Institute of Certified Public Accountants, reports on a service organization's controls against the Trust Services Criteria: security, availability, processing integrity, confidentiality and privacy (AICPA, 2017). A Type I report concerns the design of controls at a point in time; a Type II report also tests their operating effectiveness over a period.

Two consequences follow. First, it is an organization that is examined, not software. A provider that runs its own Mission Rooms, or a host that runs them on providers' behalf, is the party whose controls are examined; software cannot be "SOC 2 compliant" on its own. Second, software can make those controls straightforward to operate and to evidence, or nearly impossible. A Mission Room should therefore implement the relevant controls as properties of the system and produce the evidence an auditor needs as a by-product of normal operation. Outside the United States, ISO/IEC 27001 certification (ISO/IEC, 2022) and data-protection obligations play a similar role. Table 5 maps each SOC 2 criterion to the capabilities a Mission Room must provide.

7. Draft, Confirm, Commit

"Human in the loop" is too loose a phrase to govern anything. It does not say which human, at which point, with what authority, or what happens if they are absent. We propose a precise pattern for agent-assisted expertise work, which we call Draft, Confirm, Commit.

7.1 The pattern

A mission moves through ordered stages. In the reference configuration these are Discover, Baseline and Commit (Figure 4). In Discover, an interviewing agent conducts one-to-one conversations with the client's people, by voice or text, and stores complete transcripts. From these it drafts candidate records and proposes a score for each against the rubric in the Base playbook. In Baseline, agents assemble the records into a register document, which the Lead reviews. In Commit, the Lead confirms each record, either keeping or overriding the proposed score. Commit ends only when every record is confirmed. The client then receives a read-only view, and the mission produces an audit trail covering every record's source session, proposed score, confirmed score and time of confirmation.

The governance invariants of this pattern are stated with the ownership, sovereignty, security and privacy invariants in Section 8. Table 6 summarizes rights by role.

7.2 Provenance

Accountability requires that a reader of any confirmed finding can see where it came from and where a person changed the agent's view. Figure 5 shows the chain.

7.3 Gates and rank

Scoring in tacit work answers two different questions: does a finding matter enough to act on, and in what order should findings be addressed? The pattern separates them. Gate dimensions decide whether a record passes a threshold set by the Lead. Rank dimensions order the records that pass. The reference configuration uses Risk and Impact as gates, and Evidence and Reach as rank. Each kind of work substitutes its own dimensions in its Base playbook; the separation of gate from rank is what persists.

7.4 Expertise as versioned playbooks

A Base playbook holds the provider's expertise for a kind of work, written before any client engagement: what the interviewing agent should elicit, which fields a finding carries, and the rubric against which it is scored. Every mission of that kind starts from the same Base playbook, at a recorded version. A Client playbook holds what is known about one client, assembled at setup and extended during Discover, and is visible only inside that mission. Treating codified expertise this way makes it reviewable and improvable in the way source code is, makes it possible to ask which version of the expertise a given finding was judged against, and keeps the provider's intellectual property distinct from the client's information.

7.5 Related patterns

Draft, Confirm, Commit has close relatives. Software teams require review before a change is merged. Banks apply the four-eyes principle, in which a second person approves a transaction prepared by a first. Clinical documentation requires sign-off by a responsible clinician. Editorial work separates the writer from the editor. Each separates preparation from authorization and records who authorized. What is different here is that the preparer is often an agent, that the volume of prepared items can be high, and that the preparer can make errors that are fluent and plausible. Recent work on agent oversight proposes tiers of human involvement calibrated to stakes and reversibility (Bahidika, 2026), and shows formally that accountability cannot be preserved once agent autonomy passes a threshold (Tibebu and Shemtaga, 2026). Draft, Confirm, Commit is a domain-specific choice within that space: it keeps judgments about findings below that threshold by construction.

7.6 Failure modes

The principal risk is that confirmation decays into rubber-stamping. Automation bias and complacency are well documented when people supervise reliable automated systems (Parasuraman and Manzey, 2010), and a gate that is always passed provides little assurance. Bainbridge (1983) observed that the more capable automation becomes, the harder the remaining human role. Passi and Singh (2026) argue that human-in-the-loop review is on its own an insufficient form of oversight for agents, and that auditing, monitoring and steering are also needed. We agree: the gate is necessary but not sufficient. Override rates per field, time spent per record, and periodic re-examination of a sample of confirmed records against their sources are all observable within the pattern and are proposed as hypotheses in Section 12.

8. Invariants of a Mission Room

We define a Mission Room by what may not change. A system that lacks any invariant in Table 7 may be a useful tool, but it is not a Mission Room in the sense of this paper, and we argue it will not earn the trust of both parties to tacit work. The invariants fall into four groups. Governance invariants make accountability explicit. Ownership invariants keep the client's context and the provider's expertise apart and under their owners' control. Sovereignty invariants keep content where the parties have agreed and in the hands of services they have approved. Security and privacy invariants protect content and the people it describes, and make that protection demonstrable.

The governance invariants concern the work. The ownership, sovereignty, security and privacy invariants concern the parties and the people whose knowledge the mission holds. We place them on equal footing deliberately: a Mission Room with a sound confirmation gate but a porous boundary between client context and provider method fails the parties as surely as one with no gate at all.

9. After the Pyramid

Professional service firms have long been organized as pyramids: a few senior partners, more managers, and many junior staff. Maister (1982) described how the ratio between levels, or leverage, drives the economics of such firms. The pyramid does two jobs. It produces leverage, letting scarce senior judgment be applied across many engagements. And it produces the next generation of seniors, through years of supervised work on real problems.

Others have described how AI reshapes this structure. Duncan, Anderson and Saviano (2025) argue that consulting firms are moving from a pyramid to an "obelisk" with fewer layers, organized around AI facilitators, engagement architects and client leaders. We do not claim the move away from the pyramid as our contribution. Our contribution is narrower: a mission-level form of that structure, with a fixed pair of people, confirmation rights held by one of them, and a specific mechanism for apprenticeship.

9.1 The Lead and Operator model

We propose that a Mission Room is staffed by a fixed pair. The Lead is accountable for the mission end to end: scoping it, holding the client relationship, setting gate thresholds and confirming every record. The Operator is optional. The Operator runs the room and its agents under the Lead's direction and never confirms. Without an Operator, the Lead does this work. Around the pair sits the agent roster, which does the elicitation, transcription, first drafting, first-pass scoring and document assembly that once occupied the lower levels of the pyramid.

The design premise is that as agents improve, the senior time a mission needs should fall, and the human side of delivery should stay a fixed pair rather than grow with scope. Whether this holds is an empirical question (Section 12). If it does, the model favors small senior practices, independent advisors and in-house expert teams, which can offer senior attention on engagements that a pyramid could not staff economically. The ownership invariants matter particularly to such practices, whose method is often their principal asset.

9.2 The Operator as apprentice

The concern that AI removes the junior work through which expertise is learned is serious. We suggest the Operator role can partly answer it. An Operator works inside every stage of a mission: configuring and tuning the agents, reading the transcripts, seeing each draft, and observing every confirmation and every override the Lead makes. This is close to the conditions that the expertise literature associates with learning judgment: repeated exposure to real cases, with feedback from an expert, on the decisions that matter (Klein, 1998; Leonard and Swap, 2005). A career path from Operator to Lead is a natural consequence. A recent workflow-level framework for human-agent collaboration likewise treats learning and career advancement as conditions for genuine augmentation (CIVIC-AI Collaboration, 2026). Whether Operators in fact acquire judgment faster than juniors in a pyramid is testable (H5 in Section 12).

9.3 Risks

The model has three evident risks. The Lead can become a bottleneck, since only the Lead confirms. Operators may learn to operate tools without learning to judge. And clients may trust a result produced by fewer people less, even if it is better evidenced. Each can be observed: time to Commit, agreement between Operator predictions and Lead decisions over time, and client acceptance of confirmed findings.

10. Reference Implementation: Tacit Chassis

Tacit Chassis is an open-source implementation of the Mission Room, intended to be specialized for different kinds of tacit work. It is to be released under the Apache License 2.0. At the time of writing it is under active development and not yet public. Its first public release, version 0.1, is defined as the point at which the reference mission configuration runs end to end: Discover, Baseline and Commit, with the Lead confirming every record and the client receiving a read-only view. Project information and experimental builds are published at tacit.theoremlabs.io.

10.1 Structure

The implementation has two layers. A set of core packages holds the mission and stage state machine, the Register, the scoring engine and the confirmation rules. A reference application, the Studio, is a deployable workspace built on those packages. Adopters may deploy the application, fork it, or use the packages directly. The domain package is pure, with no input, output or framework dependencies, so the governance invariants can be enforced in code that is tested in isolation. Every external vendor, including model providers, storage and voice services, sits behind a port with interchangeable adapters, so that no vendor is built into the core and a deployment can choose storage, voice and model providers whose location and terms satisfy invariants O4 and V2. Open-source platforms for AI-led qualitative interviews already exist for research use (Geiecke and Jaravel, 2025). The Chassis differs in applying interviewing inside commercial missions, under the invariants of Section 8.

10.2 How Tacit Chassis addresses ownership, sovereignty, security and privacy

Section 6 set out problems that any Mission Room must solve. Tacit Chassis is our proposed solution to them. Table 8 maps each problem to the approach the Chassis takes and the invariants it serves, with the state of each at the time of writing.

The Chassis is designed so that an organization operating it, whether a provider running it itself or a host running it for providers, can meet the SOC 2 Trust Services Criteria and produce the evidence an examination requires. No examination has yet been performed, and, as Section 6.7 explains, one would be of that operating organization rather than of the software.

10.3 Extension points

A specialization of the Chassis for a kind of work is called a fork. Table 9 lists what a fork may change and what it may not. The right-hand column restates the invariants of Section 8 in terms of what a fork could otherwise be tempted to alter.

11. Generality Across Industries

The claim that the Mission Room is a category, rather than a tool for one engagement type, rests on whether one base serves tacit work in different industries by changing only what a fork may change (Table 9): stage names, record fields, scoring dimensions, agents and playbooks. The pattern recurs wherever a provider must understand how a client actually operates before it can deliver: a fintech onboarding a bank, a RegTech vendor taking a regulated firm live, an IT services firm planning a migration, a management consultant redesigning an operating model. In each case the decisive knowledge sits with the client's people, the provider brings a method, and a named professional must stand behind the result.

Figure 7 and Table 10 give examples. Only the advisory configuration, for AI adoption, has been specified in detail. The others are illustrations that have not been built.

Across these examples the stages change little. Most use Setup, Discover, Baseline and Commit, and a fork may rename a stage to suit its work, such as a Readiness review in a go-live mission. What changes is the Base playbook: what the interviewing agent asks, which fields a record carries, and how it is scored. That is where each industry's expertise lives, and where the provider's intellectual property sits.

12. Research Agenda

The Mission Room produces structured traces of tacit work: transcripts, drafts, proposed scores, confirmations and overrides, all tied to playbook versions. With consent and aggregation, and consistent with the ownership invariants, these traces support studies that are difficult to run on engagements conducted with general tools. We state seven hypotheses.

1. H1. Leads override a stable and measurable share of agent-proposed scores, and that share differs by kind of work and by record field. Measure: override rate per field and per mission type.
2. H2. Missions reach Commit faster than comparable engagements run with general tools, without lower quality of confirmed findings. Measure: time to Commit; blind expert rating of confirmed registers against matched engagements.
3. H3. Evidence elicited in interviews changes conclusions that document-based analysis alone would reach. Measure: share of confirmed records with no documentary source.
4. H4. On some topics, people disclose more operational detail to an agent interviewer than to a human one. Measure: matched interview designs, building on prior work showing greater disclosure to virtual interviewers (Lucas et al., 2014) and on randomized comparisons of AI and human interviewers (Wuttke et al., 2024).
5. H5. Operators converge toward Lead-level judgment faster than junior staff in a traditional pyramid. Measure: agreement between Operator predictions and Lead confirmations over successive missions.
6. H6. Base playbooks improve with use through provider-authored versions, and most of a playbook carries over from one mission to the next. Measure: differences between playbook versions; reuse across missions.
7. H7. Explicit ownership terms enforced by the system increase clients' willingness to take part. Measure: interview consent and completion rates, and time to client approval, with and without explicit ownership terms.

Tests of H1 and H6 are possible with data from routine use. H2, H4, H5 and H7 require comparison groups and are better suited to designed studies with academic partners.

13. Limitations

This paper is a design proposal. It reports no field data, and its central claims are hypotheses. The authors develop the reference implementation and have an interest in its adoption; independent evaluation is needed. Agent interviewers may change what people say, in either direction, and the effect may vary by culture, profession and topic. The pattern assumes that a single accountable Lead is appropriate; some engagements distribute accountability across several people. Ownership of deliverables is ultimately settled by contract and law; software can enforce boundaries but does not determine legal title. Sovereignty and privacy obligations differ by jurisdiction. SOC 2 is a United States standard, and providers elsewhere will face other regimes, such as ISO/IEC 27001 and data-protection law, which the invariants support but do not by themselves satisfy. Finally, the boundary between tacit and explicit knowledge is not sharp (Collins, 2010), and some work we describe as tacit may be better served by improving documentation than by structured elicitation.

14. Conclusion

Expertise engagements between providers and their clients are a distinct kind of collaboration. They cross an organizational boundary, rest on knowledge drawn out of people, end in judgments, carry accountability, and are bounded in time. General-purpose tools serve their conversation and their files but not their structure. AI agents now make it practical to do much of the elicitation and drafting by machine, which makes the absence of structure more costly: without it, provenance, accountability and ownership erode.

We have proposed the Mission Room as the missing category, with two preconditions for trust: the client's context remains the client's and the provider's expertise remains the provider's, and the system solves for data sovereignty, security and privacy in ways an operator can demonstrate under standards such as SOC 2. We have proposed Draft, Confirm, Commit as its governing pattern, a consolidated set of invariants, and the Lead and Operator pair as an operating model that follows the pyramid. The central commitments are simple. Agents draft, a named person confirms, and each party keeps what is theirs. Whether these commitments improve the speed, quality and transmission of expert judgment is an empirical question, and Section 12 sets out how it can be answered. We welcome comments, critique and collaboration at research@theoremlabs.io, and project information is at tacit.theoremlabs.io.

References

Disclosure. This research and the experimental builds of Tacit Chassis are supported by Theoremlabs.io. P. Sarode and R. Nair are each an Adjunct Researcher-in-Residence, Future of Ways of Working, at Theoremlabs.io, which develops Tacit Chassis. Product and tool names in Figure 1 and Table 2 are used descriptively to identify tool classes; their placement reflects the authors' assessment and implies no endorsement. Section 11 describes illustrative configurations, of which only one has been specified in detail. Nothing in this paper is a representation that any deployment has been examined under SOC 2.

Draft status. Version 0.7, October 2026. Project information and builds: tacit.theoremlabs.io. Comments, critique and collaboration: research@theoremlabs.io.