By Marc Taccolini, Founder and CEO, Tatsoft
*This piece condenses the full article on Substack, which adds the decision register counts and the measured fall in decision filings. Some skills used by the AI machinery described here are published in the GitHub Skills Repository.*
I ran statistics on the last 71 days: over 21,000 prompts, 508 million tokens of model output. Interesting metrics surfaced.
One typed instruction drove roughly 28 model steps, the AI’s production work. That ratio is the subject of this article. A model that has to stop and ask what you meant can’t run 28 steps unattended, and a model without good grounding will drift before it reaches its goal. What buys the other 27 is what the system can reach without asking or drifting.
The window, and what I was measuring
I’ve been building software for industrial plants for 3+ decades. In 1996 I released the product UniSoft, which became InduSoft (now AVEVA Edge). I started Tatsoft in 2009, I still lead the platform design, and I also decide on the internal business tools of the businesses I run.
Starting last year, I went deep into using AI, specifically Claude Code, in 3 aspects:
(A) Evolve the personal-assistant or second-brain concept into an AI co-COO, with access to and assignments in ALL business processes.
(B) Apply AI to assist product development and quality assurance (success metric: 700+ custom QA solutions created this year).
(C) Integrate AI in the FrameworX product itself (success metric: the Designer MCP allowed a 100+ screen competitive upgrade in a weekend).
The logs behind those numbers come from the three machines I use daily; almost all of the output sits inside a thirty-two day stretch. The models improved over the same period, so I can’t split what the tooling bought from what they did.
This article focuses on (A), the business side. A sibling article covers (B) and (C); more of our AI machinery will be published in the future.
For the business tools, I didn’t want an assistant. I wanted a co-managing tool wired into the systems where the company actually runs: customer sales and support records, accounting and finance, quoting and licensing, document stores (public-facing and intranet spaces), mail and calendar, the marketing platform. Not a place to keep notes. A place where the work happens.
Where truth lives, and why summaries drift
Claude Code was originally designed, as its name states, for programming. In software development, the source code is the single source of truth (SSoT) on what the platform is doing, and everything else is commentary and metadata.
A business, in some sense, has its source code too, and almost nobody writes it down. The signed PDFs, the invoices and permanent company records, the purchase orders received, rows in operational databases, the thread where the customer actually said the thing. Every summary, index and status note is somebody’s reading of it.
Point a general agent at a business and the first thing that breaks is grounding. Mine kept reading the summaries instead of the invoice or the document itself: an index it had written last week, or an MD file from a previous session that, even out of date or plainly incorrect, counted as good a source as the repository files and the connectors. Those files aren’t wrong when written; they’re snapshots, and a snapshot starts drifting the moment the system moves and it doesn’t. The failures that cost me most traced back to that shape.
The fix isn’t clever, and it took me too long to find. Name the systems of record. Make reaching them cheaper than remembering them. Make it a standing rule that a summary is never a source. The challenge is the balance: AI needs pre-processed information in many cases, and we also need to avoid drift or hallucination, so the work stays based on the sources of truth.
Decisions, reversibility and reach
The second failure was calibration, in both directions.
At first the agent made permanent decisions on thin evidence. One sentence I included in a long prompt became a settled company fact. A large output to which I replied “ok, go” made ALL of the 500k+ tokens in the session be taken as settled facts. That’s a hallucination with an audit trail. The lack of reliability was making the system unusable: I could only rely on the replies where I already knew the answer.
So I built the ledgers: pending decisions, executed decisions, follow-ups, a record that outlives any one session, plus hooks, gates, rules and skills for more advanced data modeling and maintenance. Then it overcorrected. Every implementation detail became a formal business decision. The agent found two customer records that were obviously the same company and, instead of merging them and telling me, logged the question and waited. When the reply to “what is pending to close this session” points to 108 decisions you have to engage with personally, that is not what I call a time-saving tool.
No prompt fixes that. The line that holds is a data model structure with maintenance rules, plus reversibility and reach. Internal and reversible: do it and tell me afterwards (or don’t even tell me, for approved workflows). Money, contracts, people, business process changes: ask first. Entry into that queue is free to every session running at once; the exit piled work on top of the person it was supposed to assist. Without that calibration, assisted workflows can take longer than just doing it yourself.
What catches it when it’s wrong
Deterministic guardrails, not trust. A workflow whose only verifier is another language model has no verifier. As much as possible, use traditional programming (like Python hooks on key events) and deterministic workflows managed by external company systems, instead of relying only on model agents for verification.
Certainly, in many workflows it’s not possible to have a deterministic layer. Either way, an independent cold review by a separate model agent (at high or extra high reasoning effort) is a mandatory step in all coding, document generation and tool actions where advanced reasoning is involved.
At the current state of the technology, all documents to customers, and all emails, must reach the user as drafts. Once the system was finally fine-tuned, “most” of the outputs were 100% ready to send without changes. But the operative word is “most”: even when the AI is at its best, around one output in ten could harm the user or the company’s image if allowed to go out without user review.
Tracking and audit should be an integral part of the design. Every write to the customer database can be replayed. Every action leaves a receipt.
There is one important gap in this flow, and it is part of the reason I am not yet publishing our engine to GitHub. The process that reads back the audit receipts searching for mistakes, the process that moves history out to keep the current state lean, and some other maintenance tasks are still evolving. That is happening in our custom machinery, and on the model side too, like the automatic memory consolidation (“dreaming”) that Anthropic released this year.
Three things I’d tell you before you start
The organization and maintenance of the workspace is a regular task. Leaving it at its initial setup, or letting the AI manage it by itself, is not enough. Specific sessions are necessary, for instance reviewing the entire week of transcripts and the current metadata across the repository, verifying compliance and improving its structure. To perform that task, three things are required.
The person driving has to know the subject. I don’t believe AI is replacing people outside genuinely simple tasks. Where it has worked, the person at the controls knows the domain well enough to catch a wrong answer on the spot, while it’s still cheap.
You do the architecture. Folder structure, naming conventions, the schema and its rules, the vocabulary. Design them yourself for the first seats. Let the agent invent the structure and you’ll spend months repairing it.
Maintain it from the evidence. Most of our improvements came from querying thousands of past transcripts for what had gone wrong. Then make something attack the result. I had a second pass attack a hundred already closed items, told to break them, and it reversed thirty-nine. I only know the first pass was wrong because I built something to argue with it.
There is no magic file. A giant instruction file loaded into every session is an entry point, not a system; underneath you need real organization, moving work from working memory to archive to history on a schedule.
The short version
An AI agent is only as good as what it can reach. Point it at the real records, not its notes about them.
Decide what it may do alone and what it must ask about. Small and reversible: act, then report. Money, contracts, people, how the business runs: ask first.
Let a program check its work, not another model alone: pick one step code can test, say an invoice total equals the sum of its lines. Then add an independent model review, and anything going to a customer still leaves as a draft.
Write down the words your team argues about, and for each the rule it carries, not its definition; a word with no rule isn’t worth the fight. I haven’t finished this: my glossary describes our rules, the enforcing code was written separately, and when they drift apart nothing warns me.
An agent reading the real records behaves like an engineer reading the instruments. One reading last week’s summary tells a story about a process it can’t see. That difference isn’t only model quality. It’s what you connected.
The full set of what runs this, the workspace rules, the hooks, the engine underneath, is not published. It is still maturing, and handing you a copy of something I am still repairing would cost you more time than it saved. What is published is smaller and it stands on its own: twelve Claude Code skills, self contained, with no dependency on anything we sell, and none of them about industrial software. They apply in a programming workspace and in a management one. Take those, and build the rest around the way your own business actually runs. They are on GitHub now, at https://github.com/tatsoft-llc/Claude-Code-Skills.
Author Bio: Marc Taccolini has spent three decades building industrial software, founded Tatsoft in 2009, and still designs the platform.
*Aim High. Start Simple. Scale Without Limits.