Brief: How we use AI guide

Purpose

A growing guide to "how to do AI": migrating knowledge work to working with AI, focused on day-to-day practice at Life Itself (and perhaps useful elsewhere). Principles and practice, not click-by-click how-tos. It should stand alone so it can later move to Tao or be published elsewhere.

Shape (decided 8 Oct)

An expanding guide in chapters, one per area of work, e.g. AI as work interface, AI for planning, AI for design, AI for research, AI for automation (what we could do with the Wisdom paper).
Start with: AI as work interface, especially for planning and coordinating work, whether you working with your AI or the team working together.
The interface argument is the opening of the guide. A standalone essay version for Way Into AI is a separate piece of work.
Automation (the Wisdom paper) belongs in a later chapter, not chapter one.

Why v1 failed (Rufus's review, 8 Oct)

Two arguments mixed up. The thesis was "AI is the interface for knowledge work"; the worked example (the Wisdom paper) is about automating a big piece of work. That example does not support the thesis.
Asides presented as the point. Way Into AI is something Rufus publishes, not part of the argument. The "try it this week" ask added nothing.
Slogans instead of distillation. The "manifesto" TL;DR was punchy lines, not a clear statement of what we are saying.
Root cause: the draft was built from the extracted key-point list and the 8 Oct briefing, not from a close reading of what each part of the dictation is arguing.

Analysis of the source dictation

Source: raw dictation, 1 Oct 2026. Three parts, recorded the same day.

Part 1: the interface argument (the core)

What each passage is doing:

Framing by contrast. The revolution is not the obvious one (automation of tasks). For knowledge work it is a shift in interface.
History. For decades we built applications to make knowledge work easier for humans: WYSIWYG word processors, Docs, spreadsheets, Asana, GitHub. Huge sums went into interfaces for people to manage work "in their way".
The claim. The AI chat is now your interface, the control plane for most of what you do.
Anecdote (the trigger). A colleague used the AI to fetch their tasks, had it write them into a GitHub issue, then read the issue. Rufus: no, stay in the AI; it is more efficient and it is bespoke.
Why it is better: it is two-way.
- In: talk. We typed because dictation was bad; now it isn't. Talking is faster and you give more context. Don't go back and correct; just say more.
- Out: the AI can build any view in real time (HTML, a graph instead of bullets, a table). Most of the time that beats what an app gives you.
Meta-observation. This was not obvious, even to Rufus. He saw it by sitting with colleagues and watching their habits. People carry old habits into the new interface.
Consequence for apps. GitHub, Asana and Docs become filing cabinets: we rarely go and look in them. Exceptions: real-time co-writing and close editing (Google Docs); presentations will change too.
Consequence for tasks. Task management stops being reading issues and ticking boxes; it becomes conversation ("I did this", "what's next", "analyse the dependencies", "plan my next five hours / two days"). That level of bespoke, intelligent support used to need a senior executive with two full-time assistants.
Consequence for tool choice. The question flips: not "is this tool good for me as a human?" but "is it efficient, reliable and well structured for my AI?" Example: Beads, which Rufus has barely used directly and doesn't fully understand, but which works very well for his AI. GitHub tasks: slow API calls, costly, no proper dependency graph.
Caveat. You still need to understand your tools enough for when things go wrong.
Close. "This is the game."

Part 2: how does the AI know where to look?

Mostly practical, but with two principles underneath:

The AI needs a map. A central index of initiatives, where their materials live and where their tasks are. Use it for overview questions (start of day or week). Then go and work in one place, with a session scoped to that folder or repo.
The AI's power comes from its tools and its environment. It does not read everything; it uses tools built over decades (search, command line). Local copies are 10–1000x faster than the network; cloud sessions clone repos into a sandbox for the same reason. Beads works best locally.

Part 3: where do tasks live?

Practical answer for one colleague. Principle underneath: tasks live with the work (in the initiative's own repo or tracker), and the planning repo is the index. Also an honest admission: we are in a messy, in-between state (two trackers in parallel).

What the source does not argue

Nothing about automating whole projects (the Wisdom paper example came from the briefing, not the dictation).
Nothing about Way Into AI.
Little about risk or verification beyond "understand your tools".

Core insight (Rufus, 8 Oct)

Start in the AI, not the apps. You used to work in Asana or GitHub or their interfaces; no longer. The interface is the AI: it can build bespoke interfaces for you, and it can query the things. What it needs is a good storage layer.

So the model is two layers: the AI is the interface layer (talk in, bespoke views out); apps and files are the storage layer, chosen and organised so the AI can work with them well. Planning out loud, reporting by talking and coordinating through a shared plan are all consequences of this, not separate tips. Start the guide from where people are today (working in apps) and show the change in thinking.

Refinements (Rufus, 8 Oct, on the first manifesto draft):

Working with AI, not delegating to it. People assume we're handing decisions to the AI. We're not: we hand it the job apps used to do, building interfaces for us. We still think and talk with it, and tell it what's done.
Two things must work for AI: storage (infrastructure) and process. Both should work for humans and, increasingly, for AI, so we can hand it more over time and it can manage more itself.
Choose, don't invest. The storage point is "choose your storage layer for AI", and it is secondary, not central. We used to choose Asana or GitHub for their UI; now we would choose Beads because it's better for AI. An example, not a rule.
Shared plan → process. "One shared plan people and AI both read" is better put as "processes that work for you and for AI".
Fixing tools, softened. You may need some knowledge of what's going on in the background, and the AI can explain that too.

The argument as we read it before the core insight

One thesis and its consequences, rather than a list of tips:

The big change AI brings to knowledge work is not automation; it is a new interface. The AI conversation becomes where we work: we talk to it, and it builds us the view we need. Everything else follows: apps become storage, task management becomes conversation, everyone gets executive-level support, and we choose and organise our tools for the AI rather than for ourselves.

Candidate principles (to test with Rufus):

Work in the AI, not in the apps.
Talk, don't type; say more, don't tidy.
Ask for the view you need.
Manage your work by conversation.
Choose tools for how well they work for AI.
Give the AI a map, then work in one place.
Understand your tools enough to fix them.
(Meta) The new way isn't obvious: watch each other work.

Open questions

Scope: ✅ Answer. An expanding guide in chapters; start with AI as work interface for planning and coordinating; automation is a later chapter; Way Into AI essay is separate.
Is the "non-obvious, learn by watching each other" point a principle, or framing?
Do Parts 2 and 3 belong in this guide as principles (map; tools and environment; tasks live with the work), or in a separate practical companion?
What should the top of the guide be: a plain summary paragraph, or a short numbered statement of the argument?
What else has Rufus said in sessions or demos that is missing here? (Follow-up research: lip-ltx.)

Chapter 1 teaching structure (agreed 8–9 Oct)

The manifesto is a summary of principles that cut across all areas of work. The chapters teach practice.
Chapter 1 opens with a question ("How do you find out what to work on today?") and walks through four situations, in order, each as old way → new way → what changed (naming the manifesto principles at work):
1. What's on today?
2. Turning a mess into a plan
3. Reporting progress
4. Handing work on (including prepping a team meeting)
1 often loops into 2 ("what's on?" reveals it isn't clear, so you plan, then come back). A small ASCII diagram shows how the four relate around the shared plan.

Feedback on the first chapter 1 draft (Rufus, 10 Oct)

Diagram: top-down (suits screens and mobile). "What's on today / this week?" → a choice: clear or not clear. Not clear → make a plan → do the work; clear → do the work. Then update progress, and back to the top. Tasks, plans and reference documents sit alongside everything on the right, read and written all the time; no arrows needed.
"Handing work on" is unclear wording. The point is that others can pick up work. Handover, to a human or an AI, is about having enough detail that anyone can pick it up. Needs more discussion; parked.
Updating progress has two kinds: as you go in a session ("OK, now write an update" to the task, issue tree or reference document) and periodic, systematic reporting (end of week). There are patterns here to extract.
Research what others are doing on the web: practices and skills for AI as the work interface. Done 10 Oct: external research note.

Decisions on the external research (Rufus, 11 Oct)

Keep "apps are storage"; "systems of record" is too fancy for most readers.
No rule that you must read everything AI-drafted before sending. Instead we need a way to run outputs through a check for concision, focus and tone of voice (lip-mu2).
Principle 2 gains the point that talking makes starting easier and rich context cheap.
Landing the plane becomes a principle (7) and part of updating progress, alongside updating tasks as you go. Needed especially after planning or collaborative sessions.
Teresa Torres's /today as a footnote example in situation 1.
Weekly reporting: good enough as drafted.
Diagram: storage (memory) on the right with two parts, reference (including plans) and tasks. A project normally has both. Add a glossary of these definitions.
Aside: Rufus's own practice over the year is worth writing up and publishing as a guide, with a short history (lip-3jt, may move to personal planning).

Open questions (chapter 1)

What are the patterns for updating progress as you go? (e.g. "now write an update", end-of-session checkpoint)
Handover: how much detail, in what form, is enough for anyone (human or AI) to pick up work?
Situation 2: is the balance right between the AI drafting first and the SCQ staying yours? (Skipped for now.)

Visuals

Options, to choose with Rufus:

Hand-drawn style diagrams in Excalidraw, matching what the design repo already uses, exported to SVG. Best for the two-way interface and the "apps as filing cabinets" idea.
Simple SVGs drawn by the AI in house colours. Fast, easy to edit, but plain.
Open illustration libraries with free licences (for example Open Peeps and Humaaans, both CC0; unDraw, free licence). Quick, but generic and not our style.
Before/after table for the interface shift: cheap, and works in any Markdown renderer.

Process

Work through the open questions with Rufus, one at a time; he dictates, Claude shapes.
Agree the argument and principles here, then redraft guides/how-we-use-ai.md.
Add visuals once the text is agreed.

Brief — How we use AI guide