Writing from the work
Field notes
Field notes are long-form writing about getting operational tools used in companies whose work happens in the field, the shop and the office: why big systems stall, how to choose the first workflow, and how to prove a crew actually uses what was built.
- Your first AI tool may not have a chat box
Why the most useful first AI tool in a field operations company often has no chat box, and what it looks like instead. - Why the big system never got used
Why companies launch a full replacement system and the team never moves onto it, and why small single-job tools get used instead. - Why adoption guarantees are rare, and how ours works
Why adoption guarantees are uncommon in software work, and exactly how the Fox & Santiago usage commitment is defined, measured and enforced. - What the crew means when it says the system is too slow
Too slow is a crew's shorthand for too many steps at the wrong moment. How to find what they really mean and what actually fixes it. - What a custom workflow tool costs, and why
Why custom workflow tools should be priced fixed after a Spec, and what drives a Build's price: integrations, exceptions, field conditions and data. - How to choose the first workflow to fix
A practical way for owners and COOs to pick the first operational workflow to fix, and the traps that make a first project stall. - Build, buy or bridge: choosing how to fix a workflow
How an operating company should decide whether to buy software, build a custom tool or bridge the systems it already has to fix a broken workflow. - A demo is not an operational tool
Why an impressive AI demo is not a working operational tool, what sits in the gap between them, and what to ask before you buy or build. - Why the COO should own deployment, not IT
Why an operational tool's deployment belongs to the COO or GM, what IT should still own, and how to split the roles so the tool gets used. - When not to use AI in field operations
Where AI does not belong in a field operations company, from safety and money to missing data, and where a plain tool is the better choice. - What you should own at the end of a software project
What a company should own when a custom software project ends: data, accounts, code, written copyright assignment and a handover pack another team can run. - What a Workflow Spec actually contains
What belongs in a Workflow Spec: observation, interviews, a measured baseline, an adoption design, a build specification and a fixed Build proposal. - The Council Method on a shop floor
How the Council Method for checking AI output applies to estimates and schedule suggestions in a field operations company. - How to run a one-week workflow audit yourself
A day-by-day method for auditing one operational workflow in a week: walk a job, time handoffs, count retyping, list exceptions, find the oldest waiting item. - Questions to ask before hiring an AI consultant
The questions an owner or COO should ask any AI consultant or firm before signing, and what good and bad answers sound like. - How to tell whether a crew really uses a tool
Why logins and dashboards mislead, and how to measure real crew adoption of a field or shop tool from your own job records.
Questions people ask
Who writes the field notes?
Jason Santiago, who specifies and builds each Fox & Santiago tool and wrote Let the AI Be Smart.
Are these case studies?
No. They are arguments and methods. Client work appears only where the client approved it, on the Proof page.
How often are they published?
When there is something worth saying. Each note shows the date it was last updated.
Can I share them with my team?
Yes. They are written to be forwarded to an owner, a COO or a crew lead.
Where do I start?
If a big system stalled at your company, start with the note on why it never got used. If you are choosing what to fix first, start with the note on choosing the first workflow.