List of figures

Figure 1.1 - Two sides of equal standing, each with knowledge of its own: the agent learns through onboarding and its own experience, people through education and experience; they work together in between and meet in Reflection above them.
Figure 2.1 - Fluid intelligence reasons in the moment and keeps nothing; crystalline intelligence accumulates and keeps. The web UI takes its name from the fluid side: people and the agent meet in it on reflections, and a side door opens on the engrams for inspection.
Figure 3.1 - The lifecycle: learn, evolve, remember, turning session by session.
Figure 3.2 - The maintenance queue in Fluid, narrowed to the Meaning family: two lines that may contradict each other.
Figure 4.1 - The anatomy of an engram: frontmatter, prose, an observation and a relation.
Figure 5.1 - First visit: creating the admin account in the browser.
Figure 5.2 - The routing prompt an agent receives at session start.
Figure 6.1 - The same block unabridged, as crystalline prompt system prints it.
Figure 7.1 - Editing an engram in Fluid: live preview, the frontmatter form and wikilink completion.
Figure 7.2 - Your agent in the page with you: its glyph in the strip beside yours, writing while you write.
Figure 12.1 - Present, test, improve: the agent presents what it knows, people change and comment, and what holds up in a thread goes back into its knowledge.
Figure 12.2 - Two lifecycles around one body of knowledge: evolve keeps it true, reflect keeps what people see in step with it.
Figure 13.1 - The six callout kinds on a sample page, the expand block folded at the bottom.
Figure 13.2 - Status labels as the verdict column of a table.
Figure 13.3 - A deploy checklist, one item done and one that doesn’t apply.
Figure 13.4 - The payment flow as a sequence diagram on the page.
Figure 13.5 - A code block with its Copy button, and a colour swatch in the sentence below it.
Figure 13.6 - The Insert menu with its Callout submenu open.
Figure 13.7 - The callout toolbar with the caret in the caution: its kind and the three fold buttons.
Figure 13.8 - An info panel and a status lozenge pasted from a wiki, now a callout and a status label.
Figure 13.9 - The first printed page of the deploy reflection, with the title block and its QR code.
Figure 15.1 - One binary: the CLI, the MCP server, Fluid and the search index, all standing on plain markdown files. Agents come in through MCP, people through Fluid.
Figure 15.2 - Faceted search across the instance, backed by the ranking the agents use.
Figure 15.3 - The neighbourhood graph of an engram in Fluid.
Figure 15.4 - An engram in Fluid: details rail, observations and typed relations.
Figure 16.1 - One shared instance: agents connect over MCP with a token, people through Fluid with an account, with a proxy in front and an identity provider beside it where the team configures them.
Figure 16.2 - Signing in through the instance’s identity provider.
Figure 16.3 - A local Crystalline connected to the team server: the harness and the hooks keep talking to it as before, and it reaches the server over one signed-in connection.
Figure 17.1 - A team domain in Fluid: the sync status, the open proposal with its review link and the share button.
Figure 17.2 - Before sharing: the team’s copy against yours, one file at a time.
Figure 17.3 - One shared instance in review mode: each actor drafts in a private overlay above the domain folder, a draft goes out as a pull request, and in the default flow only a merged pull changes the folder.
Figure 17.4 - Live co-editing: two cursors in one engram.
Figure 18.1 - Renaming a domain in Fluid: the new name and the This machine only box.
Figure 19.1 - The domains of an instance in Fluid, private ones marked.
Figure 20.1 - The readers of a page compared with the readers of the domain a section draws on. The page may carry the text when its readers fit inside.
Figure 20.2 - A thread question meets a scheduled run that can’t see the private domain, so the answer comes from the run’s own domain only.
Figure 20.3 - What happens when a write names another domain to draw on.
Figure 20.4 - A section whose readers grew beyond the domain it draws on is held back from the backup until a person decides.
Figure 21.1 - The provisioning decision of every domain that ships tools and the installed state of every harness, with the other domains folded into one line.