Work with Fieldcraft / The method
Five stages. One word. Something you keep at every step.
Every engagement runs the same way, whether it is one piece of work at a shop or a policy for a board. The stages spell the name. They are in this order because each one makes the next one safe.
Start a conversationF · I · E · L · D
- F
Find the work
Walk the building. List the jobs that repeat, who does them, which tools are already in use, and where the time goes.
You keep: The map of the work, on one page.
- I
Isolate what stays human
Decide what a system may do, what people keep, what data never goes in, and who approves what before it counts.
You keep: The written boundary. It becomes the core of the policy.
- E
Engineer the first system
The plan, then the first system on one piece of work: integrated with your systems of record, running on your own material as context, producing a structured draft that waits for approval.
You keep: A running first version and a thirty-day plan.
- L
Lead the people
Train the team on the tools they will actually use, set the approval habit, publish the approved list, and put the change in the week.
You keep: A trained team and the approved-tools list.
- D
Dial in
Monthly, from the log: what it did, the error rate, the hours it gave back. Adjust, extend, or stop. Then the next piece of work, decided from evidence rather than a plan.
You keep: The monthly log and the next decision.
Beyond prompting
Five levels. Most people stop at the first.
- 01 Prompting. Ask, show, shape. What anyone can do by Friday.
- 02 Your own material. The system works from your examples, your documents, your rules.
- 03 Connected tools. It reads and writes inside the software you already run, through the same connectors and interfaces your other tools use. Nothing gets retyped.
- 04 Systems that run. A workflow, started by a schedule or an event in your software, does a repeating job on its own, writes a draft back into the system it came from, logs what it did, and waits for approval.
- 05 Review and measure. An audit log, an error rate, the hours it gave back, and a monthly decision. The part almost nobody builds.
Training covers the first three. Build starts at the third and ends at the fifth. The systems I run sit at four and five.
How a system is built
Six parts. Every system, every time.
- 01 A trigger. A schedule, or an event in software you already run: an order lands, a form arrives, a month closes.
- 02 A read. The system pulls what it needs from your systems of record, through their own interfaces. It does not keep a copy.
- 03 A model call. Your material goes in as context: the example, the template, the rules. Nothing private leaves the boundary you set.
- 04 A structured output. A draft in the shape the next tool expects, written back where it belongs.
- 05 A log. What it read, what it wrote, and why. Readable by a person, kept.
- 06 An approval. Nothing acts on its own. A named person says yes before it counts.
That anatomy is the same whether the system sorts an inbox or drafts purchase orders. What changes is the trigger, the read, and the person.
Where the seats sit
Same method, three entry points.
+ Learn runs Find and Lead: the map and the training.
+ Build runs all five on one piece of work.
+ Decide runs Find and Isolate and hands you the written boundary.
Start a conversation