Between the model and the field,someone builds the workflow.
I’m Brian Mercier. I bring field operations experience to the software and AI workflows I build, connecting the people doing the job with the systems that track it.
Today dashboard · Demonstration data. All names, companies, and activities are fictional.
The work needs a home beyond the conversation.
I designed FoxOS to keep tasks, follow-ups, and activity history in a shared system of record. A browser, a command line, and an AI agent can each pick up the work without relying on the history of a conversation.
My role
Workflow design, AI-assisted development, deployment, and ongoing maintenance. I designed and built the system from its data model through its user interface.
The decision
The web interface and agent tools use the same API and database. A task belongs to the system, so a new conversation can pick up the work.
The result
A working operations system with a web interface, command-line tools, and an API for agent access. Screenshots demonstrate its capabilities using fictional records, not client work.
Inside the build: Node.js, SQLite, REST API, and CLI
A single Node.js service stores operational records in SQLite. Both the browser and the command-line client work through the API. I deploy and maintain it on a VPS through Coolify. The command at right illustrates how a work item enters the same system from a terminal.
foxos task add "Review vendor quote"
foxos status
# The browser and CLI use the same records.
02
Steward
Workflow execution engine · CLI and review console
Steward’s own console renderer with fictional demonstration records. Controls were shown enabled for the capture; this is a screenshot, not an interactive approval form.
A workspace specifies the stages, inputs, outputs, and dependencies.
Run a bounded stage
The runner assembles the declared context and records the model and artifacts.
Pause for review
A blocking checkpoint holds the draft for a person to approve or reject.
Release the output
Approval writes the reviewed artifact unchanged. Later execution remains a separate choice.
Process illustration, not a product screenshot. The review console makes continuing to later stages an explicit opt-in.
Automation needs clear boundaries.
I built Steward to execute a written workflow while preserving the places where a person needs to make a decision. Its console brings the draft, loaded inputs, audit results, and run history into the review.
My role
Execution-engine design and AI-assisted development. Steward implements workflows built on ICM, the open-source methodology by Van Clief and McDermott.
The decision
Zero runtime package dependencies, explicit review checkpoints, and protection against overwriting hand-edited outputs. Provider adapters keep the workflow separate from the model choice.
The boundary
Installed locally, with run records and artifacts written to the workspace. Cloud providers still receive the inputs sent to them; local installation alone is not a promise that data stays on premises.
Inside the build: review checkpoints and inspectable run records
The console shows declared inputs beside the content actually loaded. Approved drafts are written without another model call. Run records retain checkpoint decisions, resolved model names, usage, and frozen artifacts.
The current console is intended for localhost and has no login. It is not presented here as an authenticated multi-user enterprise service. The static demonstration uses invented records and disabled decision controls.
03
MCP Context Index
Independent measurement · Published method and results
One cohort. A substantial difference.
373.1×
The spread between the smallest and largest tool-definition token counts in the published cohort.
SmartBear@smartbear/mcp · 0.34.0
125,005
Postman@postman/postman-mcp-server · 2.11.2
33,553
Docforkdocfork · 1.3.0
335
Three examples from 38 measured servers in a pinned development-tooling cohort. Measured August 13, 2026, with o200k_base. Bars use a shared linear scale from zero. These are historical tool-definition counts, not current vendor rankings or a measurement of every client's loaded context. Published dataset.
Make the hidden overhead measurable.
AI tools arrive with definitions that describe what they can do. I built a harness to measure those definitions so tool selection could be informed by evidence.
Measurement design, harness development, and reporting. The repository publishes the method, versioned rubric, results, and corrections.
The decision
Pin the server versions and distinguish measurements from editorial grades. A later change to the scoring rubric should not rewrite the underlying evidence.
The limit
A dated, selected cohort, not a random sample of all MCP servers. The probe does not establish output correctness or authenticated runtime behavior. Client loading strategies affect how much context is actually used.
A lesson from the field
A working tool still has to earn its place.
I built and shared quote-review assistance, report-sorting tools, and shortcuts for repetitive entry with an operations team. The tools worked. Adoption remained low.
That experience changed the questions I ask. How much effort does learning the tool require? Does it remove enough friction to justify that effort? Can someone try it without falling behind on the work they are measured on?
My next pilot would make room for that learning period and measure whether people continue using the workflow. The result I want to understand is what stays useful after the demonstration ends.
More work, and the methods behind it
Staged AI workflows
My workspaces built on Interpretable Context Methodology, the open-source protocol by Van Clief and McDermott. Defined phases, file handoffs, and human checkpoints.
A local tool for understanding AI session consumption and planning longer runs. Calibrated estimates are kept distinct from authoritative quota readings.
A budgeting application rebuilt around Node.js and SQLite after investigating a hosted-platform failure. A practical lesson in separating application logic from infrastructure limits.
A synthetic-document experiment asking whether a model volunteers conflicting information when the assigned task does not point at it.
Read the experiment note
The documented v1 experiment used Opus 5 at high effort with 32k-token documents. Conflict detection was 16 of 18 trials when the summary target contained the planted conclusion, and 0 of 18 when it contained neither statement. Wilson 95% intervals were 67–97% and 0–18%, respectively. These are condition-specific results, not a general model-reliability score. Later experiments are separate work.
layout-probe
A browser-layout measurement tool built after a recurring alignment problem. It measures rendered geometry at specified viewport widths and can fail a deployment check when alignment is wrong.
Read the design decision
The tool measures a selected element's offset inside its parent across a group. That makes an alignment claim testable and repeatable instead of dependent on someone noticing a visual difference in a screenshot.
Experience
I’ve worked on both sides of the screen.
Facilities operations, construction delivery, enterprise technical support, and field systems. That background shapes the software I build and the questions I ask before building it.
Enterprise facilities operations: proposal and change-order review, service workflow support, and vendor coordination.
2013–2023
Construction and property-services delivery
Project management at Atlas Property Solutions, followed by ownership and operation of TLC Ohio. Estimating, subcontractor coordination, site inspections, and cost control.
2010–2013
Senior Technical Specialist, Apple
Enterprise remote troubleshooting and service coordination for businesses and educational institutions.
Earlier experience
Field systems and technical foundations
IT business ownership, survey crew leadership, spatial data and mapping, and building systems maintenance.
Hocking College · Associate degrees in Geographic Information Systems and Global Positioning Systems. Additional training spans Apple hardware service, the trades, and AI workflow development.
Tools and technologies
Build
Node.js, SQLite, REST APIs, command-line tooling, JavaScript, HTML and CSS, Google Apps Script
AI workflows
Agentic workflow design, Model Context Protocol, prompt engineering, staged pipelines with human checkpoints
Operations
Facilities operations, construction delivery, estimating and cost control, vendor coordination, proposal and change-order review
Field systems
Geographic Information Systems, Global Positioning Systems, spatial data and mapping, enterprise technical support
Let’s compare notes
Useful technology starts with understanding the work.
I’m interested in conversations about operations technology, AI workflows, and what helps people put a new system to use.
