field note · building the stack
The AI stack I built, and the parts I left thin on purpose.
I built the AI operating layer for my firm from zero, with no prior technical background. The account below is honest about what is strong, what is deliberately unfinished, and what decided the difference.
Virgil Strategies is a solo government affairs and policy intelligence firm. Over the past year I built its operating layer: a client portal, payment processing, a research and drafting system, a hardened identity layer. Building it at all was a forward bet. Two years ago an operating layer like this was not obviously worth the time for a one-person policy firm, and I read it as where the work was going and built early.
I will be precise about what is strong and what is still thin. The honesty is the point. An operating layer you oversell is one nobody should trust.
The stack, layer by layer
I do not think of a stack as the tools I pay for. I think of it as where intelligence sits in the work, and who is allowed to act without me in the room. There is a public frame for the same idea: five layers, from the model that reasons down to the interface a person actually touches. Here is where my build sits against each. The meter shows build maturity, not ambition.
The reasoning. Claude across three surfaces: chat, command line, and a desktop agent. The easiest layer to get right and the cheapest to run.
The hands. A live client portal on Node and Express with Stripe ACH working end to end, including the webhook handling that trips most first builds. Mail, calendar, documents, payments, and a research vault all connected.
The face. A portal clients log into, two public sites, and a knowledge base I work out of every day.
The part that decides the next step. I built a custom instruction-and-context system that routes work and holds firm knowledge, which does real coordination. I have not stood up autonomous agents. That is a deliberate decision, not a missing feature.
Background automation that runs unattended. I have discrete pieces, such as payment flows and document scripts, but not yet a set of processes acting without me. This is the next build, and the one I am most careful about.
What I refused to automate
This instinct did not come from software. I move policy for a living, where a wrong read loses a bill and a careless message burns a relationship I will need next session. I learned to decide, early and coldly, what is too consequential to hand off. I built the stack the same way.
So I capped it where a quiet failure would cost more than the time it saves. A person stays in the loop on money and on anything that speaks for me: no message goes out, no payment clears, and nothing gets published without a human approving it first. I name what access a tool is being granted, to whom, and at what risk, before I wire anything to anything. When the identity layer needed hardening, I took it to enforced multi-factor authentication and a strict mail authentication policy before adding a single new integration.
That is not caution for its own sake. A solo operator who automates aggressively and watches nothing ends up with silent errors and no reason to trust the system. The discipline is the product.
The rules I followed
The test case was a firm of one, but none of these were about size. Four held up.
-
I started with the work, not the tools.
The first thing I automated was the task that was frequent, structured, and ate real time. The tools came after, chosen to fit the work rather than the other way around.
-
I built in layers.
Augment first, where the system assists me. Automate second, where it runs inside rules. Delegate last, where it acts on its own. I have not reached delegation, and I am in no hurry to.
-
I wired the money in early.
Financial data is a decision lever, not a reporting afterthought, so payment processing went in near the start instead of bolted on at the end.
-
I set the brakes by blast radius.
The higher the cost of a silent mistake, the more I keep a person in the loop. That one rule decided everything I automated and everything I left alone.
A team can run these further than I can alone. The rules do not change with scale.
This is how I work in general. I read where an environment is going, not only what it needs today, build the infrastructure that gets it there, and stay until it holds.
The AI stack is the most recent example I can point to. If you are working out where intelligence should sit in your organization, and where it should not, that is a conversation I would welcome.
adam@adamducote.com →