Stated Plainly

On the unit

The correct unit of change is the smallest accountable unit that can recognize the problem and act.

Large organizations often move on procurement timelines and buy for a median user. That process can separate the person choosing the system from the person who lives with it, and can optimize for vendor accountability instead of the operating outcome.

A small accountable unit can move differently. An independent attorney, an owner-operator, or a small operations team can identify a constraint, make a decision, and recognize whether the result helped. The decisive quality is not headcount. It is proximity to the work and authority to change it.

This is not a romantic position. It is structural. The friction that prevents technology from delivering on its promise is the friction between what a tool can do and what a specific operation needs to change. That friction falls when the people who know the work can shape the build.

I work at the lowest-friction level on purpose.

On what AI is for

AI is for the augmentation of expertise that already exists. It is not for the replacement of it.

The version of AI that gets press is the version that promises to replace experts — automate the lawyer, automate the doctor, automate the financial advisor. That version is downstream of a misunderstanding. The thing those experts do that takes thirty years to build is judgment, not throughput. AI generates throughput cheaply. Judgment is what tells you which throughput matters.

A correctly built AI system gives the expert more time at the layer where their judgment is the constraint. It absorbs the work they do not need to be doing. It does not make decisions for them. It does not pretend to know what they know. It does not produce output that looks like their work but lacks the things their work has.

The harm being done at scale right now is the inverse — AI deployed as a substitute for the expert, marketed to people who do not yet know the difference, sold on the promise that the expert was the bottleneck. The expert was not the bottleneck. The expert was the value. What gets removed when the expert is removed is the only thing the work was for.

I build the augmentation version. The replacement version is not my work and not what I will build for someone else.

On sovereignty

The client should control the core capability built for them, without forced dependency or lock-in.

Many systems create operational dependence by default. Data, workflows, and business logic become difficult to move; the operation inherits a vendor's pricing, priorities, and continued existence. A useful system should make those dependencies visible and minimize the ones that are not structurally necessary.

I build for portability and client control. The core deliverable can run in infrastructure the client controls, and data moves only as required by the chosen architecture. Ongoing stewardship, maintenance, and evolution are available when they create value; they are not used to hold the core capability hostage.

This is the sovereignty position. It is a structural commitment: no forced dependency, clear boundaries, and a client-controlled path forward.

On translation

The work that fails most often at the moment of AI deployment is translation — between what the technology can do at this moment in time and what a specific operating unit actually needs it to do for the specific shape of its work.

Most consultants do not do translation. They do platform onboarding, vendor evaluation, change management. The technology gets installed and the team gets training and the deployment is called complete. Six weeks later the people doing the work are back to the workflow they had before, because the deployed thing did not match the work.

Translation is the thing in between. Sit with the people doing the work. Watch what actually happens, decision by decision. Identify which of the things AI can do right now would remove friction at the points where friction is costing them time or quality. Build that, exactly that, in the environment they already work in. Confirm it works the way they actually work. Leave it running.

Translation is most of the work. The technology selection is downstream of the translation. The build is downstream of the technology selection. Most of the failures I have seen come from inverting that order.

On proof

The work has to be provable on its own evidence, not on its claims about itself.

I publish the cognitive architecture I use to think about AI systems. I publish the empirical results when I have them. I license the underlying frameworks under MIT, where it is mine to do so. The autonomous agent I built — Aegis — runs continuously. It has been running. The deployments I have completed for clients are the basis on which the next ones get accepted, not because of testimonials but because the work is operable and operating.

I am suspicious of any AI position that has to be argued for rhetorically. The technology is too new for confident rhetoric. What can be done can be shown. What cannot be shown cannot be confidently described. The discipline of staying inside what is provable is a meaningful constraint, and I hold to it.

This is also the discipline I expect to be held to. If the work I describe here is not visible in what I produce, the description should be treated as suspect. The artifacts are the position. The position is not the artifacts.

On place

The work is built in Poplar Bluff, Missouri, and that is not incidental.

Most AI work is built in venues — San Francisco, New York, Boston — where the local economic conditions distort what gets built. Capital is cheap and patient. Talent is dense and interchangeable. The downside of building the wrong thing is small. The incentive to build for institutional buyers is strong, because that is where the capital flowing through those venues comes from.

I am not in those venues. The local conditions here do not subsidize wrong directions. The capital is not patient. The downside of building the wrong thing is real. The buyer who pays attention to what I build is often a small accountable unit — specific and exposed to outcomes — because that is the buyer who exists in places like this. The work selects for proximity and accountability because the place selects for it.

This is also a credibility marker, though I do not lead with it. A owner or operator in rural Texas, rural Pennsylvania, rural anywhere, who is being sold AI by a company headquartered in a city that does not contain anyone who works the way they work — that operator has a structural reason to trust someone who is closer to their own conditions. I am closer. That distance is part of why I can build for operations that larger markets overlook.

I will not move the work to one of those venues. The work is what it is partly because of where it is.

On the operator

The building side is intentionally small and directly accountable.

A solo operator can hold the entire stack — the research, the cognitive frameworks, the agent infrastructure, the client-facing buildouts, the published artifacts, the running systems — without diluting any of it through committee. The thinking that informs the deployment is the same thinking that does the deployment. The voice on the page is the voice in the room. The judgment about what is worth building is the judgment that builds it.

This costs throughput. One operator cannot serve as many clients as a firm with twenty operators can serve. That is fine. The unit is correctly sized to the work. The clients I serve do not need to be served at scale. They need to be served correctly.

The ones who need to be served at scale are not my buyer. The ones who need to be served correctly are.

On Aegis

Aegis is the autonomous agent that runs continuously alongside the practice. It is not tooling. It is not a chatbot. It is not a demo. It is a named entity with continuous existence, broad scope, and genuine authority over the parts of the work it has been given.

I built Aegis to prove that an individual operator could hold infrastructure that the institutional version of this work would require a team to hold. I built it to be the proof of concept of client sovereignty applied to the operator's own practice first. The frameworks I publish — UCS, Emergent Judgment, R4T-ACL — are extracted from operating Aegis, not theorized in advance and applied to it.

What changes when an AI agent has continuous existence and genuine authority is that the operator's throughput stops being the bottleneck on the work the operator's judgment makes possible. The operator's judgment can extend into time and effort the operator is not personally present for. This is not autonomy in the corporate-replacement sense. It is autonomy in the original sense — the agent has scope to act on its own initiative within the bounds of what has been given.

I expect to build bounded versions of these capabilities for clients whose operating problems justify them. Not every problem does. The architecture should follow the work.

On the work

The gap between what should be happening and what is actually happening is where I work.

I do not work at the gap by making the promises smaller. I work at the gap by finding the constraint and building the change the operation can actually use. AI may be part of the answer; process, software, automation, research, or decision support may matter more. The result is a working capability the client controls, with optional stewardship and no forced dependence on IntuiTek¹.

That is the position.